Re: [hybi] WS ABNF

Scott Ferguson <ferg@caucho.com> Wed, 17 February 2010 17:02 UTC

Return-Path: <ferg@caucho.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 DF86228C168 for <hybi@core3.amsl.com>; Wed, 17 Feb 2010 09:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 ouu7pJbMlCmq for <hybi@core3.amsl.com>; Wed, 17 Feb 2010 09:02:14 -0800 (PST)
Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by core3.amsl.com (Postfix) with SMTP id C4E9E28C145 for <hybi@ietf.org>; Wed, 17 Feb 2010 09:02:13 -0800 (PST)
Received: (qmail 72097 invoked from network); 17 Feb 2010 17:03:44 -0000
Received: from dsl092-008-203.sfo1.dsl.speakeasy.net (ferg@66.92.8.203 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 17 Feb 2010 09:03:44 -0800 PST
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
X-YMail-OSG: UUVrTAcVM1lY6uXpUEapfaMTrcDR1QLh.CSTbUC7mzEfsxES0PvjcQEzdDxAx3D9YRO_KZjKa7thixuFrCWImFmyA4r.aVPhgs4IQwEmSG95f6jV2azt.iaSDzzDTPmToSGYDVctlJgsyksB9_ISUvFr1_O9yKoS6K56BRQiOfSjvJ2uB0jaOVWfMUPCnRUjSHuJ8xpwSrV1o7T3IwoeJt08GvWJkywFvx8CZSJxqqfdtV6YTVbVhZYZwJeklMAK1w72RvMUi7JBHIwoY4e2vzKz7zd7ZgtPOGt57rsPbrDCfeK5QioatHOLSJPV93jmrk6Jxb4lU.9QidMT9mgd3WAZT08lMWNM3xL3iyrmGab9i65SF7cbBW2Eue1CgqSgvZAx7794.Tx2_iBGXKHcR_VS
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4B7C216E.7040404@caucho.com>
Date: Wed, 17 Feb 2010 09:03:42 -0800
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
References: <8B0A9FCBB9832F43971E38010638454F032E566DDF@SISPE7MB1.commscope.com> <18559.1266310165.853559@puncture> <4B7A5FD1.8090005@gmx.de> <18559.1266313683.441640@puncture> <20100217025338.GA1654@shareable.org> <14781.1266401848.423659@puncture>
In-Reply-To: <14781.1266401848.423659@puncture>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] WS ABNF
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: Wed, 17 Feb 2010 17:02:15 -0000

Dave Cridland wrote:
> On Wed Feb 17 02:53:38 2010, Jamie Lokier wrote:
>> Then one day, someone else puts an 8GB file there and expects it to
>> work.  Why should it be fine for 3GB files but fail for an 8GB file?
>
> Because websocket messages would (then) be limited to 4G, just as IMAP 
> limits emails to 4G (yet the rest of the mailsystem doesn't). I'm not 
> aware of this *ever* causing a problem. I'm not aware of - amongst the 
> vast numbers of people who seem to enjoy picking holes in IMAP - 
> anyone complaining about that limit even theoretically, or complaining 
> that the literal octet count is represented in ASCII.
Chunked/fragment encoding is needed anyway because you don't want to 
force the sender to buffer an arbitrarily large message before sending 
it. And once you have chunking/fragmenting, the size of the fragment is 
irrelevant to the size of the full message.
>> Maybe for generality (no fixed limit), but it might have been an
>> attempt to use fewer bytes for small messages.  Considering most
>> messages are expected to be small(*), that's not entirely illogical.
>
> Not on the face of it, no. A naïve look would see that a whole 1-3 
> octets are shaved off the wire, and that can't be a bad thing in and 
> of itself.
>
> The trouble is that it's vanishingly rarely saving any TCP packets, 
> which would be interesting and useful, and nor is it saving any 
> messages, which is essentially beyond the scope of the protocol. Those 
> two *do* save appreciable amounts of bandwidth.
This isn't complicated.  Just use a chunk/fragment encoding that looks like

  len ::= [\x80-\xff]{0,3}[\x00-\x7f]

The 0-terminating chunk takes up a single byte, small messages (< 128) 
only need two bytes of overhead, chunk lengths are limited to 32-bits 
(actually 28-bits but it doesn't matter), the total message size is 
arbitrarily large, and it's trivial to implement.

Or something like utf-8 if you want the first byte to specify the number 
of bytes:

  len0 ::= [\x00-\x7f]
  len1 ::= [\x80-\x9f] [\x00-\xff]
  len2 ::= [\xa0-\xbf] [\x00-\xff]{2}
  len3 ::= [\xc0-\xdf] [\x00-\xff]{3}

Or just use a fixed 2-byte length prefix.

If it's important to add message types (and that would be cleaner as a 
different layer), that's just a single extra byte of overhead.

-- Scott
>
> Dave.