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

Aamir M intuitionist at gmail.com
Tue Sep 29 00:50:57 CEST 2009

Sorry, it just occurred to me that the current ZMQ_REQ load-balancer is
indeed useful in the case where there are many requesting applications doing
one-off synchronous RPC calls that need to be load-balanced. This is
different from the use case I'm thinking of, which is a small number of
requesting applications sending a huge number of requests that need to all
be simultaneously load-balanced. So the problem I have still remains but I
can see why the 2.0 API works this way.

On Mon, Sep 28, 2009 at 6:42 PM, Aamir M <intuitionist at gmail.com> wrote:

> 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
> allowed.
> 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
> help.
> Regards,
> Aamir
> 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/d0d968ec/attachment.htm>

More information about the zeromq-dev mailing list