[zeromq-dev] multipart message receiving does not work with C++

[Seref Arikan]

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 <cremes.devlist at mac.com> 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 <sustrik at 250bpm.com> 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
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>