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

Greg Wilkins <gregw@intalio.com> Wed, 13 July 2011 02:53 UTC

Return-Path: <gregw@intalio.com>
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 D3F2A21F8B84; Tue, 12 Jul 2011 19:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.726
X-Spam-Level:
X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 w3oGWmzNoFfo; Tue, 12 Jul 2011 19:53:54 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8E0721F8B83; Tue, 12 Jul 2011 19:53:53 -0700 (PDT)
Received: by vws12 with SMTP id 12so5820591vws.31 for <multiple recipients>; Tue, 12 Jul 2011 19:53:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.234 with SMTP id o10mr742781vdv.174.1310525632902; Tue, 12 Jul 2011 19:53:52 -0700 (PDT)
Received: by 10.52.115.103 with HTTP; Tue, 12 Jul 2011 19:53:52 -0700 (PDT)
In-Reply-To: <1310480036.26452.329.camel@vulcan.aspl.local>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <4E1BD054.7010103@gmail.com> <1310480036.26452.329.camel@vulcan.aspl.local>
Date: Wed, 13 Jul 2011 12:53:52 +1000
Message-ID: <CAH_y2NF3pxbUJctg7P1qGNR+mvzaw80+Axh6kCYwx93HiQocug@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Francis Brosnan Blazquez <francis@aspl.es>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Hybi <hybi@ietf.org>, 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: Wed, 13 Jul 2011 02:53:55 -0000

Francis et al,

not also that the protocol does support fragmentation and a 1004 frame
too large error.
Even the 1004 error does not carry an indication of what an acceptable
size is, so the client/tool/intermediary that receives a 1004 will
either have to fail or guess a smaller frames size - potentially
binary chopping down to find an acceptable size, which might be sub
optimal.

I simple optional header in the handshake declaring the max frame size
(which intermediaries could adjust) would be very complimentary to the
existing fragmentation and 1004 features and I can't think of any
significant down side.

regards

On 13 July 2011 00:13, Francis Brosnan Blazquez <francis@aspl.es> wrote:
> 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).
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>