Re: [hybi] max frame size. was: consensus call on ability to announce max frame size

Can you please explain why we may need a size limit on a frame? It does not really makes sense to me - if a frame is too big for you for some reasons, act as intermediary and split single frame into multiple ones (assuming you understand extensions, which should be very common). 

I see some benefits in having a limit on a message size i.e. you can easily provide a message based APIs. However, as you mentioned stream APIs are a norm in HTTP world and personally I do not see a reason for any limits on message/frame size.

Kind regards,
Piotr

-----Original Message-----
From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Greg Wilkins
Sent: Saturday, July 30, 2011 5:40 PM
To: Hybi
Subject: [hybi] max frame size. was: consensus call on ability to announce max frame size

Changing topic to avoid debate in consensus call thread.

On 30 July 2011 17:46, John Tamplin <jat@google.com> wrote:
> I see no mention of maximum message size in this consensus call, only 
> maximum frame size.

Sorry if that muddied the water. But I just wanted to be crystal clear we are talking about frames not messages.

On 30 July 2011 17:31, Willy Tarreau <w@1wt.eu> wrote:
> I'd also argue that HTTP has been living for a decade with support for 
> chunked encoding which does not set a limit on chunk size nor on 
> message size and has not had any trouble with that.

But HTTP also does not have a chunk-too-large error code.
Implementations are forced to deal with large chunks.  This is often
no too difficult because stream APIs are the norm for HTTP.   Large
sizes are harder to handle in the datagram API of websocket.

On 30 July 2011 23:34, Thomson, Martin <Martin.Thomson@commscope.com> wrote:
> Given that there is no constraint on message size, this capability is pointless.  Any peer that receives this indication does not need to change their behaviour in any meaningful way.  Messages of any size can be sent regardless of what frame size is supported.

Note sure if you are talking about max message or max frame size?

But a peer that does not respect a max frame indication and does not change it's behaviour will then just receive frame-too-large errors in
response.   If we allow frame-too-large errors, then surely we need a
way to communicate what is not too large.

Also, while I think a max frame size should be optional to declare, I think that once it is declared it should be mandatory for senders to respect that limit.

> That said, such a negotiation might be crucial to an effective multiplexing scheme.  I suggest that this be deferred and included as part of the multiplexing work.

I think it is more than just MUX that needs this.  Because of the datagram style API of websockets, applications will not be stream based (blocked reading content), but will be called back when frames and/or messages are received.  Thus there will be implementations that have fixed buffer sizes and will not work with large frames and/or
messages.      For large messages, there is not much the
implementations can do to influence the applications, so I don't see a limit being worthwhile.  But for a max frame size, it is pretty simple for implementations to fragment messages to respect a limit.

regards
_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi