[zeromq-dev] What is 0MQ?]

Martin Sustrik sustrik at fastmq.com
Wed Dec 10 10:33:37 CET 2008


> When I first started looking at 0MQ, I was under the impression that it 
> is simply an implementation of AMQP.  Correspondence on this list helped 
> me understand that AMQP is just a part of this project; however, I’m 
> still not quite sure I understand the motivation and the goals here.

Actually, this is one thing 0MQ is really missing: 50 word description
of what it is on the front page. Let me summarise what it is in bullets
and if anyone is able to come up with comprehensible text to place on
the frontpage we'll be happy to use it.

* 0MQ core is not a middle-ware, it's rather a meta-middleware
* It implements few low-level features e.g.:
   * How to locate message flow endpoints on the network
   * How to establish connections between the endpoints
   * How to shut down connections
   * How to pass messages between connections and application threads
* The rest of the functionality is pluggable.

So you can plug in different network transports (TCP, RDMA, PGM, SCTP),
different OSes and meachanisms for polling for network events (select,
poll, epoll, /dev/poll, kqueue, IOCP), different MOM protocols (0MQ
native, AMQP, STOMP, XMPP), different client API (C, C++, Java, Python),
different routing sematics (fanout, topic, content-based,
load-balancing), different queueing mechanism (transient, persistent,
last-value cache).

Obviously, not all the plug-ins are available at the moment, but we are
gradually moving to cover as much of it as possible.

> Front-end financial trading systems usually require not only fast data 
> distribution, but also use cases such as the following:
> -          The ability to have clients subscribe to fast updates, 
> different clients may subscribe to different data (so a general 
> broadcast of all data won’t work)

Yup. Topic or content-based routing. It's on the roadmap.

> -          The ability to sync up clients in case of failure—sending a 
> snapshot, re-subscribing

At the moment this has to be done on application level (note that even
AMQP doesn't define last-value cache or resubscriptions atm). Later on
this can be plugged in.

> -          A transaction/persistence engine which allows messages to be 
> restored if the whole system, server and clients, crash (think FIX 
> messages that can’t be lost just because RAM is wiped clean)

Persistence is not high on the priority list as it is contradictory to
low latency. However, we have done some experimenting with persistence
and we do have some preliminary results.

> Clearly this project provides the transport layer, but are there plans 
> to provide other features as well?

Yes, sure there are plans for all of that. However, our business model
is based on custom development, so we are developing the features we are
paid by our customers to develop in the first place. If you need certian
feature urgently, you can contact us directly to code it for you.


More information about the zeromq-dev mailing list