[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