Re: [hybi] Max frame size

"Andy Green (林安廸)" <> Thu, 23 June 2011 11:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36D9411E80E7 for <>; Thu, 23 Jun 2011 04:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XY5MMhsbKTbb for <>; Thu, 23 Jun 2011 04:12:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A388711E807F for <>; Thu, 23 Jun 2011 04:12:38 -0700 (PDT)
Message-ID: <>
Date: Thu, 23 Jun 2011 12:12:36 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: =?UTF-8?B?RnJhbmNpcyBCcm9zbmFuIEJsw6F6cXVleg==?= <>
References: <1308720860.5393.18.camel@tot.local> <> <1308738811.11941.704.camel@vulcan.aspl.local> <> <1308756913.11941.823.camel@vulcan.aspl.local> <> <1308826861.11268.47.camel@tot.local>
In-Reply-To: <1308826861.11268.47.camel@tot.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] Max frame size
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jun 2011 11:12:39 -0000

On 06/23/2011 12:01 PM, Somebody in the thread at some point said:

> While I see this API makes the buffering (max frame size) problem for
> the websocket developer to be not an issue, is in fact not solving but
> moving the problem to the app level where, again, the application will
> have to buffer the content until a message is completed.
> I still think we need a way to each party to notify its buffering or
> message size limit capabilities, *mainly*, because we have a framing
> designed to notify messages, defined as *units* by the draft, not
> bytes...

The way I think of it is that frames are directly analogous to TCP/IP 
packets, one level up.

Everyone accepts application code has to act defensively and not make 
assumptions about tcp / ip packet lengths and if they got merged or 
fragmented along the way.  How much turns up at any given time when 
poll() or select() tells you something came must be treated like a 
random number you find out when you read from the socket and it says how 
much was ready.  You can't be expecting 32 bytes every time because you 
think that the sender always sends 32 byte packets.

It's the same with frames, reliance on assumptions about when they turn 
up, in how many pieces of what size needs to be defended against in the 
code so it's not vulnerable to problems.  If you take that approach it 
naturally leads you away from this idea you need to buffer whole frames.