Re: [hybi] Interface for Large Frames

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C6BC1F0C47 for <>; Wed, 22 Jun 2011 15:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gxVO0QLhGiwA for <>; Wed, 22 Jun 2011 15:18:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F2A141F0C45 for <>; Wed, 22 Jun 2011 15:18:11 -0700 (PDT)
Message-ID: <>
Date: Wed, 22 Jun 2011 23:18:04 +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: Bob Gezelter <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] Interface for Large Frames
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 22:18:12 -0000

On 06/22/2011 10:58 PM, Somebody in the thread at some point said:
> The FILE methods in stdio.h include a "number of bytes" parameter. In
> the context of the WebSocket protocol, the natural unit would appear to
> be the frame. Once the frame has been retrieved by a user, then a
> character-by-character state machine may (emphasis MAY) be appropriate,
> however, the interface is best (most efficient) if entire frames can be
> transferred at a time.

That's true but it's inherently fragile when 63-bit length frames are 
allowed by the protocol but cannot be buffered.  It means there's a 
ceiling where the code must act different or break based on its 
buffering arrangements.

Requiring maximum frame size buffers per connection may also present 
scaling problems.

> If programs must pull one character at a time, the efficiency will be
> poor, with a large amount of overhead being consumed moving up and down
> the call tree.

Well, it depends.  You'll notice that "...and just buffer payload 
locally using any size buffer or none at all...", so buffering at the 
layer that contains the state machine is possible with this technique 
and reduces the calls to the handler dramatically even with a small 
buffer.  And with this technique, there's no dependency on that buffer 
size compared to max frame size so scalability is improved.