Re: [hybi] Max frame size

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 (e.g. you're not saying
anything the group hasn't already considered).

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.

-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<https://www.ietf.org/mailman/listinfo/hybi>
>>
>>
>>
> ______________________________**_________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman/listinfo/hybi>
>