Re: Ending streams/connections

On 3 September 2014 18:07, Cory Benfield <cory@lukasa.co.uk> wrote:

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

My bad - I forgot that RST is not acknowledged.   I had thought that it was
effectively a half close with the extra condition that when you receive a
RST, you
had to send one immediately, hence forcing the full close (but above the
framing layer).

But I now (belatedly) remember that it is not acknowledged and that

   after sending the RST_STREAM, the sending endpoint
   MUST be prepared to receive and process additional frames sent on the
   stream that might have been sent by the peer prior to the arrival of
   the RST_STREAM.

It's a little bit strange that we insist that settings frames are
acknowledged but
have to have a  'short period' when the stream is quasi closed.

Anyway - ignore me.  I had thought it was a minor tidy up, but does not
work with this complex closed state.

cheers

-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.