Re: Ending streams/connections

Greg,

On 3 September 2014 03:11, Greg Wilkins <gregw@intalio.com> wrote:
>
> Currently a stream can end either with a RST_STREAM or with a frame carrying
> the  END_STREAM flag.

Not quite. The END_STREAM flag doesn't terminate a stream, it closes
one end of a stream. This is not what RST_STREAM does: RST_STREAM
closes *both* ends of the stream. If i receive an END_STREAM flag from
you that tells me that you can't send me any more non-control frames
on that stream, but does not prevent me sending you more. RST_STREAM
does (or at least should).

(NB: It's actually suddenly not clear to me what frames END_STREAM
prevents. It definitely prevents more DATA frames, but does it also
prevent further HEADERS frames? If I'm sending trailers, does the last
DATA frame carry END_STREAM and is then followed by HEADERS, or does
the last HEADERS carry END_STREAM?)

> I propose that RST_STREAM should also indicate end of stream by defining the
> END_STREAM(0x1) flag and it MUST be set.

This is harmless: the END_STREAM flag informs the remote party that
you're closing your send portion of the stream, which is already
implied by the fact that RST_STREAM includes that meaning. However,
it's also redundant. Redundancy tends to be bad.

> The reason for this proposal is so that code can be written to track the
> status of stream without needing to care about the exact semantics of
> resetting a stream.

As I point out above, that's not true. You'll still need to
special-case the RST_STREAM frame's effect on closing your send
channel.

> Similarly, I think that GO_AWAY should also indicate END_STREAM on stream
> ID=0

This is a weird idea, but that might be because of my implementation.
I don't consider stream 0 to be a 'real' stream, I consider it to map
1:1 to the connection. Its state maps directly onto the state of the
connection: stream 0 is open for as long as the connection is.

Additionally, given what I said above about END_STREAM being about
sending non-control frames, END_STREAM has no effect on the state of
stream 0 because you already can't send non-control frames on it.
HEADERS and DATA must be sent on stream != 0, so if you send me
END_STREAM it doesn't change my behaviour at all.

Cory

Received on Wednesday, 3 September 2014 08:08:21 UTC