[zeromq-dev] Poll results!

[Martin Sustrik]

Hi all,

We've ended the poll about new features in 0MQ today. Here are the results:

1. Windows port (18 votes)

Windows port is already available in 0MQ/0.4.

2. Topic-based message routing (11 votes)

This feature is on our roadmap. However, it resides quite high in the 
messaging stack and thus it's scheduled to be implemented *after* some 
low-level features (transitive flow control, pluggable MOM protocols etc.)

3. Multicast (9 votes)

PGM plug-in is available for a long time already, however, 0MQ core 
needs few changes to be able to support multiple transport protocols 
(say TCP+PGM) at the same time. This functionality is high in our 
priority list.

4. Get latency down below 10us (7 votes)

I've wrote about this issue already. Getting the latency below 10us 
means switching to high-end non-commodity networking hardware, using 
kernel by-pass, non-standard APIs etc. It means using expensive hardware 
& vendor-specific software to get few microseconds of latency advantage. 
This kind of thing may be useful for stock exchanges to implement 
collocation services, for clustering solutions within a datacenter etc. 
However, the scope is pretty narrow and the development should be 
strictly focused. Contact us directly (desk at fastmq.com) if you need this 
kind functionality.

5. C10K (6 votes)

Handling thousands of connections in parallel is a challenge for any 
messaging system. 0MQ/0.4 already supports different polling mechanisms 
provided by different OS's (epoll, /dev/poll, kqueue) that remove the 
bottleneck in the OS kernel layer.

6. XMPP (6 votes)

Prerequisite for XMPP support is implementing MOM-protocols as plug-ins. 
Thus a single instance on 0MQ would be able to handle 0MQ native traffic 
on one connection, while processing AMQP messages on another, XMPP 
traffic on the third one etc. Making the protocols pluggable is high on 
our priority list. However, we would appreciate help from XMPP community 
w.r.t. writing the XMPP parser itself.

7. Persistence (5 votes)

Persistence is contradictory to high performance. Storing data 
permanently is time-expensive operation. We've done some tests with SSD 
storage and at this point we are sure we can add persistence to 0MQ with 
the trade-off of ~200us higher latency (messages may be moved from SSD 
to standard HDD in the background). If you really need this 
functionality, I would suggest contacting us directly as it is quite low 
on the priority list right now.

8. Get throughput up to 5,000,000 msgs/sec (5 votes)

As 0MQ is able to handle thrice the peak volumes of OPRA feed 
(consolidated market data feed of big US option exchanges) without any 
message batching on part of the application. The request for 5M msgs/sec 
thus seems a bit exagerated. But sure, we are optimising the stack as we go.

9. .NET client (4 votes)

We believe that being able to access 0MQ from C#, VB etc. is the key to 
allow 0MQ to extend from the datacenter (primary use case for the 
product) to the desktop. Thus, you'll be seeing .NET client for 0MQ soon.

The rest of the features got 2 or less votes. Let me summarise them briefly:

10. STOMP support (2 votes) - same comment applied as to XMPP
11. Security (2 votes) - low priority as for now
12. RTD integration (1 vote) - can be done as an external project if 
there's a volunteer out there :)
13. SCTP (1 vote) - seems there's a little interest in the feature
14. Perl API (1 vote) - no much interest either
15. IPv6 support (0 votes) - no one wants IPv6!

Thanks everybody for joining the survey and have a nice holidays!
Martin