On Wed, Jun 15, 2011 at 12:06 PM, Pieter Hintjens <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
