[zeromq-dev] [PATCH] Add msg_t::label flag

Martin Sustrik sustrik at 250bpm.com
Mon May 23 08:15:31 CEST 2011


Hi Fabien,

>> +Bit 1 (LABEL): _This message part is not part of the original
>> +message._ A value of 1 indicate a message part that weren't part
>> of +the original stream.   They are used internally by the
>> transport to +indicate, for example, the origin of a message. +
>> +Bits 2-7: _Reserved_. Bits 1-7 are reserved for future expansion
>> and MUST be set to zero.
>>
>> It should be explained how LABEL flag interacts with MORE flag. I
>> would propose something like this:
>>
>> 1. Labels always occur at the beginning of the message. If label
>> appears elsewhere in the message, the message is malformed.
>
> In present use-case (routing), that's true.  Not so sure about future
> use-case but I can't tell why it couldn't be always as start
> neither.

It's matter of good design. Message envelope dispersed throughout the 
message violates clean layering. Additionally, it is a nightmare to 
parse at wire speed.

>> 2. Labels never have MORE flags set. Combination of LAVEL and MORE
>> on the same message part makes the message malformed.
>
> Make it harder to implement queuing device and require the flag to be
> either exposed externally or to change the behavior of the
> ZMQ_RCVMORE getsockopt.  Also, mutually exclusive flags are usually a
> bad smell (mean they lack orthogonality).  So, -1 for me here.

The orthogonality is what should be deliberately avoided here. Note that 
LABEL flag and MORE flag live at different layers. LABEL flag is 0MQ 
flag, while MORE is an application flag. You can think of it as 
user-defined multi-part message being taken as atomic unit and labeled 
with various labels by 0MQ. The two should never overlap.

Unfortunately, backward compatibility concerns force us to mix the two 
flags in a single layer, which makes the above non-obvious.

Martin



More information about the zeromq-dev mailing list