Re: [hybi] Max frame size

Norio Kobota <norio.kobota@jp.sony.com> Wed, 22 June 2011 08:55 UTC

Return-Path: <Norio.Kobota@jp.sony.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 ADA6C11E809A for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 01:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level:
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 GpXgC8OtYcdf for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 01:55:11 -0700 (PDT)
Received: from ms4.sony.co.jp (ms4.sony.co.jp [IPv6:2001:cf8:0:56::198]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8289E800F for <hybi@ietf.org>; Wed, 22 Jun 2011 01:55:09 -0700 (PDT)
Received: from mta8.sony.co.jp (mta8.sony.co.jp [IPv6:2001:cf8:0:191::15]) by ms4.sony.co.jp (R8/Sony) with ESMTP id p5M8t7QA012352 for <hybi@ietf.org>; Wed, 22 Jun 2011 17:55:07 +0900 (JST)
Received: from mta8.sony.co.jp (localhost [127.0.0.1]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p5M8t7O3017628 for <hybi@ietf.org>; Wed, 22 Jun 2011 17:55:07 +0900 (JST)
Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p5M8t6Qr017419 for <hybi@ietf.org>; Wed, 22 Jun 2011 17:55:07 +0900 (JST)
Received: from jptkyxim101.jp.sony.com ([43.15.31.5]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 17:55:00 +0900
Received: from [43.0.235.115] ([43.0.235.115]) by jptkyxim101.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 17:55:01 +0900
Message-ID: <4E01ADE7.7050800@jp.sony.com>
Date: Wed, 22 Jun 2011 17:55:03 +0900
From: Norio Kobota <norio.kobota@jp.sony.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: hybi@ietf.org
References: <1308720860.5393.18.camel@tot.local>
In-Reply-To: <1308720860.5393.18.camel@tot.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 22 Jun 2011 08:55:01.0202 (UTC) FILETIME=[12107320:01CC30BA]
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 08:55:11 -0000

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