Re: [hybi] Frame size

[Mike Belshe <[e-mail]>]

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

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


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

Are there really other protocols to be solved with the same websockets
framework?  (if so, let's list them!)  I think we're all in disagreement
because we haven't agreed on what problem we're solving.  If we agreed that
the problem we're solving is providing a protocol to support a
WebSockets-like API to web developers, we'd likely be done.  Another option
would be to say we don't like the current WebSockets API proposal, and offer
up an alternative API which we're trying to support (maybe one which does
streaming or needs chunking?). But I haven't seen that either.

Our charter is fairly clear, I think: "*The Hypertext-Bidirectional (HyBi)
working group will seek standardization of one approach to maintain
bidirectional communications between the HTTP client, server and
intermediate entities, which will provide more efficiency compared to the
current use of hanging requests.*"  Further, "*In particular, the working
group has liaised with the W3C WebApps working group around the WebSockets
protocol and the need to support the WebSocket API..*."  I realize there is
some flexibility in the charter for a more generic protocol, but there is no
guidance as to what other problems we're trying to solve.  I think this is
where each of us carries our own opinions to the table.

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.

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