Zeromq which socket should bind on PubSub pattern

Question

I have been reading about ZeroMQ more specifically about NetMQ and almost every Pub/Sub examples I saw used to Bind the Publisher socket and then the Subscriber socket connects to the other.

So i'm wondering if it is possible to do the reverse, i mean Bind the Subscriber socket and then publishers connect to it.

Is this possible ? (I didn't found anything clear on documentation) What are the disadvantages using this connection strategy ?

Any help will be usefull.

Tubercle

Answer 1

Yes, you can reverse it and there are no disadvantages to using that connection strategy... provided it suits your purpose.

In ZMQ, the driving concept behind "binding" and "connecting" is that one side is often considered to be more reliable (and usually there will be fewer nodes), and the other side is considered to be more transient (and there could be more numerous nodes). The reliable side would be considered your "server", and you should bind() on that side, the transient side would be considered your "client" (or clients), and you should connect() on that side.

Typically, we think of a stable "server" publishing information constantly, to many "client" subscribers which may come and go. This is represented in the examples that you see: bind on pub, connect on sub.

But, you could just as easily have a stable "server" subscribing to any output from many "client" publishers that connect to it, accepting any information that they're sending while they are available. Bind on sub, connect on pub.

You're not limited to one server, either, it's just the simplest example - however, you're more limited if you're running all of your sockets on the same computer. Binding on the same address with more than one socket will produce a conflict, but you can connect as many sockets to the same address as you like.

In many cases, both sides of the communication are really intended to be reliable and long running, in which case it's useful to think of the node which sends the information as the server, and the one which receives it as the client. In which case, we're back to bind on pub, connect on sub.

Thinner