[zeromq-dev] XREP vs. ROUTER

Martin Sustrik sustrik at 250bpm.com
Fri Mar 18 15:29:01 CET 2011


On 03/18/2011 02:36 PM, Martin Lucina wrote:

> 1) People who want an improved REQ/REP model. Retransmission, recovery from
> wedged states, sending more than one request asynchronously. All of these
> are valid parts of a REQ/REP model.
>
> 2) People who wish to do completely custom routing or filtering of
> messages. E.g. similar to an AMQP headers exchange.
>
> 3) People who just want to use 0MQ as "smart message-oriented sockets" and
> don't give a damn about scalability or high level messaging patterns
> (yet).

That's a nice analysis :) Anyone using XREP who believes he doesn't fit 
into any of the three groups, shout!

> Group 1) should be done by improving REQ/REP in the core, but someone has
> to do it up to core standards. If it's not there, people will want a
> "router" to do it themselves.

Definitely. Request/reply pattern implementation is leaking in various 
ways and should be improved.

> Group 2) looks like a valid case for a "router" socket of some kind.

Yes. That's people who want to use 0MQ as an email. Specify address and 
the message gets there. The "router" or "mail" pattern can be introduced 
for them to use, but it's not easy to implement.

> Group 3) are the people you (Martin) dislike the most based on our many
> discussions. But, look at it optimistically. They will do their thing, and
> some of them will eventually see the light and move on to nice, globally
> scalable, high-level messaging patterns. In the mean time, if we give them
> functionality to do what they want *right now*, they will be happy and get
> us more users, some of which will see the light, and so on and so on :-)

"Dislike" is an overstatement. Using 0MQ as a generic networking 
framework is understandable. However, it conflicts with strict messaging 
patters. That's why the option 1 suggests separating 0MQ into 2 
libraries. The lower layer could look something like this:

     funtions:

     void *socket (context);
     void connect (string);
     void bind (string);
     void send (id, msg);
     void recv (id, msg);

     callbacks:

     void connected (id);
     void disconnected (id);

or something similar, while the upper layer would work as it does now, 
i.e. no connection/disconnection notifications etc.

Obviosuly, the question is whether it's worth of doing given that those 
who want this kind of thing can use ACE/Boost.Asio instead.

Martin



More information about the zeromq-dev mailing list