2011/5/24 Martin Sustrik <[email protected]>: > 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
