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

[Paul Colomiets]

On Wed, Jun 15, 2011 at 12:06 PM, Pieter Hintjens <ph at imatix.com> wrote:
> Hi all,
>
> Following some discussion on IRC about reviewing the REQ/REP designs,
> I'd like to measure how people are using these. So, a short survey,
> please answer inline, if you can.
>
> 1. Are you using ROUTER (XREP) sockets in custom devices or brokers?
>
Probably yes. If you think of zerogw as a broker, a cross-protocol broker
actually. Also planning to write another broker for reliability and
load-balancing.

> 2. Are you using ROUTER sockets in end-nodes (application code)? If
> so, can you explain how and why?
>
Yes, when writing asynchronous aplications. Usually no for synchronous.
We are trying to use monitoring to restart processes, and detect
crashed nodes. Until we will implement or own load-balancing.

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

Yes. Always instead REQ. To have a timeouts on request.

> 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?
>
Yes. Currently queue device. We need that for many to many connections
to cut total number of TCP streams from tens of thouthands to hundreds.
Also eases configuration. Also planning to implement own device for
reliability and better load-balancing.

> 5. How do you handle failures (lost requests or replies)?
>
Timing out and either resending request or propagating failure
depending of type of the request.

> 6. Anything you feel is missing or inadequate in the REQ/REP designs?
> Please explain with a use case.
>
Wrote a lot about that. Req/Rep is almost unusable, but failure is different
for each one.

For REQ inability to recover from failure/timeout
(I've seen some mentions of timeouts in ml, are they implemented?).

For REP it's inability to send presence/heartbeat/status update info.
The best solution is use pub/sub pair for that, but there are drawbacks:
1. increased traffic, BTW sending info that is usually already known,
unless process crashed or something  happened
2. another port, which makes configuration complex (we use from two
to five different request-reply services on each of our quite small projects,
each service also has several nodes, and that's not counting other
patterns, so adding another layer of complexity is quite distracting).
3. unable to report presence immediately, only on next heartbeat (we
don't know when reconnect takes place in zeromq)

I guess usecases are quite clear from above.

-- 
Paul