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

[Jamie Lokier <[e-mail]>]

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

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?

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