Re: [hybi] Max frame size
Francis Brosnan Blazquez <francis@aspl.es> Wed, 22 June 2011 10:12 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 B66A811E8098 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:12:13 -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 T13K9Oy0HKQd for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:12:13 -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 A1E8211E807F for <hybi@ietf.org>; Wed, 22 Jun 2011 03:12:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id E8B641170003; Wed, 22 Jun 2011 12:11:43 +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 EU2Zy5bRj565; Wed, 22 Jun 2011 12:11:42 +0200 (CEST)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id 7DAFB1170001; Wed, 22 Jun 2011 12:11:42 +0200 (CEST)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: ifette@google.com
In-Reply-To: <BANLkTinBH_UAj7kA5uKVJ2Rvg329xxfbCCrxYPTW-MhH_=-HwA@mail.gmail.com>
References: <1308720860.5393.18.camel@tot.local> <4E01ADE7.7050800@jp.sony.com> <BANLkTinBH_UAj7kA5uKVJ2Rvg329xxfbCCrxYPTW-MhH_=-HwA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: ASPL
Date: Wed, 22 Jun 2011 12:11:43 +0200
Message-ID: <1308737503.11941.641.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 10:12:13 -0000
Hi Ian, > We spent almost a year before we got to the point on agreeing on > framing. We're now in last call. It's not the time to re-open such > lengthy conversations based on individual preferences I'm not trying to reconsider framing; that's ok. I'm talking about providing a way to each party to advice is buffering capabilities which has nothing to do with the framing format. > (e.g. you're not saying anything the group hasn't already considered). Possibly but the problem is yet not addressed. I think this will cause lot of wrong patterns and a security problem at the server side like passing to the app level not completed frame (unfragemented or not) but just octects because the server was unable to buffer. That is, assuming a 2MB message, with a 64KB buffer limit, the app level may receive a first indication that a frame was received, only 64kb, and subsequent indications of pending content without header? If this is the pattern accepted, this will make easy do stream injection for those servers that won't buffer 20MB content until pass a complete frame to the app level.. > As for negotiation, that's a very complex topic, which, while > interesting, is not necessary for the base protocol to function. I > would suggest that if you're interested you propose text for an > extension that would handle negotiation of such parameters as > optimal/max frame sizes etc. Ok, I'll wait for your comments since I believe this is not an individual preference but a risk at the server side. The idea is to ensure server side delivers complete frames to the app level, not octects without header.. > -Ian > > On Wed, Jun 22, 2011 at 1:55 AM, Norio Kobota > <norio.kobota@jp.sony.com> wrote: > Hi, > > I think that 63 bits-length is too big for single frame, too. > But there is no need to provide any header in handshake. > > The websocket frame format has a FIN bit for fragment message. > So we can use this bit when we want to send very long message. > > I think that the websocket frame format can be more simple. > > +-+-+-+-+-------+-+-------------+-------------------------------+ > |F|R|R|R| opcode|M| Payload len | Extended payload length > | > |I|S|S|S| (4) |A| (7) | (16) > | > |N|V|V|V| |S| | (if payload len==126) > | > | |1|2|3| |K| | > | > +-+-+-+-+-------+-+-------------+-------------------------------+ > | Masking-key, if MASK set to 1 | Masking-key (continued) > | > +-------------------------------+-------------------------------+ > | Payload Data... > | > +---------------------------------------------------------------+ > | Payload Data (continued) > | > +---------------------------------------------------------------+ > or > +-+-+-+-+-------+-+-------------+-------------------------------+ > |F|R|R|R| opcode|M| reserve | Payload length > | > |I|S|S|S| (4) |A| (7) | (16) > | > |N|V|V|V| |S| | > | > | |1|2|3| |K| | > | > +-+-+-+-+-------+-+-------------+-------------------------------+ > | Masking-key, if MASK set to 1 | Masking-key (continued) > | > +-------------------------------+-------------------------------+ > | Payload Data > | > +---------------------------------------------------------------+ > | Payload Data (continued) > | > +---------------------------------------------------------------+ > > Regards, nori > > > > (2011/06/22 14:34), Francis Brosnan Blázquez wrote: > Hi, > > Current frame design allows to send a very big single > frame size (63 > bits). In terms of memory a websocket server will have > problems with > this because he must buffer all content until he can > deliver the entire > message to the app level (assuming message based API). > > I think we need a way for servers (and possibly > clients) to notify each > other which is the max frame size each part is willing > to accept so each > site administrator can configure this according to its > resources, > application type, number of connections, etc. > > I think a simple header notified at the websocket > handshake will provide > this valuable control to each party: > > Max-Frame-Size: 4096 > > This will cause each party to fragment application > level messages if it > is found bigger than Max-Frame-Size. > > In the same direction, if not provided Max-Frame-Size, > it looks > reasonable to assume a default value for this header. > Again, 4096 bytes > looks like a good value. > > What do you think? > > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi -- 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] Max frame size Francis Brosnan Blázquez
- Re: [hybi] Max frame size Willy Tarreau
- Re: [hybi] Max frame size Norio Kobota
- Re: [hybi] Max frame size Ian Fette (イアンフェッティ)
- Re: [hybi] Max frame size Francis Brosnan Blazquez
- Re: [hybi] Max frame size Francis Brosnan Blazquez
- Re: [hybi] Max frame size Ian Fette (イアンフェッティ)
- Re: [hybi] Max frame size Francis Brosnan Blazquez
- Re: [hybi] Max frame size Francis Brosnan Blazquez
- Re: [hybi] Max frame size Arman Djusupov
- Re: [hybi] Max frame size Willy Tarreau
- Re: [hybi] Max frame size Francis Brosnan Blazquez
- Re: [hybi] Max frame size Andy Green (林安廸)
- Re: [hybi] Max frame size Scott Ferguson
- Re: [hybi] Max frame size Iñaki Baz Castillo
- Re: [hybi] Max frame size Francis Brosnan Blázquez
- Re: [hybi] Max frame size Andy Green (林安廸)
- Re: [hybi] Max frame size Brodie Thiesfield
- Re: [hybi] Max frame size Scott Ferguson