Re: [hybi] Frame size

On Mon, Apr 19, 2010 at 1:14 AM, Greg Wilkins <gregw@webtide.com> wrote:

> Mike Belshe wrote:
> > Sorry - we're thinking of two different things for chunking.  I was
> > thinking of chunking in terms of enabling multiplexing; but maybe I was
> > off from the original poster.  Sorry if that is the case.
>
> Mike,
>
> I was not proposing Fragmentation for multiplexing.   I was
> suggesting it for error handling (which I guess can be considered
> multiplexing control frames).
>

> The scenario that I'm concerned about is that we need
> a way to handle too-large-handle messages.
>
> Currently the specification says that the endpoint simply
> closes the connection.  But that is unsatisfactory as the
> reason for the close is not known and the too-large message
> will just be resent.
>
> So we need some way of sending an error status back, saying
> that the message being sent is too-large.
> But if our framing allows arbitrary large frames, then
> we conditions in which there is no way of sending any error
> state.
>
> If both endpoints start sending a too-large-to-handle
> message at the same time, then both endpoints will
> want to send a too-large error frame.   But neither
> will be able to because they are in the process of
> sending a large frame.
>
> This is not an insurmountable problem, and I'm sure
> might be able to invent ways to abort frames and send
> error state etc.  However, I believe that such error
> handling in an unlimited frame-size environment will
> be significantly more complex that a fragmentation
> mechanism.
>
> Fragmentation does not avoid the need for error
> handling for too-large-to-handle messages.  But
> by removing the possibility of too-large-to-handle
> frames, it means we are more likely to be able to
> simply send the error messages.
>
>
> regards.
>
> PS> Another alternative is to mandate a negotiation
> of maximum message size in the handshake.
> Or somebody can come up with a good simple design for
> error handling with large (or unlimited) frames.
>

OK - this approach seems like the simplest one; each side sends a
"max-frame-size" in its headers during the upgrade.  These values do not
need to be the same - each side declares the maximum size it is willing to
receive.

If this is the only use case which requires a complex frame header, then
this seems simpler than fragmentation/reassembly/chunking approaches, no?

Mike

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