[zeromq-dev] Improving message patterns

[Martin Sustrik]

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