I like msg groups idea, but it sounds more like an application feature. I was thinking about application level framing, adding a msg header, body and checksum. If we can setup different buffers for each msg segment, then sender won't have to create a contiguous block and receiver can avoid having to strip off header and trailer. I suppose this'll be useful for large messages, where copying buffers is a problem.
Dhammika On 3/6/10, Martin Sustrik <[email protected]> wrote: > Michael, > > > > > > > It's less trivial to implement (at very least it would require tweaking > > > the wire protocol), however, the added value is much greater than in the > > > simple iovec case. > > > > > > > Agreed, it certainly seems non-trivial, especially over some of the socket > > types. What did you have in mind for the API on the receiving side? > Would > > the receiver have to know that it is receiving a message group, or would > all > > of the messages be delivered as one large message? Or do you have another > > idea? > > > > I thought of leaving the receiving API as is: > > zmq_recv (&msg1); > zmq_recv (&msg2); > zmq_recv (&msg3); > > Note that as the messages are guaranteed to be delivered atomically in one > go, second and third recv won't ever block. > > Additionally, it's possible to check for 'end of the group' flag: > > bool end = zmq_is_end_of_group (msg); > > However, my feeling is that such a functionality just makes the API more > complex without providing much added value. If needed, the same thing can be > done on application level. > > Martin > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
