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

[Pieter Hintjens]

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.

-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.org soon,
> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110903/30ebbd59/attachment.htm>