Re: [hybi] Max frame size

"Andy Green (林安廸)" <> Wed, 22 June 2011 15:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0155411E807A for <>; Wed, 22 Jun 2011 08:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jrFv4WWZNeQL for <>; Wed, 22 Jun 2011 08:48:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6320111E811B for <>; Wed, 22 Jun 2011 08:48:45 -0700 (PDT)
Message-ID: <>
Date: Wed, 22 Jun 2011 16:48:43 +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: Francis Brosnan Blazquez <>
References: <1308720860.5393.18.camel@tot.local> <> <1308738811.11941.704.camel@vulcan.aspl.local> <> <1308756913.11941.823.camel@vulcan.aspl.local>
In-Reply-To: <1308756913.11941.823.camel@vulcan.aspl.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: Wed, 22 Jun 2011 15:48:46 -0000

On 06/22/2011 04:35 PM, Somebody in the thread at some point said:

Hi -

> So, if the frame received is less than 127 or 65535 bytes the server
> reads everything, checks header correctness and that the header
> represents bits advised, etc, and then pass the data through a handler
> to the user level code...but if the data is bigger, you pass a file
> descriptor??

There's more than one way to write the code to deal with this, but the 
way that is immune to running out of buffer space or funny boundary 
conditions / packet fragmentation fragility is to pass everything 
through a bytewise state machine, as Willy says treat it strictly as a 
stream of bytes.

Then you really don't care about what size packets it comes in, how big 
a frame can be, you interpret the frame header as each byte of it comes 
in and just buffer payload locally using any size buffer or none at all, 
and spill those up to the guy who takes payload for that kind of frame 
as it fills up or you see it was the last byte.

> This way, the handler is called, for example, each 4k, so the handler
> can receive those 5GB with minimum memory allocation and with the
> security it handles messages not raw access to a file descriptor (with
> the security and code complexity implications it has).

I guess you could write it like that but it has other problems, like 
blocking and timeout management that are handled neatly by having the 
state machine as the one place for everything.