Re: [hybi] Interface for Large Frames

Francis Brosnan Blázquez <> Thu, 23 June 2011 11:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B6A511E80B6 for <>; Thu, 23 Jun 2011 04:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.584
X-Spam-Level: **
X-Spam-Status: No, score=2.584 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6FeAsMyNKZcL for <>; Thu, 23 Jun 2011 04:18:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9CFF611E807F for <>; Thu, 23 Jun 2011 04:18:52 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D58D01170003; Thu, 23 Jun 2011 13:18:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vh32gAX1nZIc; Thu, 23 Jun 2011 13:18:48 +0200 (CEST)
Received: from [] (unknown []) (Authenticated sender: acinom) by (Postfix) with ESMTPA id 2DA351170001; Thu, 23 Jun 2011 13:18:48 +0200 (CEST)
From: Francis Brosnan =?ISO-8859-1?Q?Bl=E1zquez?= <>
To: "\"Andy Green" =?UTF-8?Q?=28=E6=9E=97=E5=AE=89=E5=BB=B8=29=22?= <>
In-Reply-To: <>
References: <> <>
Content-Type: text/plain; charset=ISO-8859-15
Date: Thu, 23 Jun 2011 13:18:49 +0200
Message-Id: <1308827929.11268.63.camel@tot.local>
Mime-Version: 1.0
X-Mailer: Evolution
Content-Transfer-Encoding: 8bit
Cc:, Bob Gezelter <>
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: Thu, 23 Jun 2011 11:18:53 -0000

Hi Andy,

> 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.

We have a framing with fragmentation support so each application could
decide how to handle such situations (63 bit frames), in some cases
better than stream oriented API because the application can choose the
chunk size it likes where stream oriented will return what is available
at the call time...

Whatever method used by a websocket implementation (stream oriented or
message/frame notification) I believe it is a contradiction to state
websocket is protocol designed to exchange *units* as messages but not
giving required elements to handle pointed situations, forcing people to
design stream oriented, and hence, force websocket users to

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

At the end, someone will buffer, or the websocket engine or the
application level. I think a checked websocket implementation will
buffer better than an application on top of it so, the scaling problem,
if present, will affect both methods...
Francis Brosnan Blázquez <>
91 134 14 22 - 91 134 14 45 - 91 116 07 57

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
ASPL garantiza que los datos serán tratados con la finalidad de mantener
las oportunas relaciones comerciales o promocionales con usted o la
entidad que usted representa. No obstante, usted puede ejercitar sus
derechos de acceso, rectificación, cancelación y oposición dispuestos en
la mencionada Ley Orgánica, notificándolo por escrito a ASPL -
Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de Henares