Re: Design Issue: Life-cycle of a Stream

Ok, based on the feedback given so far, we seem to be in agreement
that promised streams ought to have an independent lifecycle from the
parent stream. Closing the parent, even with an RST_STREAM, ought not
affect any of the associated promised streams, and that the only
association that truly exists between the original and the promised is
that the promised stream inherits headers from the original. Does that
seem accurate? (The header inheritance does raise a number of other
questions but I'll get to those later on). This resolves items 10 and
11.

Items #2 and #4 are still controversial and we need more input to figure it out.

Item #9 is also controversial. Currently the group appears to be
leaning towards requiring that pushed streams are always
unidirectional and automatically half-closed for the receiver.
However, there is the opposing point of view (which I share) that we
ought to allow pushed streams to be optionally bidirectional, even if
http/2 semantics do not make direct use of the bidirectionality. Some
subprotocol later on might.

All of the other items in the lifecycle list appear to be non-controversial.

As for the Tier discussion, we can use the "layer" terminology
instead. How about, "Tier 0" == "Session Layer", "Tier 1" == "Framing
Layer", "Tier 2" == "HTTP/2 Layer". Also, it is suggested that Item C
from my tier 1 in the original note ought to be part of tier 1. That
works for me.

Does that appear to be an accurate assessment?

- James

On Wed, May 1, 2013 at 10:03 AM, James M Snell <jasnell@gmail.com> wrote:
> The current spec is rather vague on the complete life-cycle of a
> stream within a session. Aside from discussing how the Mommy Endpoint
> and the Daddy Endpoint get together, we ought to take just a bit of
> time to make sure we're all on the same page...
>
> In a separate thread, several of us discussed stream creation...
> specifically, how is a stream initiated. Let's see if we can formalize
> the process and the language. I've written the following out as
> statements, if you disagree with the statement or see it a different
> way, lemme know! Some of this is obvious and well established, I'm
> documenting it here just to make sure we have the complete picture
> captured. I've marked the items that appear to me to be the most
> controversial with an asterisk.
>
> 1. Streams are initialized or opened by sending a HEADERS or
> HEADERS+PRIORITY frame that uses a previously unused stream
> identifier.
>
> 2. Only HEADERS and HEADERS+PRIORITY frames are used to open a stream.
>
> 3. PUSH_PROMISE frames reserve a stream identifier but do not open the stream.
>
> 4. Promised streams are only opened by sending a subsequent HEADERS or
> HEADERS+PRIORITY frame that uses the reserved stream identifier.
>
> 5. All streams are either fully open, half-closed by the client,
> half-closed by the server, or fully closed.
>
> 6. All promised streams are associated with an originating "parent" stream.
>
> 7. A stream is half-closed by sending a frame with the FINAL bit set.
>
> 8. A stream becomes fully-closed when either: a) both endpoints send
> frames with the FINAL bit set or b) either endpoint sends an RST_FRAME
> with that streams identifier.
>
> 9*. Promised streams are automatically half-closed for the recipient.
> That is, when the server sends a PUSH_PROMISE to a client, that
> streams becomes automatically half-closed for the client. The only
> frame the client can send back to the server for that stream are
> RST_STREAM frames.
>
>   -- or --
>
> 9*. Promised streams are handled just like regular streams. The server
> opens the stream and half-closes. The stream does not fully close
> until either the client half-closes it or a RST_STREAM frame is sent
> for that stream.
>
> 10*. Sending an RST_FRAME for a parent stream fully closes that stream
> as well as all associated promised streams.
>
>   -- or --
>
> 10*. Sending an RST_FRAME for a parent stream only closes that stream
> and has no affect on associated promised streams.
>
> 11*. Fully closing a parent stream using symmetric half-closes will
> fully close all associated promised streams.
>
>   -- or --
>
> 11*. Fully closing a parent stream using symmetric half-closes has no
> affect on associated promised streams.
>
> 12. Half or fully closing a promised stream has no impact on the
> parent stream or any associated sibling promised streams.
>
> Ok, so that covers the lifecycle.. let's talk about processing.. this
> is largely a reiteration of my previous note on this but I want to
> make sure I've hit all the major points in how this is categorized.
>
> Tier 1: Includes the following...
>
> A. Reception and basic parsing of frames. "Basic parsing" here means
> looking at the header bytes to determine the frame type, making note
> of the flags, frame size and stream identifier, and performing any
> necessary header block decompression and state management.
>
> B. Handling of all session frames (stream id #0). This means that
> upgrade negotiation, SETTINGS, PING, flow control and session level
> error handling are all Tier 1 processes.
>
> C. Basic lifecycle handling of stream frames. This includes
> determination of whether a stream is open or closed, whether or not
> additional frames are allowed for a stream, validation of proper
> stream id use, reservation of stream id's with push_promise, and
> handling of the FINAL flag.
>
> Tier 2: Includes the following...
>
> A. Frame-type specific processing. Validation and handling of frame
> payloads and frame-specific flags, not including header block
> processing (which is tier 1)
>
> B. Additional stream-level error handling not related to stream-lifecycle
>
> Tier 3: Includes all application-level handling (HTTP Semantics)
>
> So, when we say things like "an endpoint must be prepared to continue
> receiving frames on a closed stream", we mean to say that "an endpoint
> must be prepared to do tier 1 processing on all frames, even those
> sent for closed streams."
>
> Please weigh in on whatever items y'all feel are controversial. I'll
> work up proposed spec edits based on whatever feedback is received.
>
> - James

Received on Wednesday, 1 May 2013 23:22:15 UTC