Re: [hybi] Frame size

[Ian Hickson <[e-mail]>]

On Fri, 16 Apr 2010, Thomson, Martin wrote:
> 
> Proposal:
> 
>  - Frame size is indicated up front.

This seems incompatible with the requirement that we not expose amateur 
programmers to the complications of measuring UTF-8 strings.


>  - Frames are binary.

Not sure what this means in this context, unless you mean the length is in 
bytes and not in characters; if you mean the latter then I agree that any 
length in the protocol should be in bytes.


>  - Frame size be strictly limited (2 octets should suffice).
>  - Sub-protocol needed if messages are larger than the max frame.

This seems like it would make the API highly unpredictable. For example, 
it would mean that you could transmit 65,536 characters if they were the 
character "X", but only 21,845 if they were the character U+263A. That 
would be very confusing. Similarly, if we add compression, it would mean 
that how many bytes you could pass in the send() method would depend on 
how well it compressed. This would result in a very bad programming 
experience, especially for anyone new to this kind of thing. (I would 
expect most subprotocols to be ridiculously primitive; asking amateurs to 
figure out chunking mechanics is non-trivial, especially if they have to 
work out where to split a UTF-16 string as exposed in JS, before it is 
converted to UTF-8 and compressed, which is what matters for deciding what 
will fit in the frame.)


> Binary frames isolate user-space (the payload) from the framing layer.  We had this discussion in the meeting (c.f. Pete Resnick's comments).  Thus, 
>  - binary frames are easier to process (intermediaries don't have to inspect every octet)
>  - kinder on implementations (framing component does not depend on UTF-8 component)
>  - isolates framing layer from the bugs of higher layers

If we were designing a protocol for experts, I would completely agree. 


> IF used for UTF-8 AND implementer counts characters instead of octets 
> THEN framing doesn't work. [...] One solution to this problem is to 
> start a frame with a known sequence of octets, so that this can be 
> detected.

That's an interesting approach, but I worry that anything hardcoded like 
this would be handled in ways that defeat the purpose. This is why, for 
instance, the proposed handshake uses unpredictable keys to force the 
server to prove it read the handshake -- otherwise, servers written by 
amateurs might not actually read the handshake but just send back the 
right response, simply assuming the handshake came from a Web Socket 
server. If it weren't for targetting amateur programmers, the handshake 
could be a heck of a lot shorter; we could even do away with the 
requirement for a round trip and for the client to test the handshake, 
since we could assume the server would only accept connections that were 
trusted.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'