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

"Len Holgate" <len.holgate@gmail.com> Wed, 13 July 2011 08:22 UTC

Return-Path: <len.holgate@gmail.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 3CA0F21F8868; Wed, 13 Jul 2011 01:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9ZmnjdGzlTHT; Wed, 13 Jul 2011 01:22:05 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEEDC21F8872; Wed, 13 Jul 2011 01:22:04 -0700 (PDT)
Received: by wyj26 with SMTP id 26so4383191wyj.31 for <multiple recipients>; Wed, 13 Jul 2011 01:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=o3Ti2WnO7biG3hLZoMhgKZywgFFWW6yagtm4Hmq5sPs=; b=OH14pUMLfPvhpH3SjL2KQdcVF4K3PUCx4SxUU+kZKvUe9C2QfWNgXssJloQdqjLEqs LWVTlq4Jrbnkq8Hbo596bjFgc5eb8Fe0wN+qx6tphKZE+mr92kLsLOjJ5cnnvHkJHAY9 A4NC+hFuldNv9n7N0C5yQnKkjgnG7vPSKAsL0=
Received: by 10.227.166.9 with SMTP id k9mr725962wby.57.1310545323515; Wed, 13 Jul 2011 01:22:03 -0700 (PDT)
Received: from Venus (cpc7-glfd6-2-0-cust20.6-2.cable.virginmedia.com [86.27.227.21]) by mx.google.com with ESMTPS id o19sm7084193wbh.9.2011.07.13.01.22.01 (version=SSLv3 cipher=OTHER); Wed, 13 Jul 2011 01:22:02 -0700 (PDT)
From: "Len Holgate" <len.holgate@gmail.com>
To: "'Francis Brosnan Blazquez'" <francis@aspl.es>, "'Hybi'" <hybi@ietf.org>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com><4E1BD054.7010103@gmail.com> <1310480036.26452.329.camel@vulcan.aspl.local>
Date: Wed, 13 Jul 2011 09:21:57 +0100
Message-ID: <1bc701cc4135$efbf8540$0a00a8c0@Venus>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <1310480036.26452.329.camel@vulcan.aspl.local>
Thread-Index: AcxAngKgFP4EGmhgTeejP3KMKb6S9wAljiJQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
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: Wed, 13 Jul 2011 08:22:09 -0000

Francis,

I agree with your points and would welcome a max frame size negotiation
header.

However, whilst an intermediary might legitimately change the fragmentation
of a frame it cannot merge complete messages. If, in your example, your
client limited itself to messages of a certain size then it doesn't matter
what intermediaries do to the frames as the maximum frame size would be
limited to the maximum message size that the client sends. The only time
this wouldn't work is if you were using a 'message of infinite fragments'
where you start with a fragmented frame and don't know when you'll send the
final fragment.

The communication between peers about maximum message sizes supported could
just as easily be in the application level protocol that you're running over
the websocket connection.

Len
www.lenholgate.com

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On 
> Behalf Of Francis Brosnan Blazquez
> Sent: 12 July 2011 15:14
> To: Hybi
> 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
> 
> 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
>