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

Pieter Hintjens ph at imatix.com
Tue Sep 6 00:23:16 CEST 2011

On Monday, September 5, 2011, MinRK wrote:

> 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)?

This gets my vote too. The model that seems to be cleanest is that we have
multiple parts, indicated by SNDMORE, and these parts can be labels,
indicated by SNDLABEL, or data parts. Otherwise it is becomes quite messy.
What does zmq_msg_t hold? A label? A part? A message? A data part?

> 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.

Someone needs to rewrite the LRU queue pattern using the new ROUTER socket.
I'll have a go at this if possible. We need running code to prove the new
design in any case. When LRU queue works, the other router patterns should
be clearer.

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.

If labels are a strict subclass of "message part", this becomes possible.
But it's still conceptually too complex IMO. One does not put addressing
inside the envelope.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110906/5d77bb95/attachment.htm>

More information about the zeromq-dev mailing list