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