Question

I’m just starting understanding and trying ZeroMQ.

It’s not clear to me how could I have a two way communication between more than two actors (publisher and subscriber) so that each component is able both to read and write on the MQ.

This would allow to create event-driven architecture, because each component could be listening for an event and reply with another event.

Is there a way to do this with ZeroMQ directly or I should implement my own solution on top of that?

Answer 1

If you want simple two-way communication then you simply set up a publishing socket on each node, and let each connect to the other.

In an many to many setup this quickly becomes tricky to handle. Basically, it sounds like you want some kind of central node that all nodes can “connect” to, receive messages from and, if some conditions on the subscriber are met, send messages to.

Since ZeroMq is a simple “power-socket”, and not a message queue (hence its name, ZeroMQ – Zero Message Queue) this is not feasible out-of-the-box.

A simple alternative could be to let each node set up an UDP broadcast socket (not using ZeroMq, just regular sockets). All nodes can listen in to whatever takes place and “publish” its own messages back on the socket, effectively sending it to any nodes listening. This setup works on a LAN and in a setting where it is ok for messages to get lost (like periodical state updates). If the messages needs to be reliable (and possibly durable) you need a more advanced full-blown message queue.

If you can do without durable message queues, you can create a solution based on a central node, a central message handler, to which all nodes can subscribe to and send data to. Basically, create a “server” with one REP (Response) socket (for incoming data) and one PUB (Publisher) socket (for outgoing data). Each client then publishes data to the servers REP socket over a REQ (Request) socket and sets up a SUB (Subscriber) socket to the servers PUB socket.

Check out the ZeroMq guide regarding the various message patterns available.

To spice it up a bit, you could add event “topics”, including server side filtering, by splitting up the outgoing messages (on the servers PUB socket) into two message parts (see multi-part messages) where the first part specifies the “topic” and the second part contains the payload (e.g. temp|46.2, speed|134). This way, each client can register its interest in any topic (or all) and let the server filter out only matching messages. See this example for details.

Basically, ZeroMq is “just” an abstraction over regular sockets, providing a couple of messaging patterns to build your solution on top of. However, it relieves you of a lot of tedious work and provides scalability and performance out of the ordinary. It takes some getting used to though. Check out the ZeroMq Guide for more details.