Re: [hybi] Frame size

Greg Wilkins <gregw@webtide.com> Fri, 16 April 2010 12:49 UTC

Return-Path: <gregw@webtide.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54AE43A6C15 for <hybi@core3.amsl.com>; Fri, 16 Apr 2010 05:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.624
X-Spam-Level:
X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td9FHzXmWIyv for <hybi@core3.amsl.com>; Fri, 16 Apr 2010 05:49:47 -0700 (PDT)
Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 8DD5F28C16F for <hybi@ietf.org>; Fri, 16 Apr 2010 05:38:24 -0700 (PDT)
Received: by bwz25 with SMTP id 25so3032192bwz.28 for <hybi@ietf.org>; Fri, 16 Apr 2010 05:38:12 -0700 (PDT)
Received: by 10.103.3.20 with SMTP id f20mr1038772mui.95.1271421492628; Fri, 16 Apr 2010 05:38:12 -0700 (PDT)
Received: from [192.168.0.100] (host116-234-static.43-88-b.business.telecomitalia.it [88.43.234.116]) by mx.google.com with ESMTPS id j10sm13342586mue.18.2010.04.16.05.38.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Apr 2010 05:38:12 -0700 (PDT)
Message-ID: <4BC85A31.6060605@webtide.com>
Date: Fri, 16 Apr 2010 14:38:09 +0200
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Hybi <hybi@ietf.org>
References: <8B0A9FCBB9832F43971E38010638454F03E3F313ED@SISPE7MB1.commscope.com> <v2m5c902b9e1004160043i7b5ccc79y2346e1b2b2c55cf5@mail.gmail.com> <s2qad99d8ce1004160053w436a29b1idae0c66737b3760a@mail.gmail.com>
In-Reply-To: <s2qad99d8ce1004160053w436a29b1idae0c66737b3760a@mail.gmail.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] Frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 16 Apr 2010 12:49:48 -0000

I thought one of the key arguments for a limited frame size,
is that we could avoid the need to consider end points that
could not store an entire frame in a buffer at once.

So 2 byte's can still result in a 64k maximum frame size that
some devices might baulk at... but not many.

However, if frame sizes were 4 bytes or more, then we have the
issue that all end points will have a restriction of frame size
that can be held in a buffer that is smaller than the maximal.
We then need error handling for when a frame that is too large
is offered etc.

So if we are going to limit it, then is should be small
enough so we can say that all websocket endpoints must
be able to accept a minimal frame.

In fact, I would argue for a 16k max frame size with 2
bits given over to help with partitioning and aggregation,
but with no requirement that an endpoint can handle
aggregation and partitioning (unless they indicate they
can in the handshake).

cheers