[zeromq-dev] [PATCH] Add msg_t::label flag
fabien.ninoles at gmail.com
Wed May 25 06:02:43 CEST 2011
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
>> 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
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
More information about the zeromq-dev