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

[Fabien Niñoles]

2011/5/24 Martin Sustrik <sustrik at 250bpm.com>:
> Hi Fabien,
>
>>> 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?

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

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

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

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

Fabien