Re: [hybi] Frame size

[Scott Ferguson <[e-mail]>]

Mike Belshe wrote:
>
>
>      - to leave room for transport control messages inserted by the
>        transport (such as graceful close and transport error indicators),
>        so that applications don't have implement them
>
>
> The protocol has implicit chunks - frames.  Having a second level of 
> chunking has little value here.  Or at least I haven't heard the use case.
Same as HTTP/1.1 chunking: when the length of dynamically produced 
content cannot be calculated beforehand.

Unless the frames can be assembled into messages, it's not implicit 
chunking.
>
> Applications that want to use chunking can do so already by just using 
> smaller frames.
I don't see how that makes any sense.

Here's a basic, typical application. Suppose messages are XMPP packets 
(ours are binary HMTP, but the idea's the same). The message is 
identical to the entire packet.  The sender don't know how big the 
packet will be until serialization completes, but receivers may need to 
know the message/packet end before parsing.

For sanity and performance, we use a fixed-size output buffer for each 
packet. Each frame is a fragment of the XMPP packet and the message only 
ends with the final frame. We don't know the length of the entire packet 
until the entire thing is serialized. So the protocol needs multiple 
frames forming a message.

This is a very basic pattern. There's nothing unusual about it and I 
don't see how smaller frames addresses the issue, because it's the 
message boundary that's important. If you're not marking message 
boundaries, you may as well eliminate the frames entirely and just have 
raw TCP.

16 vs 32 vs variable-length integer encoding isn't hugely important. 
Chunking is important.
> Overall, I'm talking about simplicity.  A 32bit fixed length is simple 
> and sufficient for purposes today and tomorrow.
HTTP's fixed Content-Length is not sufficient for the same reasons.

-- Scott