Re: [hybi] hum #3: Message

Scott Ferguson <ferg@caucho.com> Sat, 07 August 2010 01:46 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 489D53A6915 for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 18:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oqlE5IR8PNXz for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 18:46:01 -0700 (PDT)
Received: from smtp113.biz.mail.re2.yahoo.com (smtp113.biz.mail.re2.yahoo.com [66.196.116.98]) by core3.amsl.com (Postfix) with SMTP id B8EDE3A6407 for <hybi@ietf.org>; Fri, 6 Aug 2010 18:45:57 -0700 (PDT)
Received: (qmail 10279 invoked from network); 7 Aug 2010 01:46:26 -0000
Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 06 Aug 2010 18:46:26 -0700 PDT
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
X-YMail-OSG: wNQ_NO0VM1mYmydgDI9X2RSxP4HJHo81YBNhgqCwfkC3L3e nlJ_Tul99npERbNnoE2F13NxHw8zpwUUrq3EDI0Ec1TuFEjX6EjEl91GZJqf NlVbyBt6mqKLL.S4R__BGJ0eIC_UoJbcmeQVux5Nn3mf_rJI64ZxnsUThQco M_TvSjm7yN_8iNZT5ihFlQYsfdn2kzzgy0G1Yibf4Bl4N.1lCpZzEMLD1FsR u_ZB9xkfRYjlC9T0_hPlPoyxWyfo4CBBuhswKeQpZqUmdSymum57vnvUjCcp r6JlTINld4WaNW3g7D7nwoy_eboiJEhHfqLMopqfh_ha9A0mlX8wJ.LcLjIf 7FmsP10b895KI14XhosAef9YuEkYgsiJ1LVo313Dnhl7xvvtdBIDniyMjc0m v7UrGF.Q3rT03O7oKwA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4C5CBAEB.3050809@caucho.com>
Date: Fri, 06 Aug 2010 18:46:19 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
References: <4C5AE93D.4040803@ericsson.com> <Pine.LNX.4.64.1008051758290.5947@ps20323.dreamhostps.com> <AANLkTik0kbh14s2JZARY2MFh0iNGV7H+B4Px4yG+wX44@mail.gmail.com> <71BCE4BF-D3F6-4F94-BE76-306BDF6A2E67@apple.com> <Pine.LNX.4.64.1008051930160.5947@ps20323.dreamhostps.com> <4C5B1695.6070704@gmx.de> <F8E2F702-9F74-4316-B3B2-D5A731409ABF@apple.com> <AANLkTin=gO9D8K5NVhqCRKki-jrDmTYqF-gBjp9X41GN@mail.gmail.com> <4C5BF15E.1090608@noemax.com> <AANLkTinXLPmBACd3ji0V9wkAWmxOR7qBMED19KKMvJrd@mail.gmail.com> <AANLkTi=RWdqDDgy24C6qtUSr+5R5p=P15B=+aUZuE16Q@mail.gmail.com> <4C5C07D6.1030208@noemax.com> <AANLkTimj9RvzL8E+FmH=vT_TeECVNmDPXY0ymPnvBHSZ@mail.gmail.com> <4C5C31DF.3030608@caucho.com> <2286.1281126409.976140@puncture>
In-Reply-To: <2286.1281126409.976140@puncture>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] hum #3: Message
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: Sat, 07 Aug 2010 01:46:02 -0000

Dave Cridland wrote:
> On Fri Aug  6 17:01:35 2010, Scott Ferguson wrote:
>> As a practical matter, a 16-bit short length would be better because 
>> buffer sizes are typically in the 1k to 64k range, and a 16-bit 
>> length lets the implementation pre-allocate the frame header for any 
>> message/chunk.
>>
>>
> I'm happier with the "short" being 255 octets, because the only case 
> we really need to minimize overhead is in mobile cases, where the 
> power levels possible by transferring packets <128 octets are 
> substantial and important.
>
>> With an 8-bit length, the implementation either needs to shift bytes 
>> in the buffer when the message is 255 bytes long or it needs to 
>> preallocate the long frame header.
>
> Indeed. I'm told, however, that this is not such a big deal.

16 bits is a very helpful length for implementing chunking efficiently 
for dynamically-produced content. This is not a theoretical concern, but 
based on experience implementing similar framing protocols and chunking 
for HTTP. So I'm telling you as a developer who will implement chunking 
for WebSockets, that this choice affects my implementation significantly.

Any of 16/64, or 8/16/64 or 8/32/64 would be fine, but 8/64 is a poor 
choice for chunking because 256 bytes is too small to be a reasonable 
chunk, and 64 bits is a waste. Suppose you're using a 8k buffer. With 
the 8-bit length, you need 32 chunks just to send the buffer. With the 
64-bit length, you're wasting 6 bytes. With those as the only options, 
you're stuck between two bad choices.

The advantage of 16/64 is that it's still efficient for small messages, 
and is also efficient for chunking, and for large static files. The 
extra byte over the minimum 2-byte header is insignificant (and people 
were happy with 3 bytes.)

Since you were suggesting a 6-byte header earlier, I can't see why a 
3-byte header would not be acceptable.

> FWIW, unaliagned access to wrong-endian data is something I have 
> experience of, and as far as I can tell, is not a substantial overhead.

Yes, endian is not a major overhead. Endian is a non-issue because it 
doesn't affect the length, and never forces a buffer copy (or tricks 
like multiple buffers to avoid the copy) like expanding over a dynamic 
length boundary does.

-- Scott

>
> Dave.