On 8 July 2015 at 20:13, Rob Godfrey <rob.j.godf...@gmail.com> 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 receiver within > <window size> frames, otherwise the sender will potentially block > until it has received such information. As such the receiver should > always be able to safely set its incoming window to be <= the sender's > outgoing window, since setting it to be larger is pointless. A sender > which finds itself having previously set the outgoing window size to > zero, and finding its peer's incoming window size is also zero must, I > think, send a flow indicating that its window size is now non-zero. > > Having said that I'm not sure I ever saw much utility in this value > and as such I would agree that implementations should probably just > set the default outgoing window size to a large number, and ignore > their peer's outgoing window when setting their own incoming window. > About the only thing that we probably should be doing is ensuring that > if the implied outgoing window of the peer is zero, but might open up > if a flow informing the peer of the updated state, then such a flow > should be sent. (Not sure I would set to MAX_INT in case anyone is > trying to create an array based on the provided size upon receipt... > but that's just me). > > -- Rob >
I did wonder if setting it that large was too large (though its only half the allowed value)...but decided its a bit difficult to pick a 'large enough to forget it exists, but not too large' number, and just ensured it is configurable in case needed. > > > On 8 July 2015 at 20:46, Xin Chen <daron...@gmail.com> wrote: >> 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? >>>
