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

[Martin Sustrik]

On 05/25/2011 06:02 AM, Fabien Niñoles wrote:

>>> 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?
>
> Just for the sake of simplicity: it transforms a simple two steps FSM
> (while (MORE) continue...) that
> can't be wrong (there is no way to put a wrong more flag) into a more
> complex three states FSM
> (LABEL part, MORE part, FINAL frame) with possibility of failure
> everywhere except the first frame.
>
> Maybe there is a way around, allowing the message to be easily check
> or very hard to break but I can't
> see how in the current code.

IIRC there's a code doing something like that in the codebase:

https://github.com/zeromq/libzmq/commit/da1ef4d2685c02e8320847d49a38726b2b6d52f0

It's a hack as it drops malformed message rather than the connection, 
but it's better than nothing.

> And even worse, I find out the current
> LABEL flag force you to use to keep the msg_t
> structure (which should be called frame_t correctly) around for
> implementing stuff like the LRU routing.
> You can't used your own buffer for this anymore (with this patch).

You can do the same thing that you do with MORE (ZMQ_SNDMORE, 
ZMQ_RECVMORE => ZMQ_SNDLABEL, ZMQ_RCVLABEL).

>>> 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.
>
> And probably more important: not at all compatible with the current
> BSD socket API.

To be precise: Not backward complatible with current 0MQ API, but 
perfectly compatible with POSIX socket API.

> Still, I don't see anything blocking to have a special API allowing to
> gathered all message parts
> together, flags included and allow you to manage the labels more
> transparently.  This API would
> be clearly of a lower level since it would be used only for device (I
> can't see no reason to use it
> at endpoints).

You can do that on top of existing API, no need to get into the core. 
Avoiding feature creep is a good thing.

>>> 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 user.
>>
>> X-style sockets are meant to be the lower layer of the stack, where the
>> labels are visible.
>
> If we can find a way to implement LRU routing (and similar, like the
> COLLECTOR pattern)
> without passing the labeled frames to the user, I would be very happy
> to let the code ensure
> that no labeled frames is going out from those sockets everywhere.  I
> just can't see how
> right now.

Exactly the same algorithm REQ and REP sockets are using now. REQ takes 
an unlabaled message, labels it, REP gets the labeled request, stips it 
off and reattaches it to the reply. REQ finally strips the labels from 
the reply. User never sees any label.

Martin