Re: [hybi] Max frame size

Scott Ferguson <ferg@caucho.com> Thu, 23 June 2011 16:37 UTC

Return-Path: <ferg@caucho.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6611E8179 for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 09:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level:
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZovCgJV9EVL for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 09:37:40 -0700 (PDT)
Received: from nm18.bullet.mail.sp2.yahoo.com (nm18.bullet.mail.sp2.yahoo.com [98.139.91.88]) by ietfa.amsl.com (Postfix) with SMTP id C57D011E813D for <hybi@ietf.org>; Thu, 23 Jun 2011 09:37:40 -0700 (PDT)
Received: from [98.139.91.64] by nm18.bullet.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 16:37:38 -0000
Received: from [98.139.91.26] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 16:37:38 -0000
Received: from [127.0.0.1] by omp1026.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 16:37:38 -0000
X-Yahoo-Newman-Id: 282133.43472.bm@omp1026.mail.sp2.yahoo.com
Received: (qmail 42260 invoked from network); 23 Jun 2011 16:37:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1308847057; bh=1ruodZp7BQj0UvxcAaWnfwG9/zDeWDBZXINJ9Yz08u8=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FWDNRXEXle8DtMPlD7et4Zkwg38vzzHHzcDQ4COOd7WR9uphL2KTngbCYV1GLIbcK81Y6yjUVqrugeGzn6+T1XwD6wJMmL51EjBUuYIpMoq4UPI+5BtZgKBFBBbRz7MTtTAyBUrLrkaoRZPkb3omAfPuQi762VBuLVheWrAYwV4=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: GKT0d08VM1ljJ6M9RC38vux9xonW6lDwzYHpCCe9U2hqKMi 4eXE1YelYUzqvqmLBpOObXZ4zyERiNYLGSJSnu4UjlRGa1Mca7lrY86YuICW vPc2F2wupKvZdXzCTQ2k0THTPtrBt9LQ7TCc9iXmhBQn5WEsZzp0Ve1884Jb zi7kL2masfuak8r.wx3YnF__DJguOpZKwio9v1QnR1HzzilfMCsUxWdEERsJ JGpqIkP02m7immJXcmXbOtUlSBT_32spqgNUBMjci9gXHW0Al8IQmKOoTBLD QnzmyoJDlJ2ltXC70G1KC3q6IzX5_D_At4kK2TY4O.at6uP3G6lOb5jQ.kNH Ol99n6fB8PxgV1XNht7AILwwG9LL.N7o_
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 23 Jun 2011 09:37:37 -0700 PDT
Message-ID: <4E036BC1.3090400@caucho.com>
Date: Thu, 23 Jun 2011 09:37:21 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: Brodie Thiesfield <brodie@jellycan.com>
References: <1308720860.5393.18.camel@tot.local> <20110622060514.GF18843@1wt.eu> <1308738811.11941.704.camel@vulcan.aspl.local> <20110622122521.GA22198@1wt.eu> <1308756913.11941.823.camel@vulcan.aspl.local> <4E021121.5050409@caucho.com> <1308826861.11268.47.camel@tot.local> <BANLkTinnSkPx7zkBDMUk_hVyK4TrbN9=4g@mail.gmail.com>
In-Reply-To: <BANLkTinnSkPx7zkBDMUk_hVyK4TrbN9=4g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 23 Jun 2011 16:37:41 -0000

On 06/23/2011 04:26 AM, Brodie Thiesfield wrote:
> On Thu, Jun 23, 2011 at 8:01 PM, Francis Brosnan Blázquez
> <francis@aspl.es>  wrote:
>> Hi Scott,
>>> No. It's like a HTTP chunked POST, where the application receives a
>>> stream of data, not the underlying HTTP chunks.
>>>
>>> A server (or client) which exposes the frames as its primary API is
>>> doing it wrong.
>
>> ..and you really think this API is suitable for a message oriented
>> protocol? (I assuming your fread concept will return bytes as it comes
>> not complete messages)
> Scott understood you and was only talking about the data, however the
> file stream API metaphor might be distracting.
>
> Websocket is a message based protocol, but the message contents are
> byte streams that might be split into any number of frames. So your
> websocket layer notifies your upper layer only of the messages and
> bytes. The frames are a websocket layer concept that the next layer
> has no need to know of.

+1

Yes, that's exactly what I'd meant.

If you use the stream model (assuming it's not too distracting), the 
FILE/fread ends when the message ends. Each new message produces a new 
FILE as the new stream which ends when the new message is fully read.

The application sees messages as distinct byte/char-streams but doesn't 
see the frames.

For example, the API could have a callback to the application for each 
message:

class WebSocketHandler {
   void onBinaryMessage(InputStream is);
   void onTextMessage(Reader in);
}

The InputStream/Reader produces bytes/chars until the message is done 
and then returns EOF.

-- Scott

> The websocket layer will tell the upper layer about the start of a
> message, then feed it bytes until the message is complete, then tell
> it that the message is complete. The bytes may come from a single
> frame, or multiple frames. The upper layer has no need to know.
>
> Think of the processing as something like the following (note that
> control frames, compression, etc is ignored):
>
> while have connection:
>      receive frame header
>      if first frame in message:
>          notify application layer of the start of a message
>      receive bytes up to max of frame length:
>          pass bytes up to the application layer as message data
>      if last frame in message:
>          notify application layer that the message is complete
>
> The frames are never notified to the application layer. It doesn't need to know.
>
> Brodie
>
>
>