IIRC, the definition of the outgoing-window was largely motivated by the need to express to receivers certain conditions under which they may be required to settle deliveries in order to receive more. For example if an implementation uses a fixed sized array to store deliveries, and this array is keyed by the offset of the delivery-id from the smallest unsettled delivery, then although the sender may have sufficient credit to send more transfers, it may not actually be capable of doing this because the next delivery-id would land outside the range of deliveries that are currently represented within its fixed size array. This could happen for example if the receiver issues N credits (where N is the size of the sender's fixed array) and settles deliveries 2 through N. The sender is then stuck with an unsettled delivery in the first slot of its fixed sized array and cannot send another delivery until that first delivery is settled.
Given this, it's certainly true an outgoing-window of 0 is kind of strange and useless. It's probably also true that it is never super useful for the incoming window of the receiver to be larger than the outgoing window of the sender (or vice versa) since one can't ever exceed the other, so I'd say your largest-possible-int default and max-frame-like treatment are fairly appropriate. --Rafael On Fri, Jul 3, 2015 at 8:57 AM, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > Rob, Rafi, as authors of the spec and the related code in proton, do > you have any thoughts to add here? > > Barring any discussion otherwise I will be looking to change proton to > at least optionally allow controlling the outgoing window along the > lines I mentioned near the end of my original mail. > > Robbie > > On 2 July 2015 at 00:15, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > > Thanks James. Some expansion which may be useful to add. > > > > When comparing the older JMS client, proton-c via the Messenger API, > > and the new JMS client using proton-j, its important to note that they > > aren't all doing the same thing even where their underlying > > implementations do seem to share the same behaviour in the cases of > > proton-c and proton-j. > > > > The older JMS client initializes its outgoing window to a fixed number > > in the session Begin frame and then doesnt seem to ever change it for > > subsequent Flow frames, and simply manages whether its session can > > later send transfer frames based on the current value of the remote > > incoming window. Proton-J and Proton-C similarly only base their > > session level decision to send transfers on the remote incoming window > > and not their own outgoing window (which as noted below means they > > violate their advertised outgoing window, which is often going to be > > 0). > > > > Proton-C and Proton-J both currently look to set the outgoing window > > at any given time to a calculated value based on either the number of > > buffered messages or the buffered bytes divided by frame size. If > > there are no buffered messages at the point the Begin and Flow frames > > are generated, then the outgoing-window will be set to 0. This appears > > to function the same for both proton-c and proton-j. A key point > > though is that I think much of the historic usage of proton-c against > > Service Bus has been via the Messenger API, which works somewhat > > differently than many others in that it looks to create a session and > > a sender and sends the messages in one pipelined sequence of transport > > output, which means that by the point the Begin frame actually gets > > generated there are indeed buffered messages to send which means the > > outgoing-window is initialised to a value greater than zero. Other > > APIs which create the session as a distinct step thus wont ever have > > buffered messages when the Begin frame gets created and so the > > outgoing-window is initialised to 0, which is the behaviour observed > > with the new JMS client using proton-j and also what I saw when trying > > proton-c via the Qpid Messaging C++ client (against qpidd). > > > > Robbie > > > > > > On 1 July 2015 at 20:54, James Birdsall <jb...@microsoft.com> wrote: > >> FYI, I have forwarded this and important bits of the preceding > discussion to our AMQP stack dev within the ServiceBus team. > >> > >> Both the Qpid JMS AMQP 1.0 "legacy" client and Proton-C have been > working fine with Azure SB for years now. Proton-J, however, is not > something we have explored previously, and obviously there is something > different about its behavior compared to the other clients. > >> > >> The Qpid JMS client is our recommended JMS client for interop with > ServiceBus, and we would like to keep up with the times and not have to > direct customers to the legacy client, so we are very interested in > figuring out the correct resolution to this issue. > >> > >> -----Original Message----- > >> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] > >> Sent: Wednesday, July 1, 2015 7:48 AM > >> To: us...@qpid.apache.org; proton@qpid.apache.org > >> Subject: AMQP 1.0 session outgoing-window usage / meaning > >> > >> Hi all, > >> > >> Short intro: > >> > >> The way we use the outgoing-window feels wrong, and seems to violate at > least one bit of the related [and unclear overall] description in the spec. > The way we use it means we currently can't send messages to ServiceBus in > many cases (likely anything-but-messenger). > >> > >> > >> Full version: > >> > >> A user reported being unable to send messages to Service Bus (Azure or > Windows variants) using the new JMS client. Investigating that lead me to > the handling of session outgoing-window in proton (and incoming-window in > ServiceBus). I'd like to discuss how proton uses this, what the spec > actually says on how it should be used since its not clear to me these are > currently in alignment, and possibly changing how we utilise it in proton. > >> > >> In Proton the outgoing-window is set based on the amount of outstanding > outgoing bytes for the session (from buffered sends) and the frame size, > which leads to many situations where the advertised value is 0, > particularly in a client that creates sessions entirely independently from > sending messages (such as a JMS client, or the Qpid Messaging C++ client). > We then send transfer frames if a link has credit, regardless of the > session outgoing window, only withholding them if the > remote-incoming-window hits 0. > >> > >> This causes problems against ServiceBus because it seems to base its > advertised incoming window on the clients [initial] advertised outgoing > window. If it is 0, then it means we can never send any messages. > >> > >> The intent/definition of the outgoing-window seems a bit unclear as a > whole in the spec to me, to the point you could almost remove it without > issue given the [remote-]incoming-window seems to govern overall behaviour. > However, it seems wrong to me that we often set the outgoing-window to 0. > Doing this means we violate the outgoing window (local and at peer) > whenever we send a message if the remote-incoming-window allowed it. If we > tried not to violate it, we would have to flow the new session window > before every send, which again seems odd. > >> > >> It feels to me like it would be better to define initial values for the > windows, perhaps allowing that to be configurable in the same manner as e.g > max frame size is. Those that want to impose some limit then could, and > those that don't can leave/set it to the max values to achieve that effect. > >> > >> Thoughts? > >> > >> Robbie > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
