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

[Fabien Niñoles]

2011/5/23 Martin Sustrik <sustrik at 250bpm.com>:
> 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.

Ack.  I attach a new patch with the comment.  However, I don't think
the code should
check for this in all occasions, no ?

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

Right on this.  I was thinking about this for the collector, but can't
find a way
to completly removed the flag from the user without giving up the frame division
of ZMQ messages.  May be the next generation of ZMQ API shoud avoid access
to frames internally; basically, pushing all the frames on a msg_t and
have an api to
access only permitted frames ?  Would be useful to check how many
frames a message
is composed and stuff like this, but probably required a more complex
API for memory
management.

Fabien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-msg_t-label-flag.patch
Type: text/x-patch
Size: 20492 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110523/7831cd9f/attachment.bin>