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

[Chuck Remes]

On Sep 18, 2011, at 1:52 AM, Martin Sustrik wrote:

> 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).

I thought it was *also* intended to better support zerocopy and scatter-gather scenarios for sending data. If we go back to only allowing a single message part at the user level then it may force a lot of copying before transmission.


> 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.

I don't think you really mean this. You are currently working on exposing a whole bunch of 0mq "internal" events (connect, disconnect, etc) in the new ROUTER socket type. Why would you create a new layering problem in the 4.0 API if you think that's the wrong thing to do?


> 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).

I don't understand your argument. How does marking a label with the MORE flag break layering? Why is this a problem?

cr