On Wed, Jul 8, 2015 at 8:28 AM, iPC <daron...@gmail.com> wrote:
> // 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 deﬁnes the maximum number of outgoing
> transfer frames that the endpoint can currently send. This identiﬁes 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.
That's certainly a fair interpretation, but even under that interpretation
a potential deadlock with service-bus may still exist. Consider an
implementation that sets its initial outgoing window to zero, waits for
credit, and then upon receiving credit expands its window, sends a flow
frame with the updated window, and then sends a transfer. I expect this
implementation would deadlock with service-bus, but I don't think it is
violating the spec under any of the interpretations proposed in this thread.