Hi Chuck, Thanks for the feedback. I've made my code work with multipart messages, and it is quite fast. It is quite flexible this way, so I'll keep it :)
On Thu, Jun 2, 2011 at 3:14 PM, Chuck Remes <[email protected]> wrote: > There is no reason to avoid using multi-part messages. I think they are a > great way to logically separate different components of a complex message so > I use them in that way pretty regularly. > > 0mq guarantees that all parts will be made available atomically. This means > that if you send a message with N parts, all N will be delivered or *none* of > them will be delivered. > > I have not seen any measurable performance issue with them. You could > probably write a simple benchmark to show what kind of overhead they incur. > If you need to serialize each message part separately (e.g. protocol buffers, > json, whatever) then the primary overhead is likely to be the invocation of > the serializer. > > cr > > On Jun 2, 2011, at 9:06 AM, Seref Arikan wrote: > >> Hi Martin, >> Indeed this would be a solution, and Jashua has kindly provided a link >> for a way to do this. I'm using protocol buffers in a complicated >> wrapper scenario, and in general I'd like to get multipart messaging >> up and running, since it feels as if it will offer more flexibility. >> Given my current setup, multipart messages is method that offers >> shorter time to functionality required. >> >> Any reason I should avoid multipart messages? Performance? Stability? >> >> On Thu, Jun 2, 2011 at 11:53 AM, Martin Sustrik <[email protected]> wrote: >>> On 06/02/2011 11:37 AM, Seref Arikan wrote: >>>> >>>> I'm already using protocol buffers. The thing is, I can be passing >>>> around any protocol buffer serialization; so I need an envelope to >>>> tell the receiving party about the type of the message. >>>> I'm using multipart messages to pass two protocol buffer >>>> serializations; first one that contains data regarding the whole >>>> message, the second one, actual payload of the message. >>>> I'm happy to hear other approaches to handle this. >>> >>> Why not simply serialise both envelope and data using protocol buffers? >>> >>> 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 > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
