Re: [hybi] Frame size

[Scott Ferguson <[e-mail]>]

Mike Belshe wrote:
>
>
> On Sun, Apr 18, 2010 at 9:06 PM, Scott Ferguson <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Mike Belshe wrote:
>
>
> Sorry - we're thinking of two different things for chunking.  I was 
> thinking of chunking in terms of enabling multiplexing; but maybe I 
> was off from the original poster.  Sorry if that is the case.
Gotcha. I'm pretty sure both ideas are going on at the same time :).
>
> As for the example you pose - of course this is important.  But isn't 
> this up to the user of the websocket (e.g. the application)?  I don't 
> think the websocket protocol needs to do anything for this - as 
> chunking for two different applications is likely to be very different.
I think chunking for many/most applications will be similar because it's 
a pretty generic need, like HTTP's chunking is.  In the case of HTTP, 
many developers don't need to be aware that their output is getting 
chunked; it just works. I'd expect the same to be true for the simple 
frame/message model. Assuming it does cover the common cases, it's a 
useful abstraction to give users.

To tie this into the KISS requirement, it's a way to keep the 
client/server APIs and application code simple for the simple cases. 
Applications don't need to know about frames/chunks, just messages.

-- Scott

> Mike
>  
>
>
>     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
>
>