> 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? No. > 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 ZMQ) and a ZMQ QUEUE. > 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. Fabien _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
