[zeromq-dev] Feedback on new PATCH socket

Fabien Ninoles fabien.ninoles at ubisoft.com
Fri May 6 22:15:50 CEST 2011

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.  I replace the PULL/PUSH sockets with PUB/SUB, end up receiving the results of everybody (tsunami effect), start to add subscription by gateway (the pub/sub socket pair), and wonder if there wouldn't be an easier way to achieve the same thing.  That's the point where I send you my original email.

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.

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).

Hope this help,


-----Message d'origine-----
De : Martin Sustrik [mailto:sustrik at 250bpm.com] 
Envoyé : 6 mai 2011 15:20
À : ZeroMQ development list
Cc : Fabien Ninoles
Objet : Re: [zeromq-dev] Feedback on new PATCH socket

To do the thing properly we have to understand the new messaging pattern 
in detail.

So, as far as I can say, it's basically a census. One socket, let's call 
it SURVEYOR, publishes a form for participants to fill in. It also 
defines a deadline for the census. The participants, let's call them 
RESPONDENT sockets, fill in the form and send it back to the SURVEYOR. 
All the forms received before the deadline are then passed to the user, 
while those that arrive after the deadline are ignored.

Does that kind of model fit your use case?


More information about the zeromq-dev mailing list