On 8 July 2015 at 20:13, Rob Godfrey wrote:
> As far as I can recall/reconstruct the only utility given by the
> outgoing window was so that the sender (of transfer frames) can
> indicate to the receiver (of transfer frames) that it will require
> notification of which frames have been seen by the
As far as I can recall/reconstruct the only utility given by the
outgoing window was so that the sender (of transfer frames) can
indicate to the receiver (of transfer frames) that it will require
notification of which frames have been seen by the receiver within
frames, otherwise the sender will p
I think one safe thing to do now is to ignore this field. I will update
service bus to not setting incoming window based on the received outgoing
window field. This is the only time we look at this value.
On Wed, Jul 8, 2015 at 10:58 AM, Gordon Sim wrote:
> On 07/08/2015 06:23 PM, Rafael Schlom
On 07/08/2015 06:23 PM, Rafael Schloming wrote:
On Wed, Jul 8, 2015 at 8:58 AM, Gordon Sim wrote:
Under your interpretation - i.e. where the sender can change the value of
the outgoing window without ever having to inform the receiver - the
outgoing window seems to have very little value except
On Wed, Jul 8, 2015 at 8:58 AM, Gordon Sim wrote:
> On 07/08/2015 03:49 PM, Rafael Schloming wrote:
>
>> I think what is confusing about the spec language is that it is defining
>> the meaning of the value in terms of the sending endpoint's state and then
>> not saying anything about when the sen
On 8 July 2015 at 17:59, Rafael Schloming wrote:
> On Wed, Jul 8, 2015 at 8:29 AM, Robbie Gemmell
> wrote:
>
>> The wording of "This identifies a current maximum outgoing transfer-id
>> that can be computed by subtracting one from the sum of
>> outgoing-window and next-outgoing-id." when describi
On Wed, Jul 8, 2015 at 8:29 AM, Robbie Gemmell
wrote:
> The wording of "This identifies a current maximum outgoing transfer-id
> that can be computed by subtracting one from the sum of
> outgoing-window and next-outgoing-id." when describing it, coupled
> with the requirement for the peer session
On Wed, Jul 8, 2015 at 8:28 AM, iPC wrote:
> // quotes from the spec ---
> 2.5.6 Session Flow Control
> The Session Endpoint assigns each outgoing transfer frame an implicit
> transfer-id from a session scoped sequence.
>
> outgoing-window: The outgoing-window defines the maximum number of outgoin
On 07/08/2015 03:49 PM, Rafael Schloming wrote:
I think what is confusing about the spec language is that it is defining
the meaning of the value in terms of the sending endpoint's state and then
not saying anything about when the sending endpoint is obligated to
communicate the value to the rece
On 8 July 2015 at 16:03, Rafael Schloming wrote:
> On Wed, Jul 8, 2015 at 2:38 AM, Robbie Gemmell
> wrote:
>
>> On 8 July 2015 at 10:03, Gordon Sim wrote:
>> > On 07/08/2015 02:22 AM, Rafael Schloming wrote:
>> >>
>> >> a value of zero is actually what
>> >> signals that the receiver needs to ta
On 8 July 2015 at 15:49, Rafael Schloming wrote:
> On Wed, Jul 8, 2015 at 2:03 AM, Gordon Sim wrote:
>
>> On 07/08/2015 02:22 AM, Rafael Schloming wrote:
>>
>>> a value of zero is actually what
>>> signals that the receiver needs to take some action here, and arguably an
>>> initial value of zero
// quotes from the spec ---
2.5.6 Session Flow Control
The Session Endpoint assigns each outgoing transfer frame an implicit
transfer-id from a session scoped sequence.
outgoing-window: The outgoing-window defines the maximum number of outgoing
transfer frames that the endpoint can currently send.
On Wed, Jul 8, 2015 at 2:38 AM, Robbie Gemmell
wrote:
> On 8 July 2015 at 10:03, Gordon Sim wrote:
> > On 07/08/2015 02:22 AM, Rafael Schloming wrote:
> >>
> >> a value of zero is actually what
> >> signals that the receiver needs to take some action here, and arguably
> an
> >> initial value of
On Wed, Jul 8, 2015 at 2:03 AM, Gordon Sim wrote:
> On 07/08/2015 02:22 AM, Rafael Schloming wrote:
>
>> a value of zero is actually what
>> signals that the receiver needs to take some action here, and arguably an
>> initial value of zero is correct since it is signaling that the receiver
>> nee
On 8 July 2015 at 10:03, Gordon Sim wrote:
> On 07/08/2015 02:22 AM, Rafael Schloming wrote:
>>
>> a value of zero is actually what
>> signals that the receiver needs to take some action here, and arguably an
>> initial value of zero is correct since it is signaling that the receiver
>> needs to t
On 07/08/2015 02:22 AM, Rafael Schloming wrote:
a value of zero is actually what
signals that the receiver needs to take some action here, and arguably an
initial value of zero is correct since it is signaling that the receiver
needs to take action (in this case issue credit).
My interpretation
On Tue, Jul 7, 2015 at 4:29 AM, Gordon Sim wrote:
> On 07/07/2015 07:22 AM, Rafael Schloming wrote:
>
>> IIRC, the definition of the outgoing-window was largely motivated by the
>> need to express to receivers certain conditions under which they may be
>> required to settle deliveries in order to
On 7 July 2015 at 07:22, Rafael Schloming wrote:
> IIRC, the definition of the outgoing-window was largely motivated by the
> need to express to receivers certain conditions under which they may be
> required to settle deliveries in order to receive more. For example if an
> implementation uses a
On 07/07/2015 07:22 AM, Rafael Schloming wrote:
IIRC, the definition of the outgoing-window was largely motivated by the
need to express to receivers certain conditions under which they may be
required to settle deliveries in order to receive more. For example if an
implementation uses a fixed si
IIRC, the definition of the outgoing-window was largely motivated by the
need to express to receivers certain conditions under which they may be
required to settle deliveries in order to receive more. For example if an
implementation uses a fixed sized array to store deliveries, and this array
is k
Rob, Rafi, as authors of the spec and the related code in proton, do
you have any thoughts to add here?
Barring any discussion otherwise I will be looking to change proton to
at least optionally allow controlling the outgoing window along the
lines I mentioned near the end of my original mail.
Ro
Yes, that's a good point: all our work with Proton-C to date has been via the
Messenger API.
-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
Sent: Wednesday, July 1, 2015 4:16 PM
To: proton@qpid.apache.org
Cc: us...@qpid.apache.org
Subject: Re: AMQP 1.0 se
Thanks James. Some expansion which may be useful to add.
When comparing the older JMS client, proton-c via the Messenger API,
and the new JMS client using proton-j, its important to note that they
aren't all doing the same thing even where their underlying
implementations do seem to share the same
FYI, I have forwarded this and important bits of the preceding discussion to
our AMQP stack dev within the ServiceBus team.
Both the Qpid JMS AMQP 1.0 "legacy" client and Proton-C have been working fine
with Azure SB for years now. Proton-J, however, is not something we have
explored previously
24 matches
Mail list logo
