On 8 July 2015 at 16:03, 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.
I agree, you wouldnt waat to do that. To reiterate, I was only saying you would have to do that when both local outgoing and remote incoming were 0, given you would need to hear back about the new remote incoming (to ensure it not being 0) before you could actually send. You could of course asyncronously increase your outgoing window normally if you needed to, it just woudlnt do any good in that special case, which is the scenario we found ourselves to prompt this discussion. > > >> > 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
