Re: GOAWAY -> GTFO

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.

Received on Monday, 27 January 2014 23:10:35 UTC