Features
What security features does ØMQ support?
None at the moment. ØMQ does not deal with security by design but concentrates on getting your bytes over the network as fast as possible. Solutions exist for security at the transport layer which are well understood and have had many man-years of development invested in them, such as IPsec or OpenVPN.
Having said that, if you have a use case which precludes the use of transport layer security please let us know and we can discuss your needs.
Does ØMQ support IP multicast?
Yes, ØMQ includes Pragmatic General Multicast (RFC 3208) support using the excellent OpenPGM implementation.
Does ØMQ include APIs for serializing data to/from the wire representation?
No. This design decision adheres to the UNIX philosophy of "do one thing and do it well". In the case of ØMQ, that one thing is moving messages, not marshalling data to/from binary representations.
Some middleware products do provide their own serialization API. We believe that doing so leads to bloated wire-level specifications like CORBA (1055 pages). Instead, we've opted to use the simplest wire formats possible which ensure easy interoperability, efficiency and reduce the code (and bug) bloat.
If you wish to use a serialization library, there are plenty of them out there. See for example Google Protocol Buffers.
Does ØMQ support AMQP protocol?
It used to. The feature was dropped to protect ØMQ users from infringement on AMQP-related patents.
Development
I cannot use more than 64 connections on Windows; what's the problem?
The Windows implementation of select() handles at most 64 connections by default. To increase this limit define the FD_SETSIZE macro to a more reasonable value. Keep in mind that FD_SETSIZE has to have same value in all the compilation units, otherwise unexpected behaviour is to be expected.
My Python/Ruby application isn't responding to signals, why is ØMQ mucking with my signal handlers?
It's not. However, ØMQ uses native I/O threads to offload I/O in the background. Unfortunately, the current state of affairs is that signal handling in Python and Ruby applications which use native threads is broken. Any help from the Python or Ruby communities on fixing this would be much appreciated.
I can't Ctrl-C my Python/Ruby application. Help!
See above. As a workaround we've found that on POSIX systems Ctrl-\ seems to work as long as your application doesn't try to install a handler for SIGQUIT.
I'm trying to send data using the udp:// transport and I get "Protocol not supported". Why?
The udp:// transport is not plain old unicast UDP but actually PGM encapsulated in UDP packets. You need to have ØMQ built with the —with-pgm option for this to be enabled.
Why am I only getting 100 kbps performance when sending messages using PGM?
PGM uses rate-limiting on the sender side. By default this limit is set to 100 kbps. You can set it using the ZMQ_RATE option to zmq_setsockopt().
Why does ØMQ use 100% CPU when sending messages using PGM?
Because the OpenPGM rate limiting is implemented using busy waiting. This only happens where there are data to send in the sendbuffer. If there's nothing to send, CPU is idle.
I read somewhere that I have to run my application as root if I want to use PGM, is this true?
The udp:// transport uses PGM encapsulated in UDP packets and does not require any special permissions.
If you need to use the raw pgm:// transport. then your application must be able to create raw sockets, which means either running as root or with capabilities to do so. On a modern Linux distribution with capabilities enabled you can use the following to run an application with the CAP_NET_RAW capability enabled:
$ sudo execcap 'cap_net_raw=ep' pgmsend moo
For more details please see the relevant OpenPGM wiki page.
How can I integrate ØMQ sockets with normal sockets? Or with a GUI event loop?
You can use the zmq_poll() function to poll for events on both ØMQ and normal sockets. The zmq_poll() function accepts a timeout so if you need to poll and process GUI events in the same application thread you can set a timeout and periodically poll for GUI events. See the zmq-camera example for a demonstration.
Performance
The graph in the test results shows that ØMQ is slower than TCP/IP. What's the point then?
Obviously, you would expect system working on top of TCP to have higher latencies than TCP. Anything else would be - simply speaking - supernatural. However, throughput is a different matter. ØMQ gets you more throughput than TCP has using intelligent batching algorithms. Moreover ØMQ delivers value-add over the TCP. Asynchronicity, message queueing, routing based on business logic, multicast etc.
How come ØMQ has higher throughput than TCP although it's built on top of TCP?
Avoiding redundant networking stack traversals can improve throughput significantly. In other words, sending two messages down the networking stack in one go takes much less time then sending each of them separately.This technique is known as message batching.
When sending messages in batches you have to wait for the last one to send the whole batch. This would make the latency of the first message in the batch much worse, wouldn't it?
ØMQ batches messages in opportunistic manner. Rather than waiting for a predefined number of messages and/or predefined time interval, it sends all the messages available at the moment in one go. Imagine the network interface card is busy sending data. Once it is ready to send more data it asks ØMQ for new messages. ØMQ sends all the messages available at the moment. Does it harm the latency of the first message in the batch? No. The message won't be sent earlier anyway because the networking card was busy. On the contrary, latency of subsequent messages will be improved because sending single batch to the card is faster then sending lot of small messages. On the other hand, if network card isn't busy, the message is sent straight away without waiting for following messages. Thus it'll have the best possible latency.
ØMQ's latency is nice, but is there a way to make it even lower?
We are working on delivering ØMQ over alternative networking stacks, thus having advantage of features like kernel bypass, avoiding TCP/IP overhead, using high-performance networking hardware etc. That way we can get the latency as low as 10 microseconds. Contact us to get more details.
Licensing
See the ØMQ licensing page.
