[zeromq-dev] Non-contiguous message thoughts

Michael Santy michael.santy at dynetics.com
Mon Mar 8 20:34:57 CET 2010




On 3/8/10 1:26 PM, "Martin Sustrik" <sustrik at 250bpm.com> wrote:

> Brian Granger wrote:
>> Martin,
>> 
>>> Yes. The field has to be there anyway.
>>> 
>>> We just have to find some suitable name for the accessor function...
>>> 
>>> bool zmq_msg_end (zmq_msg_t *msg);
>> 
>> While this may not be possible in C/C++, in Python, I would be tempted
>> to hide the message group
>> stuff in send/recv:
>> 
>> sock.send([msg1, msg2, msg3])
>> 
>> On the other side:
>> 
>> messages = sock.recv()
> 
> One thing to be considered is keeping the case of single-part message as
> simple as possible (i.e. as simple as it is now) given that this will be
> the case in 99 times of 100.
> 
> message = sock.recv() [0] just doesn't look right.
> 
> 
> One additional issue to think about: In C API sending a multipart
> message involves passing a flag to send function, while receiving a
> multipart message requires checking a flag on message itself. That seems
> somewhat incoherent. Is there a better way? Is there a better way wthout
> making the API sucky?

This time sent to the list...

One thought is to have a more general zmq_multi_send/recv that acted as the
sender/receiver for all of the messages in a group.  For the 99% case where
the messages aren't multipart, it would degenerate into the standard
behavior.

void zmq_multi_recv(void * s, zmq_msg_t * msgs, unsigned int * num_msgs, int
flags);
void zmq_multi_send(void * s, zmq_msg_t * msgs, unsigned int * num_msgs, int
flags);

Mike




More information about the zeromq-dev mailing list