Re: [hybi] frame length encoding

[Scott Ferguson <[e-mail]>]

Salvatore Loreto wrote:
> On 8/21/10 9:59 PM, Pieter Hintjens wrote:
>> On Sat, Aug 21, 2010 at 9:34 PM, John Tamplin<[e-mail]>  wrote:
>>
>>    
>>> The main difference between #0 and #1 is that #0 uses one of three 
>>> reserved
>>> bits.  They are easy to spend, but then when we find out we need 
>>> them it
>>> becomes much more expensive to get them back.
>>>      
>> Indeed.  Adding another 8 reserved bits in the header does not seem 
>> wasteful.
>>    
> (as individual)
>
> I agree on the fact that with the fact that adding an extra byte to 
> the WebSocket header would
> cost very little also for very small payload.
>
> I don't understand because 4bytes basic header (+length field 
> +payload) as defined in 
> http://tools.ietf.org/html/draft-ietf-core-coap-01#section-3.1
> is good for constrained devices and constrained networks: btw 
> constrained devices are the one usually just exchanging 1byte payload
>
> and we can not define a 2byte basic header (+length field +payload) 
> for WebSocket, reducing the complexity present in the previous proposals
> using 1 or 2 bits to indicate the length header,
> and also providing more room (bits) for future extensions (actually we 
> could also think to use 2bits for version the protocol)


Something like the following?

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+---+-------+---------------+
|F|T|LEN|OPCODE | reserved(8)   |
|I|M|   |       |               |
|N|L|   |       |               |
+-+-+---+-------+---------------+

LEN: 00 = 1 byte length
     01 = 2 byte length
     10 = reserved (or 4 byte)
     11 = 8 byte length

It might also be possible to define 00 to use the reserved byte for an 
ultra-compact header, or 00 could be ultra-compact, and 01 could be the 
normal 1 byte after the reserved and 10 be 2 byte.

LEN: 00 = 0 byte length (uses reserved byte)
     01 = 1 byte length
     10 = 2 byte length
     11 = 8 byte length

(For versioning, a hello opcode might be better than taking up frame 
bits, and a hello opcode would also allow digest-authentication 
credentials to piggyback on the handshake replacing the 8 random bytes, 
which is an idea I'd like to bring up when we get to discussing the 
handshake because I'd love to save a roundtrip when authenticating 
non-browser clients.)

-- Scott
>
> cheers
> /Sal
>