Re: [hybi] Frame size

[Scott Ferguson <[e-mail]>]

Ian Hickson wrote:
> 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.
>   
Unless the spec gets an editor who understands the basics of wire 
protocols, discussion is becoming pointless.

Or one capable of basic programming, really. "The complications of 
measuring UTF-8 length"? "chunking mechanics [are] non-trivial?"

-- Scott
>
>   
>>  - 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.
>
>