Re: [hybi] frame length encoding

[Salvatore Loreto <[e-mail]>]

On 8/21/10 9:59 PM, Pieter Hintjens wrote:
> On Sat, Aug 21, 2010 at 9:34 PM, John Tamplin<[e-mail]>  wrote:
>
>    
>> But those are going to be highly compressible, and will easily compress to
>> under 126 bytes, even with some application level framing around them.
>>      
> Compression is not an option for low-latency cases (where volumes are
> in the millions of messages /second).  We're already finding that
> zero-copy techniques halve the cost of processing.  So the sweet spot
> for these really high volume messages remains above 127 bytes IMO.
> However, websockets is not intended for the financial markets, and
> probably won't ever be used for such volumes.
>
>    
>> 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)

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com