Re: [hybi] frame length encoding

["Shelby Moore" <[e-mail]>]

>>  The only thing that truly matters are what kinds of messages we want to
>> handle with the protocol.  My point is that there's no reason for a
>> websocket client or server to handle a single message >4GB.
>
>
> You won't have to.  You will tell the other end your maximum frame size on
> the connection handshake, then the other end will re-fragment if
> necessary.
>
>
>>  For my chat
>> server that I'm building, any incoming message larger than 64KB is
>> likely
>> to
>> be ill-intended, and that's a very generous threshold.  Clearly the
>> threshold would be different for someone else's application.
>
> Apologies I forgot to make the above point in my prior reply. I could have
> been more concensus driven with that.

[snip]

>
> I do agree that I should not have made the point that you need to process
> 64-bit frames.  That would not be a free market. Rather we must have
> re-fragmentation, so that no WS server has to be forced into any maximum
> size.

Given the above point, those who are arguing against the CPU load to test
for value 126 and 127 to fork to 16-bit and 63-bit frame size of Option 2,
we instead could consider adding a byte to the header and give 1 to 32766
sizes without any test.  The end could set its maximum frame size to 32766
on connection handshake, and then it never needs to perform that logic in
CPU.  They just load 2 byte size field and use it.

That eliminates the 16-bit size field of Option 2.  It is extends the size
field of Option 1.

That would cost us an extra byte on every frame, but the minimum frame
size is 3 already, and those who were arguing that point, said that
network speed will increase faster than CPU because there is no way to
parallelize (use multi-cores) for a serial channel that has no rewind
feature (unless you buffer and use pipelining perhaps?).

Also what are we using the 0 size value for? Couldn't we add 1 to the size
field to get the size?

Also for the special case where the maximum frame size is set on
connection handshake to 32767 (instead of 32766), no need to escape that
into an 8 byte size field.