[zeromq-dev] multi-part messages

Martin Sustrik sustrik at 250bpm.com
Mon Jan 23 00:38:51 CET 2012


Hi all,

I believe this discussion misses what I wanted to say.

There are many issues mixed here:

1. Should 0MQ provide internal message parts?
2. Should 0MQ provide application-level message parts?
3. Expose the functionality as gather-scatter arrays?
4. Should the 0MQ-related parts of the protocol separate from 
application-level parts?

Answer to 1 is yes (because of way REQ/REP works).
Answer to 2 is yes due to the popular demand.
Answer to 3 is no, to preserve backward compatibility.

My point was that the answer for 4 should be "yes" and the fact that it 
is not so is unfortunate.

Too late to fix that, anyway. I've tried with LABELs and failed. 0MQ is 
a stable product and bad design decisions are already baked in. Not much 
we can do about that.

Martin




On 22/01/12 20:51, Brian Granger wrote:
> I should also note that I don't consider multipart messages an
> unfortunately accident.  In my mind they are one of the killer
> features of ZeroMQ that allows it to scale and achieve high
> performance with large amounts of data.  Before ZeroMQ, we had
> struggled for years with the lack of good multipart messages in the
> network protocols we were using.  The idea and implementation are
> brilliant, and Martin definitely gets the credit for this (even if he
> may regret it...).
>
> Cheers,
>
> Brian
>
> On Sun, Jan 22, 2012 at 11:43 AM, Brian Granger<ellisonbg at gmail.com>  wrote:
>> On Sun, Jan 22, 2012 at 7:48 AM, Pieter Hintjens<ph at imatix.com>  wrote:
>>> On Sun, Jan 22, 2012 at 9:36 AM, john skaller
>>> <skaller at users.sourceforge.net>  wrote:
>>>
>>>> The problem is like this: if you use say an array, you can put the
>>>> pieces into it in any temporal order. This allows you to write
>>>> simple code.
>>>
>>> This is an accurate statement of the problem, but the answer doesn't
>>> lie in the low level API. In CZMQ, for instance, we solve this by
>>> treating a "message" as a multipart object (composed of frames), which
>>> we can send and receive in one step, and work with separately, as an
>>> array, list, stack, whatever. It's one of the abstractions I proposed
>>> binding authors should take seriously[1], precisely because the way
>>> applications need to work with frames doesn't match the 0MQ low level
>>> API. More accurately, there is no single application semantic, there
>>> are several.
>>>
>>> So solution: make the language binding smarter.
>>
>> In the Python bindings, dealing with multipart message is nearly
>> trivial most of the time.  They are represented as Python lists and
>> can be sent/recv'd as easily as a single message part.  The only cases
>> where you need to deal with each message part separately is if you
>> need to treat each message part differently - unicode handling
>> differently, some copy/non-copy, etc.
>>
>> Cheers,
>>
>> Brian
>>
>>> -Pieter
>>>
>>> [1] http://www.zeromq.org/topics:binding-abstractions
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>
>
>




More information about the zeromq-dev mailing list