Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard: request for max frame size

Francis Brosnan Blazquez <francis@aspl.es> Tue, 12 July 2011 14:14 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 EE83321F9175; Tue, 12 Jul 2011 07:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.884
X-Spam-Level: ****
X-Spam-Status: No, score=4.884 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 KVRCILMAgSjh; Tue, 12 Jul 2011 07:14:01 -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 4537321F9171; Tue, 12 Jul 2011 07:13:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id B4179FCC1F7; Tue, 12 Jul 2011 16:13:55 +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 CTIRERmHfrQM; Tue, 12 Jul 2011 16:13:54 +0200 (CEST)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id A9487FCC076; Tue, 12 Jul 2011 16:13:54 +0200 (CEST)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: Hybi <hybi@ietf.org>
In-Reply-To: <4E1BD054.7010103@gmail.com>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <4E1BD054.7010103@gmail.com>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: ASPL
Date: Tue, 12 Jul 2011 16:13:56 +0200
Message-ID: <1310480036.26452.329.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 8bit
Cc: ietf@ietf.org, draft-ietf-hybi-thewebsocketprotocol@tools.ietf.org
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard: request for 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: Tue, 12 Jul 2011 14:14:02 -0000

Hi,

Recently, I posted [1] that websocket protocol should include an
indication about max frame size that is willing to accept the connecting
peer. 

Many pointed this is not an issue because you could use a stream
oriented API (like TCP send/recv and others), but that only bypasses the
problem (in some cases) not solves it.

Websocket protocol is frame based and every frame based protocol
designed until now has/need such feature or similar. Even TCP, for those
that proposes to use a stream oriented API as a solution, includes a
more complex mechanism than a simple max frame size (window based ack),
so each party can control/inform the sender. This is critical.

A good example for this would be the next. Let suppose you have a
constrained memory device (either because it is small or because it
accepts a large amount of connections). On that device you deploy a
websocket app that only accepts small messages (< 512 bytes, let's
say). 

In this context, you can hard code at your web app (javascript) that
must not send messages larger than this size (so you control websocket
payload size) and in the case you need to, you must split them
properly. 

However, even with this mechanism, you have no warranty that the browser
or an intermediary will join those messages into a single frame, causing
your device to receive a bigger message/frame than expected.

Assuming this I think we would require either to include a
Max-Frame-Size indication (or a really poor solution: to explicitly
state on the draft that frames must not be coalesced by intermediaries
or browsers). 

Regards,

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg07641.html
-- 
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).