[zeromq-dev] Non-contiguous message thoughts

[Dhammika Pathirana]

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 <sustrik at 250bpm.com> 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
>