Re: GOAWAY -> GTFO

Keeping a list of streams and their state is something that some proxies
may not do, especially if only involved in load balancing-- keeping the
last seen stream-id is trivial, however.
On Jan 27, 2014 3:12 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

> On 27 January 2014 14:56, Amos Jeffries <squid3@treenet.co.nz> wrote:
> > Both ends already have that tracking in place. The costs I here would be
> the
> > extra bytes on the GTFO frame and the cycles used to generate that list
> in
> > the sender for which streams it still wants to receive. The cycles to
> > process it in recipient would be the same ones for clearing up that state
> > anyway.
>
> Not exactly.  You know what streams you have, but the streams that
> have crossed from 'not idle' states into 'no way back from here' isn't
> something that necessarily needs tracking.
>
> It's a line call either way.  Multiple stream identifiers is more
> complexity all around, and the gain is marginal at best.
>
> > A list of only one entry (as currently used) meaning the connection
> close is to follow and everything outstanding is borked.
>
> Signaling using a single entry won't work.  You could make the first
> item in the list imply that all earlier streams are (or could be)
> processed.  That's an easy way to allow people to contain the
> complexity.
>
> BTW, if you send GTFO because things are messed up badly enough that
> explosions might occur, I don't think you want to keep on keeping on.
> In most of the error scenarios, GTFO is followed immediately with a
> connection close.  Keeping the connection alive is usually reserved
> for graceful shutdown.
>
>