// 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. 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. // end quotes --- Outgoing-window is a mandatory field on flow. The sender's outgoing window is communicated to the peer. If the sender sends a 0 outgoing window but subsequently sends a transfer frame, the implicit outgoing transfer-id would exceed the limit implied by the flow frame. I agree that the sender can maintain a local outgoing window to satisfy any local implementation specific logic, but the value communicated to the peer must allow further transfer frames to be sent. I don't think it makes senses to use 0 outgoing window to request for credit (assuming it is the link credit mentioned in early mails). Using a 0 link credit would make more sense. On Wed, Jul 8, 2015 at 8:03 AM, Rafael Schloming <r...@alum.mit.edu> wrote: > On Wed, Jul 8, 2015 at 2:38 AM, Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > > > On 8 July 2015 at 10:03, Gordon Sim <g...@redhat.com> 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 take action (in this case issue credit). > > > > > > > > > My interpretation is that if 0 is sent as the initial value, the sender > > > cannot legally send any transfers without first expanding the window by > > > sending a flow with a non-zero value. > > > > > > > Agreed. We don't currently do that, so we are typically violating the > > window (Messenger being an exception, on its initial send to a node at > > least). > > > > In the case the remote incoming window is also 0 (which it is in the > > case which prompted this discussion) we would also have to > > synchronously wait for a flow 'response' increasing it before we could > > send anything, since we also need to know the remote incoming window > > actually enabled us to send. > > > > See my reply to Gordon for more details, but I think we need to be careful > in distinguishing between the rules the spec mandates for > updating/maintaining the value locally, and the rules the spec mandates for > when it is necessary to communicate the value to the peer. These definitely > should not be conflated because you don't want to notify the peer whenever > you update the value locally, this would be way to chatty. > > > > > Further I think the sender should not take the lack of credit as > grounds > > to > > > set a window of 0. The receiver knows it has not issued credit. (At the > > link > > > level, the sender can also indicate that it has messages awaiting link > > > credit). > > > > > > > That was my take on reading things, that the two are essentially > > separate mechanisms, and on top the two windows are separate as well. > > > > If the initial outgoing window was set to 0 because the reciever hasnt > > issued, would there be a need for the field to exist on Begin? It > > would seem like much of the time it wouldnt be used and a Flow would > > have to be used instead. > > > > > In the case where the sender's implementation involves a fixed amount > of > > > buffer space and requires messages to be settled before it can send > more, > > > the receiver would not be able to know that without getting some > signal. > > So > > > to my mind that is the only case for which it would make sense to send > an > > > outgoing window of 0. (I'm not sure how useful this is in practice and > I > > > don't believe it applies to proton at present anyway). > > > > > > I think as it stands proton is violating the spec, and should be > changed > > to > > > send a non-zero outgoing window. > > > > That is what I did for the proposed changes on > > https://issues.apache.org/jira/browse/PROTON-936 / > > https://github.com/apache/qpid-proton/pull/42. Essentially setting it > > initially on begin to max int (unless otherwise configured) and > > leaving it there for any subsequent flows. We could later (when we > > arent right before a release) look to make it smarter if needed. > > > > See my other email for more details, but I agree this seems like a > reasonable change for now. > > --Rafael >
