In some network topologies there are pieces that need to envelope messages, for example so they can be routed correctly:
1. Client sends a message to A 2. A adds a message part which identifies the client 3. A sends the multipart message to B 4. B pops off the added part and processes the original message 5. B creates a reply and pushes back on the extra part and sends it to A 6. A pops off the added part, knowing which client to send the reply, and sends the raw reply If you properly handle multi-part messages, you can create reusable pieces that can be nested indefinitely and fit into larger networks easily. http://zguide.zeromq.org/page:all#Request-Reply-Envelopes -- Patrick Lucas On Sat, Jan 21, 2012 at 08:38, john skaller <[email protected]> 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? > > Is it something to do with reliability (disconnects in the middle of a big > download SUCKS!)? > > -- > john skaller > [email protected] > > > > > _______________________________________________ > 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
