Re: [hybi] frame length encoding

[Salvatore Loreto <[e-mail]>]

On 8/22/10 9:31 PM, Scott Ferguson wrote:
> 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|   |       |               |
> +-+-+---+-------+---------------+
>    
(again as individual)

Hi Scott

almost, what I had in mind was

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

in this way we have the possibility to add 1 extra bit to OPCODE in the 
case we will run out of it

> 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
>    
+1
> (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.)
>    

For versioning I don't have a strong opinion, it was just an example of 
the fact that we need enough room (bits) for extansions

-- 
Salvatore Loreto
www.sloreto.com