[zeromq-dev] Multi-part messages

Martin Lucina mato at kotelna.sk
Wed Mar 31 10:51:09 CEST 2010


Martin, 

sustrik at 250bpm.com said:
> >> zmq_msg_t msg;
> >> ...
> >> int tbc = msg.flags & ZMQ_MSG_TBC ? 1 : 0;
> > 
> > I guess this is the API then :)  I will think about how to represent
> > this in Python.
> 
> Any idea is welcome. I've made up a list of requirements to figure out 
> how the API should look like:

We should define this ASAP. Your suggesting the workaround that people peek
inside zmq_msg_t is just horrible and we really don't want to go that way.
Ever. It directly contradicts all of the documentation which explicitly
tells people to never access a zmq_msg_t directly.

I'd like to propose the following:

1) We see that "message options" is a possible extension point. So, let's
define it with zmq_getmsgopt() and zmq_setmsgopt(). Even if we don't use it
for anything other than ZMQ_MSG_MORE for the next two years, at least it's
defined.

2) Given the above, the construct

    zmq_getmsgopt (&msg, ZMQ_MSG_MORE, &have_more, sizeof have_more);
    
is going to be used extremely frequently. So, we define an additional
*alias* which is

    int /* (boolean TRUE/FALSE) */ zmq_msg_more (&msg);

this is not inconsistent with the other zmq_msg_* functions such as
zmq_msg_size (), and leads to a nice way of expressing code such as

    do {
        rc = zmq_recv (socket, &msg, 0);
        /* process message part */
    } while (zmq_msg_more (&msg));

I think that this fulfills all your defined requirements nicely and can map
to OO-style language bindings also as msg.more().

Cheers,

-mato



More information about the zeromq-dev mailing list