Re: Shouldn't we add a new CLOSING state in H2 ?

I've run into this too. On H1 as well, of course. The solution space seems
to be

1] a go-away ack to handshake the go-away

2] document a strategy about not closing the session until all the session
flow control credits for streams <= last id have been returned to the
sender. session credits would be more reliable than stream credits, but I'm
not sure the peer is actually really required to send them while closing if
they seem redundant.

3] wait for h3 where this little tcp artifact of intentionally losing data
is not an issue.

it might be reasonable to do all 3



On Thursday, January 24, 2019, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Jan 24, 2019 at 07:31:32PM +0100, Alcides Viamontes E wrote:
> > > We could imagine a lot of dirty time-based workarounds for this, but
> > they would only steer the problem to another area.
> >
> > We had to go the way of the dirty time-based workarounds to implement
> > seamless reloads, and unless all user-agents implement a solution at
> once,
> > I don't think we can get rid of them :-( ...
>
> So I have another idea that I'll see if I can implement for this specific
> case of the seamless reload operation : the server could send a PING to
> the client after the last frame of the last stream, and wait for the
> PING/ACK to come back. Once it gets it, it will know that all data frames
> were properly received. Some implementations might let the PING/ACK frame
> leave faster than WINDOW_UPDATES (which is not really an issue). But we
> could as well emit a SETTINGS frame with SETTINGS_MAX_CONCURRENT_STREAMS=0
> and wait for the ACK, eventhough in my opinion it will be equivalent.
>
> I'll see how far I can go with this. But I'm definitely interested in
> trying to address the stream state synchronization between both ends
> anyway.
>
> Willy
>
>