Re: [hybi] Is it important to know frame length at the start of frame? (was: Re: Discontinuation of mux ...)

Peter Thorson <webmaster@zaphoyd.com> Wed, 12 February 2014 16:25 UTC

Return-Path: <webmaster@zaphoyd.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4281A0447 for <hybi@ietfa.amsl.com>; Wed, 12 Feb 2014 08:25:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTLn-8-o3xbR for <hybi@ietfa.amsl.com>; Wed, 12 Feb 2014 08:25:26 -0800 (PST)
Received: from authsmtp00.uchicago.edu (authsmtp00.uchicago.edu [128.135.12.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7331A0310 for <hybi@ietf.org>; Wed, 12 Feb 2014 08:25:26 -0800 (PST)
Received: from [10.0.1.89] (c-68-51-76-178.hsd1.il.comcast.net [68.51.76.178]) (Authenticated sender: zaphoyd) by authsmtp00.uchicago.edu (Postfix) with ESMTP id D0964498088; Wed, 12 Feb 2014 10:25:24 -0600 (CST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Peter Thorson <webmaster@zaphoyd.com>
In-Reply-To: <CACuKZqEcA1Pv8RpWfmThMjTzi2BbVMMKXqujs6BxVfxRPZJ9NQ@mail.gmail.com>
Date: Wed, 12 Feb 2014 10:25:28 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5F162C5-D2FF-4140-B80B-5BF2DEE80AB1@zaphoyd.com>
References: <CAH9hSJbf_ABT7ECL9eS=_ADrncX8qBtxZv=uLcdu9_6GUv23Uw@mail.gmail.com> <CACuKZqEcA1Pv8RpWfmThMjTzi2BbVMMKXqujs6BxVfxRPZJ9NQ@mail.gmail.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
X-Mailer: Apple Mail (2.1822)
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Is it important to know frame length at the start of frame? (was: Re: Discontinuation of mux ...)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2014 16:25:27 -0000

On Feb 12, 2014, at 10:00, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> Why not send the message in one frame? The frame length is then the
> message length.

The message length might not be known or might not be fully buffer-able by the sending endpoint.

> One argument for fragmentation is to insert control frames while
> transmitting a long message. However that reasoning is not very
> convincing:
> 
> PONG - as long as we are writing data, any data, the peer should see
> that the connection is alive. It's unreasonable for the peer to think
> that our end is unresponsive while it is receiving data from us.
> 
> PING - not necessary while we are writing data. If peer is
> unresponsive, we'll learn that from TCP layer.

It does provide some separation of concerns and the ability to do things like measure RTT during a long message.

> CLOSE - closing the connection in the middle of a message is abnormal
> anyway, it's probably not important to do the close handshake.

It can be used to cleanly close a connection after a message has been sent but before it is completed. Say a client initiates a transfer then decides to leave halfway through (browser tab closes, etc). The client can indicate that it wants to close and that the in flight message should be discarded. Otherwise the client would have to either truncate the message (which might result in bogus data getting processed by the server) or just close the TCP connection (which can leave the connection in a bad state on the server and causes the server to have to report an unclean close to its application, which isn’t entirely accurate).