Re: [hybi] WS framing alternative

Greg Wilkins <gregw@webtide.com> Tue, 27 October 2009 10:08 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 BD06E3A6A06 for <hybi@core3.amsl.com>; Tue, 27 Oct 2009 03:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.194
X-Spam-Level:
X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, 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 grvPUKIC4Ghm for <hybi@core3.amsl.com>; Tue, 27 Oct 2009 03:08:35 -0700 (PDT)
Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id C7D633A657C for <hybi@ietf.org>; Tue, 27 Oct 2009 03:08:35 -0700 (PDT)
Received: by yxe30 with SMTP id 30so15847426yxe.29 for <hybi@ietf.org>; Tue, 27 Oct 2009 03:08:46 -0700 (PDT)
Received: by 10.150.130.39 with SMTP id c39mr26061231ybd.338.1256638126426; Tue, 27 Oct 2009 03:08:46 -0700 (PDT)
Received: from ?10.10.1.9? (60-242-119-126.tpgi.com.au [60.242.119.126]) by mx.google.com with ESMTPS id 13sm2602480gxk.13.2009.10.27.03.08.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 03:08:45 -0700 (PDT)
Message-ID: <4AE6C6A8.6090307@webtide.com>
Date: Tue, 27 Oct 2009 21:08:40 +1100
From: Greg Wilkins <gregw@webtide.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
References: <8B0A9FCBB9832F43971E38010638454F0F1EA72C@SISPE7MB1.commscope.com> <Pine.LNX.4.62.0910270903080.9145@hixie.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.62.0910270903080.9145@hixie.dreamhostps.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [hybi] WS framing alternative
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: Tue, 27 Oct 2009 10:08:36 -0000

Even though I said that discussion about protocol requirements
is more important, here is some more debate about protocol design:



Ian Hickson wrote:
> This would have some pretty major costs:
> 
> - It requires length delimiting for text frames, which is more complicated 
> to implement (it's non-trivial to tell the difference between characters 
> and bytes).

But length delimited frames are in the protocol anyway, so they have to
be implemented anyway.

If there was only 1 framing type, then we have approximately half the
framing complexity.


> - It requires parsing using a presized buffer for variable-encoding text, 
> which risks character/byte mismatches and thus buffer overruns.

With sentinel encoding, sending data might be marginally simpler,
but receiving data is much harder.

You will still have buffers of fixed sizes when you receive bytes.  You
don't know how much data is coming, so you don't know how big to make
your buffer or when to start turning bytes into characters.

I can see implementations reading a buffer.... scanning for 0x00, not
finding it... allocating a larger buffer... copying the bytes ...
reading more bytes ... scanning again for 0x00.... still not finding
it.... allocating yet another larger buffer... copying the bytes ....

etc.  etc.  until either you get a denial of service or you find
0x00, when you can finally scan over all the bytes again to
convert to characters.

If the message is larger than you want to read, then you don't
know this until you have read all the bytes you can and scanned for
a 0x00.  Resource limits are always better applied before the resource
is consumed than after.

To avoid wastful copying, you have to allocate wasteful large buffers,
which can still fill up and might need to grow.

Existing UTF-8 to character conversions will error if they get a partial
multipart character, so you can start conversion to characters until
you have the entire message.   Efficient implementations will be forced
to reimplement utf-8 converters to scan for 0x00 while converting.
This will allow smaller fixed byte buffers, but will still need
growing and/or large character buffers.  This is probably also
what needs to be done to be able to use direct kernel buffers.

I don't think there is a clear winner between the two types
of framing.  Both have their pros and cons.    But implementing
both will be approximately twice as complex and it will mean that
you have to deal with both sets of cons.


regards