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

MinRK benjaminrk at gmail.com
Mon Sep 5 00:20:24 CEST 2011

On Sun, Sep 4, 2011 at 03:53, Pieter Hintjens <ph at imatix.com> wrote:

> On Sat, Sep 3, 2011 at 8:48 PM, MinRK <benjaminrk at gmail.com> wrote:
> > Is the general usage of send/recv flags documented more thorougly
> anywhere?
> >  For instance, with the XREP behavior I would expect RCVLABEL *and*
> > to be set for the routing-prefix part of the message (I understood
> > to be the thread linking a single message), but this was incorrect.
> Yes, this is also what I expected and IMO it's worth arguing this out
> with Martin. Treating labels as a special case makes code more complex
> without any benefit, which is a bad thing IMO.

Okay, then I will put my official vote behind making RCVMORE as the
sole-indicator of a contiguous message.  This would mean that any time LABEL
is set, MORE is also set (if I understand LABEL correctly).  Perhaps this
would mean SNDLABEL=6, rather thank SNDLABEL=4, as it implies SNDMORE (2)?

> > It's
> > also not clear what the SND/RCVCMD flag is to be used for, aside from
> > something to do with ROUTER sockets.
> This is the 4.0 ROUTER design? Since the design is not documented
> upfront (Martin, you really do like to communicate in code, don't you
> :-) I've no idea what this does.

Yes, this is the 4.0 ROUTER, which seems to get CMD messages on the
connection of peers.  I would be very interested in seeing examples of how
the 4.0 ROUTER improves routing compared to the 2.1 ROUTER with IDENTITIES,
as IPython uses ROUTERs with IDENTITIES quite heavily.

> > 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?
> Nope. This should not be allowed IMO.

Okay, that would help simplify my goals of supporting it in recv_multipart.
 Of course, if there is a real case where the LABEL  flag makes sense in the
middle of a message, that's fine too.

> -Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110904/6ac28d4c/attachment.htm>

More information about the zeromq-dev mailing list