[zeromq-dev] XREP/ROUTER no longer receive messages atomically in 3.0/4.0

[Martin Sustrik]

On 09/06/2011 12:23 AM, Pieter Hintjens wrote:
> On Monday, September 5, 2011, MinRK wrote:
>
>     Okay, then I will put my official vote behind making RCVMORE as the
>     sole-indicator of a contiguous message.  This would mean that any
>     time LABEL is set, MORE is also set (if I understand LABEL
>     correctly).  Perhaps this would mean SNDLABEL=6, rather thank
>     SNDLABEL=4, as it implies SNDMORE (2)?
>
>
> This gets my vote too. The model that seems to be cleanest is that we
> have multiple parts, indicated by SNDMORE, and these parts can be
> labels, indicated by SNDLABEL, or data parts. Otherwise it is becomes
> quite messy. What does zmq_msg_t hold? A label? A part? A message? A
> data part?

The problem here is layering.

The multi-part messages were originally introduced to help with 
multi-hop request/reply (sticking the identities to the message).

Unfortunately, these were also exposed to the user, which created 
situation where the feature has no clear place in the protocol stack.

It's used on 0MQ level -- which should mean that it should be invisible 
to the endpoint applications.

It's used on application level -- which should mean that it's invisible 
to 0MQ.

The simplest way to deal with mislayering would be to disable 
application level multi-parts  in 0MQ entirely (no more MORE) and use it 
only internally (LABELs). Optionally, an library could be added on top 
of 0MQ to emulate the application-level multi-parts.

The above solution would cause backward compatibility problems however.

Thus, the current design tries to cut a compromise between clear 
layering and backward compatibility. It's not perfect, but at least it 
doesn't require lower layers (0mq as such) to deal with upper layers' 
protocol entities (MORE).

Martin