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 defines the maximum number of outgoing > transfer frames that the endpoint can currently send. 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. > // 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. --Rafael
