Re: [hybi] Frame size

[Mike Belshe <[e-mail]>]

On Mon, Apr 19, 2010 at 10:59 AM, Scott Ferguson <[e-mail]> wrote:

> Mike Belshe wrote:
>
>>
>> So, given the WebSockets API, how would chunks be used?  The application
>> calls send(DOMString).  There is no need for chunking here, because the full
>> string (and it's length) is already available.  Or did I miss something?
>>
> Yes, you forgot the server side :)
>
> Buffering the message on the client is essentially unavoidable and not a
> major problem, because the client is only managing a small number of
> connections. The server is running 100s or possibly 1000s and really doesn't
> want to buffer entire messages before sending it out.
>
>
>>    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.
>>
>>
>> KISS, I think, would have solve the problem in the simplest way to support
>> the WebSockets API.
>>
> The chunking is needed to support the client WebSockets API to receive
> messages.
>
> Since the WebSockets API needs to receive the entire message, not the
> individual frames, the chunking is needed to support the API on the
> receiving end. It's true that the browser client buffers the entire response
> (not the only client, BTW).
>
> In other words, it is the simplest way to support the WebSockets API.
>
>
>> Are there really other protocols to be solved with the same websockets
>> framework?  (if so, let's list them!)
>>
> Technically, every application will invent its own protocol. "tic-tac-toe"
> uses a tic-tac-toe protocol. XMPP (or HMTP) over WebSockets. REST over
> websockets.  WebSockets isn't a full protocol stack, its just a layer
> (though an important one.)
>
>  My biggest fear is that a generic protocol will take a very high burden of
>> proof for implementation and deployment because it will offer so many
>> features and that this time will only delay solving the one problem we do
>> know of (fix hanging GET) while not really solving any other specific
>> problem either.  By contrast, if we stay focused on the problem at hand,
>> coming to agreement on the WebSockets protocol seems quite achievable.
>>
> We're talking about a very simple protocol. No one wants to make it
> complicated. Here's essentially the entire frame grammar (for something like
> Martin's proposal.)
>
>  stream ::= message*
>  message ::= non-final-frame* final-frame
>  non-final-frame ::= (0x4000 | length) <octet-data>
>  final-frame ::= (0x0000 | length) <octet-data>
>
> Done.
>

You've convinced me.

Thanks,
Mike


>
> If we do add the keepalive capabilities, close messages, error conditions
> (and the NAT discussion is convincing me that heartbeat/keepalive might be
> needed), those are a few, enumerated, specific packets.
>
> 0xff00 - keepalive packet
> 0xffff - graceful close
> 0xff01 - negotiation (?) e.g. requesting a server heartbeat/keepalive
> timeout if keepalives are implemented as unidirectional heartbeats.
>
> etc. (I'd think these would be extremely limited in number.)
>
> The concepts are more complicated than the bytes will be.
>
> -- Scott
>
>  I'm relatively new to this group and may be completely off base - so my
>> apologies if I am :-)  But I was at the IETF mtg on the topic, and it didn't
>> seem that we were  in agreement on what we're doing there either...
>>
>
>
>> Mike
>>
>>
>>
>>
>>    -- 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
>>
>>
>>
>>
>>
>