[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 :)
:)
Martin
More information about the zeromq-dev
mailing list