Re: [hybi] thewebsocketprotocol #28 (new): Fragmentation

[Zhong Yu <[e-mail]>]

On Wed, Nov 24, 2010 at 4:40 AM, Jamie Lokier <[e-mail]> wrote:
> Zhong Yu wrote:
>> The most important thing I think is the abstraction WS provides to app
>> developers. Right now the abstraction is simple -- one message after
>> another. The simplicity is a good thing, if it is compromised I don't
>> know what websocket is supposed to be any more.
>
> Right now, WS provides *two* abstractions: The one to app developers,
> and the one over TCP.
>
> Some of us believe they *should not be the same* due to network
> engineering issues *because that makes the app developer's job easier*.
>
> Right now, the "simplicity" of WS means *robust* apps need to
> implement half of TCP in Javascript on the client, which is not a good

That's where frameworks come in, which can provide degrees of
robustness suitable for different applications. I don't think WS
should or could address these application level concerns.

The #1 feature needed for robustness is auto reconnect. Nobody
proposed to build that feature in the WS protocol.

> sign.  (For example the "tic tac toe" example, which is supposed to be
> simple, can lock up on real networks: No more moves when a TCP is
> silently dropped.  A HTTP equivalent doesn't have this problem.)
>
> Why do you think the two abstractions should be the same?

They should not be. But no matter how complex the protocol must
become, I wish it won't jeopardize the simple application abstraction.
I don't want WebSocket to become WebService, and everybody needs to
buy a 1000 page "The Definitive Guide".

>
> HTTP's app abstraction is quite different from its wire abstraction,
> and that separation has worked extremely well for everyone.
>
>> Let's just kill fragments and don't even think about any advanced
>> features that depend on it. Every message stays in one frame, even
>> ones with unknown lengths.
>
> Technical question: How would you send a binary message with unknown
> length, in a single frame without fragments?

chunks within a frame. frames can't overlap, therefore messages cannot overlap.

>
> That said, I'm not sure why we need to support messages with unknown
> lengths in advance in the simplest protocol level anyway.  Is there a
> use case for control frames such as graceful close or error indication
> in the middle of a message?
>
> The use cases which come to my mind are: Keepalives - those are
> desirable in th middle of a large message, if the message is being
> generated slowly;

If it is so slow and it exceeds the timeout, who are we to say that
the connection is "alive"? The ping-pong test certainly says nothing
about application liveliness. I don't see the point.

> and graceful close/error indicator, in the case of
> WS being forwarded over a proxy.  But neither of those behaviours are
> in the simplest protocol.
>
> Imho, what we do need to do, though, is make it clear what proxies are
> supposed to do when forwarding a large or unbounded-length WS
> message...  Forward every byte as soon as they receive it, buffer
> whole messages if they so wish, or something between?  The first is
> inefficient over TCP (it can make unnecessary packets and unnecessary
> delays), and the second would lead to breakage because proxy behaviour
> would be different from non-proxy behaviour.  Right now, proxies doing
> CONNECT implement the first.
>
> -- Jamie
>