On 8 July 2015 at 15:49, Rafael Schloming <r...@alum.mit.edu> wrote: > On Wed, Jul 8, 2015 at 2:03 AM, 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. >> > > 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 receiver. This is because (at least as > originally conceived) it is never directly obligated to communicate the > value to the receiver, i.e. it could just choose to grow its array > indefinitely. > > By contrast the incoming-window is defined in terms of the receiver's > endpoint state and it is (relatively) clearly communicated that the > receiver is obligated to communicate a non-zero incoming-window if it > wishes to receive transfer frames. > > So while I agree that the language as defined requires the outgoing window > to be increased from zero, I don't think this implies (at least without a > more careful reading) that the sender needs to communicate this fact before > sending transfers. It owns the value so it can effectively increase the > outgoing-window to 1 momentarily, send the transfer, and then decrease it > back to zero without needing to sandwich that transfer in flow frames in > order to signal the changing window values. > > Put another way, the rule that says it is illegal for the sender to send > transfers when the receiver's incoming window is zero creates an obligation > for the receiver to communicate its window, but there is no corresponding > rule for the receiver, e.g. nothing says it is illegal for the receiver to > send credit when the sender's outgoing-window is zero, nor that the > receiver must compute it's incoming-window based on the sender's > outgoing-window, so there is no obligation similarly implied for the sender. >
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 to track it and decrement the remote-outgoing-window when receiving transfers, does suggest to me that things above the advertised point should not be sent (without first asynchronously communicating an increaseat least) since it would define a 'maximum' below the next-outgoing-id. On the other hand, you are right that it doesnt explicitly define when we need to update the peer, and there is a specific error condition symbol for when the peer exceeds the incoming window but there is no equivalent condition for doing the same with the outgoing window. I think the wording is wooly enough we could be here for a while figuring it out and still end up being unsure what it actually says though :) > >> >> 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). >> > > I agree that we shouldn't do this in our implementation, however I think it > is a valid interpretation, which implies that making the incoming window > dependent on your peers outgoing window (as service-bus is doing) is > probably not a safe thing to do. > > >> >> 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. >> > > Per above I don't believe it is violating the spec, but given that it has > been misinterpreted at least once, I certainly agree that some behavior > change is warranted. I think Gordon is meaning in regard to the fact that we send a transfer when our outgoing window is [initially] 0 without first increasing it to e.g.1, due to the use of the phrasing I mentioned earlier that defines a "maximum" id below our [initial] next outgoing id. If so, I tend to share his view on that. Ultimately I think we just set a big window and essentially forgot it exists for now, we aren't using it at all within proton currently after all. We might as well stop calculating the remote value given we never actually read it. > I don't think we should do the max-frame-size thing > though as this encourages the notion that the incoming-window is somehow > dependent on the outgoing-window which as I said above is I think unsafe. > > I guess setting it to a large constant for now is fairly reasonable, but I > do think we should encourage service-bus to make its implementation more > robust in this regard. > > --Rafael Can I take that as a +1 on the approach I proposed changes for on PROTON-936 / https://github.com/apache/qpid-proton/pull/42 ? Robbie
