[whatwg] WebSockets: UDP

[Philip Taylor]

On Tue, Jun 1, 2010 at 11:12 AM, Erik Möller <emoller at opera.com> wrote:
> The use case I'd like to address in this post is Real-time client/server
> games.
>
> The majority of the on-line games of today use a client/server model over
> UDP and we should try to give game developers the tools they require to
> create browser based games. For many simpler games a TCP based protocol is
> exactly what's needed but for most real-time games a UDP based protocol is a
> requirement. [...]
>
> It seems to me the WebSocket interface can be easily modified to cope with
> UDP sockets [...]

As far as I'm aware, games use UDP because they can't use TCP (since
packet loss shouldn't stall the entire stream) and there's no
alternative but UDP. (And also because peer-to-peer usually requires
NAT punchthrough, which is much more reliable with UDP than with TCP).
They don't use UDP because it's a good match for their requirements,
it's just the only choice that doesn't make their requirements
impossible.

There are lots of features that seem very commonly desired in games: a
mixture of reliable and unreliable and reliable-but-unordered channels
(movement updates can be safely dropped but chat messages must never
be), automatic fragmentation of large messages, automatic aggregation
of small messages, flow control to avoid overloading the network,
compression, etc. And there's lots of libraries that build on top of
UDP to implement protocols halfway towards TCP in order to provide
those features:
http://msdn.microsoft.com/en-us/library/bb153248(VS.85).aspx,
http://opentnl.sourceforge.net/doxydocs/fundamentals.html,
http://www.jenkinssoftware.com/raknet/manual/introduction.html,
http://enet.bespin.org/Features.html, etc.

UDP sockets seem like a pretty inadequate solution for the use case of
realtime games - everyone would have to write their own higher-level
networking libraries (probably poorly and incompatibly) in JS to
provide the features that they really want. Browsers would lose the
ability to provide much security, e.g. flow control to prevent
intentional/accidental DOS attacks on the user's network, since they
would be too far removed from the application level to understand what
they should buffer or drop or notify the application about.

I think it'd be much more useful to provide a level of abstraction
similar to those game networking libraries - at least the ability to
send reliable and unreliable sequenced and unreliable unsequenced
messages over the same connection, with automatic
aggregation/fragmentation so you don't have to care about packet
sizes, and dynamic flow control for reliable messages and maybe some
static rate limit for unreliable messages. The API shouldn't expose
details of UDP (you could implement exactly the same API over TCP,
with better reliability but worse latency, or over any other protocols
that become well supported in the network).

-- 
Philip Taylor
excors at gmail.com