[whatwg] WebSocket support in HTML5

[Philipp Serafin]

On Sat, Sep 27, 2008 at 12:58 PM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> If you are in control of the server, you can simulate datagram sockets with
> one-shot controlled sockets

I do not agree with Richard at all, but I have to play devil's
advocate here because I think such a simulation would be pretty
useless.
After all, more or less the only situation you'd want to use UDP
outside a LAN is when TCP doesn't fit your needs, e.g. because the
flow control does more harm than good to your use-case or because your
peers have not enough processing power for a full TCP implementation.
Simulating UDP via TCP would pretty much combine the disadvantages of
both protocols.
Also, you already need a full roudtrip to initiate a TCP connection, a
second one to perform the WS handshake and a third one to close the
connection. Data not taken into account. You can hardly repeat that
for every datagram you want to send.

That out of the way, I think the "structure in content" approach is
preferable because in the end it makes the whole feature easier to use
and accessible to a much broader range of web authors. Because a WS
stream has standardized metadata and delimiters, you can easily build
a generic framework that processes those parts for you.
This is especially important if you DON'T have full control over the
server, which I believe is the case for the majority of smaller sites
that use a shared hosting solution. Those hosters usually don't give
their clients access to the underlying processes at all. All the
clients can do is upload static files and script files that get
executed in a restricted environment. It's really hard to integrate
pure, persistent connections into such a setup. With WS, a hoster
could for example have a demon listen to all incoming WS connections
and call the client's scripts whenever a data frame has been received.
In short, it's much easier for them to manage persistent connections
if there is a standardized structure. And if it's easier for them,
hopefully the support for this feature will grow.

As for the restriction of unicode data, of course we could just use an
octet counting mechanism like HTTP does instead of a fixed delimiter.
This would allow arbitrary data inside the WS frames. On the other
hand, this might make it easier to spoof existing protocols. Would the
benefits of this outweigh the risks?

Note that it was a conscious design decision to make WS incompatible
with existing protocols, because the risk for misuse is too great.

If you need your web app to inerac with a specific service, it should
be easy to write a generic proxy that does the handshake, strips out
the frame marks and transforms the data.

Also, it's not like the other technologies would vanish all of a
sudden. If you have sufficient control over your server, you can STILL
use Java or Flash sockets.

Regards,
Philipp Serafin