[zeromq-dev] XREP/ROUTER no longer receive messages atomically in 3.0/4.0

MinRK benjaminrk at gmail.com
Sat Sep 3 20:48:46 CEST 2011


On Sat, Sep 3, 2011 at 09:23, Pieter Hintjens <pieterh at gmail.com> wrote:

> I'll push new docs to api.zeromq.org asap. Was enjoying the first day of
> summer here in Belgium. We will get the docs updating automatically, all the
> machinery is ready.
>

Thanks,

Is the general usage of send/recv flags documented more thorougly anywhere?
 For instance, with the XREP behavior I would expect RCVLABEL *and* RCVMORE
to be set for the routing-prefix part of the message (I understood RCVMORE
to be the thread linking a single message), but this was incorrect.  It's
also not clear what the SND/RCVCMD flag is to be used for, aside from
something to do with ROUTER sockets.

I am trying to update pyzmq to be aware of these new concepts, and do the
right thing, but without documentation and/or examples I can't figure out
what makes the most sense.

The simplest case seems to be that XREP sockets have a prefix of
LABEL-flagged message parts, followed by some MORE-flagged parts, and a
terminal part.  However, testing reveals that I can set arbitrary
combinations of MORE/LABEL on each message part.  Does it make any sense to
set SNDLABEL in the middle of a message?

I'm principally thinking of pyzmq's socket.send_/recv_multipart supporting
LABEL prefixes naturally, so you could do:

xrep.send_multipart(['msg', 'parts'], prefix=['label', 'prefix'])

and prefix,msg = xrep.recv_multipart()


-MinRK

-Pieter
> On Sep 3, 2011 12:08 AM, "MinRK" <benjaminrk at gmail.com> wrote:
> > And, as soon as I sent that I scanned through unread emails on-list, and
> I
> > saw the recent doc patch on SND/RCVLABEL. So the new way to receive a
> > multipart message with a routing prefix is (in Python):
> >
> > def recv_multipart(s):
> > labels = []
> > while True:
> > m = s.recv()
> > if s.getsockopt(zmq.RCVLABEL):
> > labels.append(m)
> > else:
> > break
> > msg = [m]
> > while s.getsockopt(zmq.RCVMORE):
> > msg.append(s.recv())
> > return labels, msg
> >
> > It would be great if the new Label docs get pushed to api.zeromq.orgsoon,
> > because that would have prevented my confusion and erroneous bug report.
> >
> > -MinRK
> >
> > On Fri, Sep 2, 2011 at 14:37, MinRK <benjaminrk at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> Are multipart messages with routing information (as received by XREP
> and/or
> >> ROUTER sockets) supposed to arrive atomically? Because they are not in
> 3.0
> >> or 4.0.
> >>
> >> * In 3.0 ROUTER/DEALER appear to behave the same as 2.1.x
> >> * XREP receives *at least* two distinct (RCVMORE=False in the middle)
> >> messages for every message sent by a peer
> >> * in 4.0, ROUTER behaves in a similar way to XREP, but with a different
> >> number of distinct prefix messages
> >>
> >> Is this the desired behavior?
> >>
> >> I imagine it could be a simple bug of omitting the RCVMORE flag when
> >> receiving routing prefix messages.
> >>
> >> Example (in C) demonstrating failure of atomicity:
> >> https://gist.github.com/1189941
> >>
> >> -MinRK
> >>
> >>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110903/c4393d7a/attachment.htm>


More information about the zeromq-dev mailing list