[zeromq-dev] Multi-part messages

Martin Sustrik sustrik at 250bpm.com
Tue Apr 6 22:11:11 CEST 2010

Steven, Mato,

As for the idea to change message from flat byte array to an object, I 
would say it's the best way to make users hate us :|

zmq_recvmsg idea is much better, but still, it bloats the API and if 
there's a way to avoid adding new function we should at least take it 
into consideration.

Sure that my proposal feels wrong! Anyone who has a look at wire 
protocol understands that ZMQ_MORE is a property of message rather than 
property of the socket.

However, try to forget about the wire protocol and give the whole issue 
a look from a little distance:

Messages are atomic objects and thus you'll never have two messages 
interleaved when accessing them via 0MQ socket. In other words, if you 
get a first part of the message you can safely retrieve remaining parts 
without any further need for checking or waiting

Given the above you can think of a socket as a simple state machine. 
It's in one of two distinct states: One of them is "ready to retrieve 
new message" other one is "in process of reading a multi-part message".

Now think of getting ZMQ_MORE socket option as retrieving the state of 
socket state machine. Suddenly it doesn't feel that wrong.

Same logic applies to sending messages. ZMQ_MORE option is used to 
switch socket's state machine between "ready for sending new message" 
and "in process of sending a multi-part message" states.

Main appeal of the solution - however - is it's simplicity. Firstly, 
there's no impact wahtsoever on how single-part messages are handled. 
Secondly, it doesn't introduce any new APIs. Instead it just uses 
existing extension points.



Steven McCoy wrote:
> On 6 April 2010 22:09, Martin Lucina <mato at kotelna.sk 
> <mailto:mato at kotelna.sk>> wrote:
>     sustrik at 250bpm.com <mailto:sustrik at 250bpm.com> said:
>      > What about this:
>      >
>      >      ...
>      >      zmq_recv (s, &msg, 0);
>      >      int more;
>      >      getsockopt (s, ZMQ_MORE, &more);
>      >      if (more) ...
>      >
>      > In other words, to make "has more undelivered message parts" a
>     property
>      > of the receiving socket.
>     That just feels wrong...
> Try to leverage existing APIs, the recvmsg() seems most appropriate.
> struct zmq_msghdr {
>   void* zmsg_buf
>   size_t zmsg_len;
>   int  zmsg_flags;
> } msgh;
> zmq_recvmsg (s, &msgh);
> if (msgh.zmsg_flags & ZMQ_MORE) {
> ...
> }
> -- 
> Steve-o 
> ------------------------------------------------------------------------
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list