[zeromq-dev] Survey: use of 0MQ request reply

Fabien Niñoles fabien.ninoles at gmail.com
Sun Jun 19 04:00:10 CEST 2011

> 1. Are you using ROUTER (XREP) sockets in custom devices or brokers?

Yes, as an MRU queue (yes, Most Recently Used to favorise Caching and also
detect dormant servers), and for the Collector pattern (a variation of
the LRU queue
that publish to all ready sockets at first).

> 2. Are you using ROUTER sockets in end-nodes (application code)? If
> so, can you explain how and why?


> 3. Are you using DEALER sockets in end-nodes? If so, can you explain
> how and why?

Yes, to bridge between a home-made fair-queue of request (not using

> 4. Are you using the REQ-REP multi-hop functionality, either with a
> queue device, or a custom device? Can you explain how and why?

Basically, we used the multihop to create broker and proxies where
required, including
redundant routing in case one broker goes down.  It also help to
cluster configuration, the brokers
being the only one know by all nodes.

> 5. How do you handle failures (lost requests or replies)?

Right now, we only have timeout on request, with the client side
dealing with repeating the request or not.  We will probably
concentrate on HA instead of per request reliability.

> 6. Anything you feel is missing or inadequate in the REQ/REP designs?
> Please explain with a use case.

Confusion in the purpose.  REQ/REP, combined with QUEUE devices, seems
to be a fairly solid end-to-end pattern.  ROUTER/DEALER seems to be
more low-level stuff, but with a lot of possibilities.  At one point,
I wonder if libzmq should concentrate in making very nice but basic
queued sockets and transport (like PUSH, PULL, PUB, PAIR...), and
leave the higher level patterns (like REQ, REP, SUB, PUB, ) to czmq or
something in between.  This would allow the higher devices to be more
robusts without impairing people to go to the lowest level and create
their own patterns.

Briefly, if this can kind be described in term of a protocol over a
ZMTP transport, it probably doesn'nt belong to libzmq but to a higher
level library.


More information about the zeromq-dev mailing list