ØMQ – The Guide (2011)

I looked at zeromq, but it seemed like it had very bad debug-ability and visibility into internal operations. Their FAQ [0] says things like:

> How do I determine how many messages are in queue?

> This isn't possible. [...] rather than provide incorrect information the library avoids providing any view into this data.

> How can I retrieve a list of all connected peers?

> This is not supported.

Those kinds of decisions are very scary for production environment. We've had to debug network connectivity problems before, and it just possible what all the interfaces Linux kernel provides. I cannot imagine doing it with library which hides stuff from you on purpose.

[0] http://wiki.zeromq.org/area:faq

You can think of ZeroMQ as legos for building message queue-based messaging systems. ZeroMQ gives you different pieces - pushers, pullers, publishers, subscribers, routers, etc. and it's up to you to then hook them up in different ways to create the system you want. The guide gives you some different ideas of how to hook up the different pieces for common use cases, but there's nothing stopping you from building a custom one.

ZeroMQ is not an out-of-the-box MQ solution. It takes some work to understand and build a functional MQ solution with ZeroMQ. If you want something that works out of the box I recommend RabbitMQ.

I guess this is fair criticism given the FAQ, but many features have been added over time.

Setting up a monitor socket allows you to observe pretty much any event you could care about, like peer connect/disconnect/errors, etc.

There is also a draft feature to access the number of queued incoming/outgoing messages (see https://github.com/zeromq/libzmq/blob/master/doc/zmq_socket_... for details).

the [...] that you removed is

> At any given time a message may be in the ZeroMQ sender queue, the sender's kernel buffer, on the wire, in the receiver's kernel buffer or in the receiver's ZeroMQ receiver queue. Furthermore, a ZeroMQ socket can bind and/or connect to many peers. Each peer may have different performance characteristics and therefore a different queue depth. Any "queue depth" number is almost certainly wrong

The library doesn't hide stuff from you, it just refuses to show you information that might as well be a random number.

If you want to know how many peers are connected you use heartbeats instead of just blindly trusting that 1 tcp socket = 1 available peer.

Anyone know how nanomsg (https://nanomsg.org) or nng (https://github.com/nanomsg/nng) compares?

Interesting that nanomsg tries to better zeromq (https://nanomsg.org/documentation-zeromq.html) and then nng tries to better nanomsg (https://nng.nanomsg.org/RATIONALE.html)

edit: just noticed nng and nanomsg share the same domain, so probably the same people behind them.