On 8 July 2015 at 17:59, Rafael Schloming <r...@alum.mit.edu> wrote: > On Wed, Jul 8, 2015 at 8:29 AM, Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > >> The wording of "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." when describing it, coupled >> with the requirement for the peer session to track it and decrement >> the remote-outgoing-window when receiving transfers, does suggest to >> me that things above the advertised point should not be sent (without >> first asynchronously communicating an increaseat least) since it would >> define a 'maximum' below the next-outgoing-id. >> >> On the other hand, you are right that it doesnt explicitly define when >> we need to update the peer, and there is a specific error condition >> symbol for when the peer exceeds the incoming window but there is no >> equivalent condition for doing the same with the outgoing window. >> >> I think the wording is wooly enough we could be here for a while >> figuring it out and still end up being unsure what it actually says >> though :) >> > > Fair enough, and I think the conservative thing to do is certainly to > asynchronously notify your peer when the window changes, however as in my > other reply I don't see how doing that actually eliminates the possibility > of deadlock with service-bus. Asynchronously notifying your peer when you > change the window is a very different requirement than being obliged to > notify your peer that the window is nonzero in order to receive credit. >
For the ServiceBus case I was saying we would need to do it synchronously, which we obviously wouldnt want to for various reasons. That would also presumably require us (and SB) to support the echo flag, which I think I recall raising a JIRA about some time ago. I'm much more inclined to set the window high and forget it exists :) > > I think Gordon is meaning in regard to the fact that we send a >> transfer when our outgoing window is [initially] 0 without first >> increasing it to e.g.1, due to the use of the phrasing I mentioned >> earlier that defines a "maximum" id below our [initial] next outgoing >> id. If so, I tend to share his view on that. >> > > Gotcha, I certainly agree that the robust thing to do would be to issue the > flow frame in such cases. > > >> Ultimately I think we just set a big window and essentially forgot it >> exists for now, we aren't using it at all within proton currently >> after all. We might as well stop calculating the remote value given we >> never actually read it. >> >> > I don't think we should do the max-frame-size thing >> > though as this encourages the notion that the incoming-window is somehow >> > dependent on the outgoing-window which as I said above is I think unsafe. >> > >> > I guess setting it to a large constant for now is fairly reasonable, but >> I >> > do think we should encourage service-bus to make its implementation more >> > robust in this regard. >> > >> > --Rafael >> >> Can I take that as a +1 on the approach I proposed changes for on >> PROTON-936 / https://github.com/apache/qpid-proton/pull/42 ? >> > > Yes > > --Rafael Great, I'll push that change in tomorrow morning.
