Hi Paul, > Request/reply: > 1. REP socket works only for samples and useless in any real world > application, things it lacks: > 1) publishing presence > 2) heartbeating > 3) ability to discard request > 2. REQ socket is also useless for most applications, because of: > 1) unable to retry request > 3. XREQ lacks support of routing request to a specific destination > 4. XREP is meant as a non-blocking replier socket, but incidentally used for > everything other sockets can't do > 5. Ineficient load-balancing for some applications > > Push/Pull: > 1. No routing to specific destination > 2. Very weak reliability guarantees > 3. Ineficient load-balancing for some applications > > Pub/Sub: > 1. Weak reliability guarantees > 2. Lack of a way to know when message stream was broken > 3. Late joiners problem
Thanks for the detailed list! I am going to reply shortly to some basic issues as replying to everything would be a mess. We can do that later on. 1. Some of the deficiencies and related solutions are non-controversaial. Namely: resending requests in req/rep pattern, using acks in push/pull pattern and subscription forwarding in pub/sub pattern. If anyone wants to help with the implementation, stand up! 2. As for heartbeats, they are an L4 functionality, while 0MQ lives at L5 (L5.5 if you wish). Some underlying L4 transports provide heartbeating (SCTP), some do not (TCP). The generic question is: To what extent is emulating the deficiencies of underlying protocols 0MQ's problem? On one end of the spectrun we can just declare that what underlying protocol provides is what you get. On the other extreme we can try to emulate any possible functionality offered by any possible transport in all the other transports. I personally think that the former makes more sense. We should keep the emulation layer minimal (afaics, all we really need is message delimitation for stream- or packet- based transport protocols). If there's need for TCP with heartbeats, let's devise a TCP-with-heartbeats (TCPH) layer and allow it to be plugged as an underlying transport into 0MQ. Btw, I was investigating the heartbeats on top of TCP a bit and IMO it seems that as long as you want a real solution, as opposed to some kind of toy heartbeats, the task is almost impossible to accomplish. 3. The problem you are trying to address with your MUX socket is a problem of statefull services. It's an valid problem, and one that have been discussed a lot already, however, I would say, before proposing a solution we should understand the problem. Most people want some kind of "route to address" mechanism so that they can send messages to specific instances of services. Once you start working on a solution for that problem you'll find out that you are basically duplicating the IP's routing functionality, distribution of routing tables etc. So the question at the moment is: What exactly should 0MQ provide in this scenario that is not already covered by IP? When we have the answer, it will be much easier to think about the solution. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
