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 <g...@redhat.com> wrote: > On 07/08/2015 06:23 PM, Rafael Schloming wrote: > >> On Wed, Jul 8, 2015 at 8:58 AM, Gordon Sim <g...@redhat.com> 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 as a hint that the >>> sender may be constrained by capacity limits on the number of >>> deliveries/transfers it is tracking. To send an outgoing window of 0 when >>> there have not yet even been any transfers seems to undermine even that >>> limited value. >>> >>> >> I think the way to look at it under that interpretation is not that the >> sender is not notifying the peer, simply that it is notifying the peer >> asynchronously, and that the transfer is implicitly notifying the peer >> (just like it implicitly advances the next-outgoing-id). >> > > I'm not sure I understand. Asynchronous with respect to what? Are you > saying that a transfer implicitly expands the remote-outgoing-window (but > only if it was 0 before the transfer)? > > One of the few concrete rules specified concerning the outgoing window is > that the remote-outgoing-window "MUST be decremented after every incoming > transfer frame is received, and recomputed when informed of the remote > session endpoint state". If the last information we received was that the > outgoing window was 0, what should we do on then receiving a transfer? >
