Re: [hybi] Max frame size

Francis Brosnan Blazquez <francis@aspl.es> Wed, 22 June 2011 15:35 UTC

Return-Path: <francis@aspl.es>
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 4818821F84A2 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 08:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.934
X-Spam-Level: **
X-Spam-Status: No, score=2.934 tagged_above=-999 required=5 tests=[AWL=0.650, 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]
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 mJLK5WAAOo6G for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 08:35:18 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBAB21F849C for <hybi@ietf.org>; Wed, 22 Jun 2011 08:35:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id 746A71170003; Wed, 22 Jun 2011 17:35:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cRqp8ShiJ3l; Wed, 22 Jun 2011 17:35:12 +0200 (CEST)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id 387B41170001; Wed, 22 Jun 2011 17:35:12 +0200 (CEST)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: Willy Tarreau <w@1wt.eu>
In-Reply-To: <20110622122521.GA22198@1wt.eu>
References: <1308720860.5393.18.camel@tot.local> <20110622060514.GF18843@1wt.eu> <1308738811.11941.704.camel@vulcan.aspl.local> <20110622122521.GA22198@1wt.eu>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: ASPL
Date: Wed, 22 Jun 2011 17:35:13 +0200
Message-ID: <1308756913.11941.823.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
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: Wed, 22 Jun 2011 15:35:19 -0000

Hi Willy,

> But why would it strip the frame header ? It should simply pass the frame
> header and stream the data.

I'm trying to figure how the use case for this would be. 

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

> The server should proceed exactly as it would proceed if receiving a large
> POST. All file transfer applications which support large POSTs (webmails
> etc...) don't buffer everything, they pass it as a stream. Do you imagine
> if the server had to buffer a DVD image or something like this before passing
> it to the application ?

I see your example but this is not the same. In the POST case you have a
single app handling its data (HTTP). 

In the websocket case you have a webserver + an application level code
that implements an application protocol that is unknown to the webserver
so it is not a nice pattern to just pass a file descriptor to the app
level...

> I don't see the difference with frames. You can call the application saying
> "hey, here come 5 GB of data, please read them from this connection handle".

Ok, the way it should be done, assuming we have a message/frame oriented
protocol, is that the app level register a handler which is called every
time a single frame is received. 

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

> Regards,
> Willy
> 

-- 
Francis Brosnan Blázquez <francis.brosnan@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

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). 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 (Madrid).