Re: [hybi] Frame size

[Scott Ferguson <[e-mail]>]

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.

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