[zeromq-dev] 0MQ/2.0-alpha3 available

Aamir M intuitionist at gmail.com
Tue Sep 29 00:42:12 CEST 2009

HI Martin,
The request / reply socket is described in zmq.h as follows:

//  Socket to send requests and receive replies. Requests are
//  load-balanced among all the peers. This socket type allows
//  only an alternated sequence of send's and recv's
#define ZMQ_REQ 3

This is the "synchronous RPC" case that we discussed earlier. I'm having
some difficultly understanding how the load-balancing can work with the
restriction that only alternated sequences of sends and receives are

Let's say I have 100 cores running, and I want to distribute 100 requests
(and then collect the corresponding 100 replies). If I use ZMQ_REQ then I
will have to wait for the first request to be completed before the second
request can be sent. Wouldn't this mean that only 1 core is ever working at
any given time? If this is true, then it defeats the purpose of
load-balancing the requests and raises a serious question about the
usefulness of ZMQ_REQ and ZMQ_REP?

Using 0MQ 1.0, I implemented an asynchronous request / reply system based on
the load-balancing exchange object. It allows me to send 100 requests to a
load-balancing exchange from a sender thread, without waiting for any
replies. A separate receiver thread listens for replies. As a result I am
able to keep all 100 cores working simultaneously. This design works "well
enough' as long as there is only ever one requester application running
(otherwise the repliers would not know who to send the reply back to). There
is an added difficulty that replies will not arrive in the same order as the
requests were sent, so we need to check the message contents to figure out
which reply corresponds to which request (and whether or not all requests
have been replied to once and only once).  With 0MQ 2.0, there is no concept
of a "load-balancing exchange." Instead there is a ZMQ_REQ socket, but the
ZMQ_REQ is fundamentally different as far as I can tell. So, as it is, I
would not be able to migrate my code to 0MQ 2.0.

I think the simplest thing to do is to just have a load-balancing version of
ZMQ_PUB that only supports sends (which is very similar to the
load-balancing exchange concept). An added layer of complexity would be for
the 0MQ infrastructure to support routing asynchronous replies based on some
kind of "reply-to" field contained in the corresponding request message (I
think this is a network-layer issue and would ideally be supported by 0MQ).
A further layer of complexity is to use the message contents to re-order the
replies so that they are in the same order in which the corresponding
requests were sent (this seems to be potentially an application-specific
issue that goes beyond the scope of a light-weight messaging library).

I would greatly appreciate your thoughts on this. Thanks in advance for the


On Wed, Sep 23, 2009 at 7:08 AM, Martin Sustrik <sustrik at fastmq.com> wrote:

> Hi all,
> New version of 0MQ/2.0 was released today:
> http://www.zeromq.org/area:download-v20-alpha3
> New features include "multicast bus" and "request/reply sockets".
> Multicast bus allows multiple applications to write and read to/from a
> single multicast group. This is to be opposed to a simple multicast
> scenario with a single sender and multiple receivers.
> Request/reply sockets simplify development of RPC, SOA and client/server
> applications.
> For instance, to create a server application such as web server it's
> sufficient to do the following:
> zmq::context_t ctx (1, 1);
> zmq::socket_t s (ctx, ZMQ_REP);
> s.bind ("tcp://eth0:5555");
> while (true) {
>     zmq::message_t request;
>     s.recv (&request);
>     zmq::message_t reply;
>     ... process the request and construct the reply here ...
>     s.send (reply);
> }
> To create a client application - such as web browser - do the following:
> zmq::context_t ctx (1, 1);
> zmq::socket_t s (ctx, ZMQ_REQ);
> s.connect ("tcp://");
> zmq::message_t request;
> ... construct the request here ...
> s.send (request);
> zmq::message_t reply;
> s.recv (&reply);
> ... process the reply here...
> Enjoy!
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090928/a0cdfa3c/attachment.htm>

More information about the zeromq-dev mailing list