[zeromq-dev] [PATCH] Add msg_t::label flag
sustrik at 250bpm.com
Tue May 24 18:00:30 CEST 2011
>> 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 ?
Is there any reason why it should not?
>> 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.
Not doable IMO. I should have used scatter/gather arrays instead of
multipart messages from the beginning. Too late to fix that now. We'll
have to live with it.
> 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 ?
Note that non-X-style sockets already do something like that. Say REP
socket removes all the labels from the request before passing it to the
X-style sockets are meant to be the lower layer of the stack, where the
labels are visible.
More information about the zeromq-dev