[zeromq-dev] Feedback on new PATCH socket

Martin Sustrik sustrik at 250bpm.com
Sat May 7 10:49:19 CEST 2011

On 05/06/2011 10:15 PM, Fabien Ninoles wrote:
> Census is just one example.  It's more a "chain of command" pattern
> where one or multiple GOVERNOR can send a command, to one or multiple
> WORKERS that obeys and send the results back.  In fact, my primary
> example were a parallel pipeline where everybody work on the same
> task.

Is that meant to implement the hot/hot failover?

> There is no many sockets able to do a bidirectional pattern, and two
> of them, the most natural choice for end point, can't be used if the
> pattern is asymetric (more replies than requests).  Adding and remove
> the delimiter is a bit artificial but since ROUTER is part of a lot
> of pattern in the Guide, with all the same requirement of adding the
> delimiter, I wonder why it couldn't be part of the standard socket.

This is part of the XREP vs. ROUTER confusion. XREP cannot add delimiter 
because it's meant to reside in the middle of the topology, forwarding 
request and replies to the next hop.

> For the AREP (one reply, many answers), I agree that a DEALER/REP
> pairing is probably a better usage, although is quite symmetric to
> the AREQ socket and I could probably find some interesting usage
> (like multipart reply).

The obvious problem with any one request many replies model is that the 
requester has no idea whether it have got all the answers or not yet. 
Specifically, think of large distributed topologies where at least a 
part of topology is likely to be offline at any given moment.

The only solution seems to be to set a deadline for the replies. The 
user code could then look something like this:

s = socket (SURVEYOR);
zmq_setsockopt (s, ZMQ_DEADLINE, 10);
//  create a request...
zmq_send (s, request, 0);
while (true) {
     zmq_msg_t reply;
     rc = zmq_recv (s, &reply, 0);
     if (rc < 0 && errno = EDEADLINE)
     //  process reply here...


More information about the zeromq-dev mailing list