On Wed, Jul 8, 2015 at 2:03 AM, Gordon Sim <[email protected]> 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. > > 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 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
