Things learned about ZeroMQ so far

ZeroMQ is basically sockets on steroids — with a message queueing approach. It can replace your typical client/server communication and RPC needs as well.

Don’t think of ZeroMQ as a Message Queue (a common misconception due to its name), but rather as a message passing library, which you can use it to create your own MQ.

The ZeroMQ manual starts off with a simple example, namely a Hello World server and client. The client sends Hello at regular intervals and the server responds with World. As the manual suggests; try starting the client, and then starting the server. It all still works — and that’s our first hint that we’re no longer using old school sockets.

The second thing I learned is that a A ZeroMQ string (or message frame) is not null terminated. Instead, they start off with the buffer length followed by the actual buffer. So it’s safe.

The real power of ZeroMQ is the PUB-SUB (Publish Subscribe) pattern, a data distribution pattern. Having worked with message queues such as OpenMQ, ActiveMQ and RabbitMQ before, I have some experience in message queues and ESB architecture, but ZeroMQ is much more bare bones and should not be directly compared with these apps.

Other ZeroMQ patterns include the pipeline pattern (a fan-out/fan-in for parallel task distribution and collection). Another pattern is exclusive pair, which is for connecting to threads in a process.

ZeroMQ doesn’t care about message content itself, so you can basically use any serialization you want, whether it’s JSON or Google Protobufs.

The guide is also somewhat controversial -

“ZeroMQ is perhaps the nicest way ever to write multithreaded (MT) applications. Whereas ZeroMQ sockets require some readjustment if you are used to traditional sockets, ZeroMQ multithreading will take everything you know about writing MT applications, throw it into a heap in the garden, pour gasoline over it, and set it alight. It’s a rare book that deserves burning, but most books on concurrent programming do.”

More to come…