Re: Design Issue: Life-cycle of a Stream
Martin Thomson <martin.thomson@gmail.com> Wed, 01 May 2013 17:50 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E6A21F9A7D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 May 2013 10:50:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkRaIEnfZDyd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 1 May 2013 10:50:15 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 477EA21F9A6B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 1 May 2013 10:50:15 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UXbAI-0004Bz-10 for ietf-http-wg-dist@listhub.w3.org; Wed, 01 May 2013 17:50:02 +0000
Resent-Date: Wed, 01 May 2013 17:50:02 +0000
Resent-Message-Id: <E1UXbAI-0004Bz-10@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UXbA7-0004An-9S for ietf-http-wg@listhub.w3.org; Wed, 01 May 2013 17:49:51 +0000
Received: from mail-wi0-f175.google.com ([209.85.212.175]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <martin.thomson@gmail.com>) id 1UXbA6-0007nX-9M for ietf-http-wg@w3.org; Wed, 01 May 2013 17:49:51 +0000
Received: by mail-wi0-f175.google.com with SMTP id h11so5132920wiv.2 for <ietf-http-wg@w3.org>; Wed, 01 May 2013 10:49:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GMbt/KNrQ2zfqOvZn8Y22QstzqF6w8xmViltWrIIjMI=; b=hCKjzM2GMPhGevMyjIW+L0nnm6qahJ41mCg1/ZTgK/i6LiqRhDgsm/Z8d1J4wvqKUf cCFMknY80vk8lWnlQnZViU1y4VCVf8sSdVCkhfxUEuuoUVLf1jGJAL6oCkfU1o1hhhKR Rs+k116+StvgDUU1A4mWwiLUhH1/1G8+XIUctetAHHi0VSPefwXXIL9zduyQjjti6j2v w/Elpgboq2j8DNU4/Izahw5k3CeuwtO+FsjWsEqnmzgjJuqYikYq6sOwHr8/apoPlQQR YHF7y4OB/J2JM1z3NkPDC7PJY2X+8OEq3mWwqt2x8NdT8ksRbOTJxBlk0XoipGEl2zP6 vB6Q==
MIME-Version: 1.0
X-Received: by 10.194.63.239 with SMTP id j15mr3850961wjs.30.1367430564179; Wed, 01 May 2013 10:49:24 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Wed, 1 May 2013 10:49:24 -0700 (PDT)
In-Reply-To: <CABP7Rbd08=A6FGA_Huydcx59MWjd7GgBsZ-hcQfAB4mt3d72yQ@mail.gmail.com>
References: <CABP7Rbd08=A6FGA_Huydcx59MWjd7GgBsZ-hcQfAB4mt3d72yQ@mail.gmail.com>
Date: Wed, 01 May 2013 10:49:24 -0700
Message-ID: <CABkgnnXWzLm59SEw=gu8EtvSYTazKcN6WJrAA+kXOu_zFyvAig@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.212.175; envelope-from=martin.thomson@gmail.com; helo=mail-wi0-f175.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.697, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UXbA6-0007nX-9M 58042023371a365f50bb04a0bd3cfa3f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: Life-cycle of a Stream
Archived-At: <http://www.w3.org/mid/CABkgnnXWzLm59SEw=gu8EtvSYTazKcN6WJrAA+kXOu_zFyvAig@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17767
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
On 1 May 2013 10:03, James M Snell <jasnell@gmail.com> wrote: > 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. I don't see why 1 & 2 are necessary. It's just arbitrary. Sending any frame should suffice. > 3. PUSH_PROMISE frames reserve a stream identifier but do not open the stream. Good. > 4. Promised streams are only opened by sending a subsequent HEADERS or > HEADERS+PRIORITY frame that uses the reserved stream identifier. Again, promised streams are opened by sending frames. > 5. All streams are either fully open, half-closed by the client, > half-closed by the server, or fully closed. I think of this differently. Streams aren't bi-directional constructs, they are a loose binding of two unidirectional constructs. Each unidirectional component has its own state. FINAL ends a stream in the direction that it appears on. RST_STREAM ends a stream in the direction that it appears on and requests the closure of the opposite direction. > 6. All promised streams are associated with an originating "parent" stream. That binding is a problem. The reason for the stream association in push promise is to obtain request headers. That relationship is a function of the HTTP usage of streams, not an inherent function of the streaming layer. > 7. A stream is half-closed by sending a frame with the FINAL bit set. See above, FINAL ends a stream for the direction in which it appears. > 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. RST_STREAM. > 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. Neither works particularly well for me. If you consider independent lifecycles for each direction of a stream, this sort of distinction is unnecessary. > 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. The latter, please. > 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. The latter, please. > 12. Half or fully closing a promised stream has no impact on the > parent stream or any associated sibling promised streams. Of course. > 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. You probably need more than one dimension in your taxonomy to get this right. I don't see this as a function of the thing that processes frames. > 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. I'm assuming that there is a stream controller that takes all stream-related frames and does things to the stream state. That controller looks at FINAL and consumes things like RST_STREAM. But that operates at what I consider to be Tier 2. It also has its own layering because flow control exists here. > 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 >
- Design Issue: Life-cycle of a Stream James M Snell
- Re: Design Issue: Life-cycle of a Stream William Chan (ιζΊζ)
- Re: Design Issue: Life-cycle of a Stream Martin Thomson
- RE: Design Issue: Life-cycle of a Stream Mike Bishop
- Re: Design Issue: Life-cycle of a Stream James M Snell