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

Martin Sustrik sustrik at 250bpm.com
Sun Sep 18 21:06:44 CEST 2011

Hi Chuck,

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

Not necessarily. You can use standard POSIX gather/scatter arrays.

>> 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 design of the new ROUTER socket stems from the fact that most people 
find implementing new patterns inside 0MQ core too complex to handle. 
Thus the ROUTER socket is kind of an "internal" API that allows you to 
plug into 0MQ's internals and define messaging patterns of your own.

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

The reason is that labeling is on 0MQ layer which, quite obviously, 
lives beneath the application layer (multi-part messages). Thus the 
labeling protocol should have no idea of details of the application 
protocol carried on top of it, same way as TCP has no idea whether it's 
XML passed on top of it or JSON.


More information about the zeromq-dev mailing list