[zeromq-dev] Preliminary results of voting

[Martin Sustrik]

Hi all,

After a week of voting on prospective 0MQ features we have some 
preliminary results.

Topic routing seems to be the most desired feature (6 votes). In a way 
it pairs with another desired feature, IP multicast support (4 votes) to 
provide an efficient publish/subscribe framework. We are working on 
these features, however, it'll take some time to get the functionality 
right. In the meantime it would be useful to know how much functionality 
are users willing to sacrifice to get extremely low latency and 
extremely high throughput. Specifically:

1. Would it be enough to use wildcard only on the end of the selector 
string? (I.e. "animals.mammals.*" but not "animals.*.dogs".)
2. Would it be sufficient to have the topic hierarchy precompiled in 
advance and not to be able to add new topics on the fly?

Opinions are welcome!

The next desired item - surprisingly - is to lower the latency from 
current 30 us to 10 us (5 votes). I have no idea what conclusion to make 
from this. 30 us is as low as you can get on commodity hardware and 
standard networking stack. Are people really willing to buy expensive 
networking hardware and use non-standard networking stacks (consider 
what network administrators would say if faced with significant amount 
of non-IP traffic on the company network) - all this just to lower the 
latency by 20 us? Comments on this issue would be helpful.

Anyway, for those striving for ultra-low latency, I would suggest 
visiting Myricom's stall at High Performance on Wall Street conference 
(New York, September 22nd) and asking for current performance figures 
for 0MQ on the top of SDP-MX/Myricom-10GbE stack. It should be slightly 
over 10 us...

Porting to Windows is obviously a concern (5 votes). Although 
non-conformance of Windows with respect to any possible standard makes 
the thing particularly annoying to implement, we'll work on this and 
deliver Windows version of 0MQ in form of binaries (to avoid building 
problems with mutually incompatible version of MSVC).

Support for different programming languages is - as expected - 
desirable. We'll publish C, Python and Java extensions for 0MQ during 
next few weeks.

Solving C10K problem seems to be a concern (3 votes). Next major version 
of 0MQ will contain epoll (dev/poll, kqueue) -based solution.

There are 3 votes for XMPP support. Once again, it would be interesting 
to have some feedback on this requirement. Does anybody need XMPP 
messages transferred in microseconds, several million of them a second? 
And if these are the requirements of your system, why have you chosen 
XML-based (and thus inherently slow) XMPP over a binary protocol?

Regards.
Martin