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

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.

> 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.


Reply via email to