[zeromq-dev] Poll results!

Martin Sustrik sustrik at fastmq.com
Tue Dec 9 17:31:11 CET 2008

Hi Peter,

>> 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.
> I, personally, don't think that implementing a xmpp-parser is a
> generally good idea. IMHO, proper solution will be to implement
> 0MQ-plugin to some xmpp-server instead (as LShift guys did with AMQP
> already).

Well, the point here is that you either need high-perf XMPP solution or 
you don't. In latter case you can use existing XMPP brokers (eJabberd or 
whatever). In former case the existing XMPP server would create a 
performance bottleneck in the architecture. I've disucussed XMPP-support 
briefly on XMPP mailing list and it seems that "high-perf" as understood 
by XMPP community is approx. 2 order of magnitudes lower that 
"high-perf" as used in stock trading industry (10,000 msgs/sec vs. 
1,000,000 msgs/sec). It would be interesting to know what people would 
actually expect from XMPP/0MQ implementation...

> BTW how different 0MQ from hypothetical AMQP reference
> implementation?

We've wrote the original reference implementation for AMQP once... 
Today, 0MQ is an effort to overcome the bottlenecks inherent in AMQP 
design (centralised broker, single network channel for management and 
messages, inefficient message batching etc.) Basic AMQP plug-in for 0MQ 
is already written but you won't expect extreme performance here (tests 
are showing ~750,000 messages/second).

>> 15. IPv6 support (0 votes) - no one wants IPv6!
> Since IPv6 will be widely used in the very nearest future, this
> feature should be implemented in any case :)



More information about the zeromq-dev mailing list