On Sat, Jan 21, 2012 at 16:29, Martin Sustrik <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
