[zeromq-dev] multi-part messages

MinRK benjaminrk at gmail.com
Sun Jan 22 10:07:30 CET 2012


On Sat, Jan 21, 2012 at 16:29, Martin Sustrik <sustrik at 250bpm.com> wrote:
> On 21/01/12 14:38, john skaller wrote:
>> Why?
>>
>> I can't see what it does. Since there's no transmission until all the parts are collated
>> and no reception until all the parts are collated .. what's wrong with the client
>> doing that and just sending one big message?
>
> The original reason for introducing multi-part messages was (as Patrick
> correctly explains) to allow for requests messages to gather the list of
> nodes it have travelled through, so that corresponding reply message can
> travel in the opposite direction.
>
> Unfortunately, this functionality, aside of being used by 0MQ itself,
> was exposed to the end users.

I wish you wouldn't refer to the existence of multipart messages as
'unfortunate'.  It's *hugely* valuable
in high level bindings like Python for allowing zero-copy with
multiple buffers in a single message, or even
just attaching a metadata header to an existing buffer without having
to reserialize or send multiple messages.

-MinRK

>
> That in turn means that application logic is now often mingled with 0MQ
> logic creating a kind of mis-layering problem. Too late to fix that now
> though.
>
> As for zero-copy, as mentioned by Andrew, I guess the standard POSIX
> scatter-gather arrays would be more appropriate.
>
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



More information about the zeromq-dev mailing list