Re: [hybi] Frame size

[Mike Belshe <[e-mail]>]

On Sun, Apr 18, 2010 at 9:06 PM, Scott Ferguson <[e-mail]> wrote:

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

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.

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.

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