[hybi] max frame size, was: frame length encoding

[Julian Reschke <[e-mail]>]

On 22.08.2010 18:39, John Tamplin wrote:
> ...
> Just because the JS API today passes the messages totally in RAM, there
> is no reason that it can be extended to support a stream-like API if
> processing larger messages becomes justified.  However, at the framing
> level, we have to have something in place such that v1.0 implementations
> written against this spec can interoperate with later extensions, so it
> seems prudent to make sure the protocol is sufficient for any reasonably
> forseeable needs.  There were several strong arguments that 32-bits
> isn't enough, and the next logical step up is 63/64-bits.
>
> Personally, I would be perfectly happy with a 32-bit maximum frame
> length, and let senders fragment larger messages.  However, there were
> significant objections (see the discussions link from
> http://www.ietf.org/mail-archive/web/hybi/current/msg03399.html for
> details) about being required to fragment a message when its size was
> known, and the fact that it made "fire and forget" of sending the
> message contents with a single sendfile() call impossible (when larger
> than 4G).  Thus, it seemed likely the only way to gain consensus was to
> support a maximum frame length much larger than 32 bits.
> ...

Well, we need only rough consensus.

32 bits has the advantage that it's big enough for almost all use case 
we can currently think of.

32 bits has the drawback that people who cross the 2/4GB barrier might 
encounter interop problems because of insufficient testing.

One way to address this problem are BIG WARNINGs in the spec, and a test 
suite.

Best regards, Julian