Hello all,
> Application level multi-part messages are one of the killer features
> of 0MQ. Without them our usage of 0MQ would be nearly impossible.
> PLEASE don't remove them.
>
I fully agree with this request.
Please don't remove them.
Emmanuel
__
On Sat, Sep 17, 2011 at 11:52 PM, Martin Sustrik wrote:
> On 09/06/2011 12:23 AM, Pieter Hintjens wrote:
>> 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
Hi Chuck,
>> The multi-part messages were originally introduced to help with
>> multi-hop request/reply (sticking the identities to the message).
>
> I thought it was *also* intended to better support zerocopy and
> scatter-gather scenarios for sending data. If we go back to only
> allowing a sing
On Sep 18, 2011, at 1:52 AM, Martin Sustrik wrote:
> On 09/06/2011 12:23 AM, Pieter Hintjens wrote:
>> 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
>
On 09/06/2011 12:23 AM, Pieter Hintjens wrote:
> 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
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, rath
>> 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 contiguo
On Sun, Sep 4, 2011 at 03:53, Pieter Hintjens wrote:
> On Sat, Sep 3, 2011 at 8:48 PM, MinRK wrote:
>
> > 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-
On Sat, Sep 3, 2011 at 8:48 PM, MinRK wrote:
> 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
On Sat, Sep 3, 2011 at 09:23, Pieter Hintjens 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
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" wrote:
> And, as soon as I sent that I scanned through unread emails on-list, and I
>
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.getsock
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)
me
13 matches
Mail list logo
