[whatwg] WebSockets: UDP

[Philip Taylor]

On Tue, Jun 1, 2010 at 2:00 PM, Erik Möller <emoller at opera.com> wrote:
> [...]
> I've never heard any gamedevs complain how poorly UDP matches their needs so
> I'm not so sure about that, but you may be right it would be better to have
> a higher level abstraction. If we are indeed targeting the game developing
> community we should ask for their feedback rather than guessing what they
> prefer. I will grep my linked-in account for game-devs tonight and see if I
> can gather some feedback.

More feedback is certainly good, though I think the libraries I
mentioned (DirectPlay/OpenTNL/RakNet/ENet (there's probably more)) are
useful as an indicator of common real needs (as opposed to edge-case
or merely perceived needs) - they've been used by quite a few games
and they seem to have largely converged on a core set of features, so
that's better than just guessing.

I guess many commercial games write their own instead of reusing
third-party libraries, and I guess they often reimplement very similar
concepts to these, but it would be good to have more reliable
information about that.

> I suspect they prefer to be "empowered with UDP" rather than "boxed into a
> high level protocol that doesn't fit their needs" but I may be wrong.

If you put it like that, I don't see why anybody would not want to be
empowered :-)

But that's not the choice, since they could never really have UDP -
the protocol will perhaps have to be Origin-based, connection-oriented
(to exchange Origin information etc), with complex packet headers so
you can't trick it into talking to a DNS server, with rate limiting in
the browser to prevent DOS attacks, restricted to client-server (no
peer-to-peer since you probably can't run a socket server in the
browser), etc.

Once you've got all that, a simple UDP-socket-like API might not be
the most natural or efficient way to implement a higher-level
partially-reliable protocol - the application couldn't cooperate with
the low-level network buffering to prioritise certain messages, it
couldn't use the packet headers that have already been added on top of
UDP, it would have to send acks from a script callback which may add
some latency after a packet is received from the network, etc. So I
think there's some tradeoffs and it's not a question of one low-level
protocol vs one strictly more restrictive higher-level protocol.

> So the question to the gamedevs will be, and please make suggestions for
> changes and I'll do an email round tonight:
>
> If browser and server vendors agree on and standardize a socket based
> network interface to be used for real-time games running in the browsers, at
> what level would you prefer the interface to be?
> (Note that an interface for communicating reliably via TCP and TLS are
> already implemented.)
> - A low-level interface similar to a plain UDP socket
> - A medium-level interface allowing for reliable and unreliable channels,
> automatically compressed data, flow control, data priority etc
> - A high-level interface with "ghosted entities"

That first option sounds like you're offering something very much like
a plain UDP socket (and I guess anyone who's willing to write their
own high-level wrapper (which is only hundreds or thousands of lines
of code and not a big deal for a complex game) would prefer that since
they want as much power as possible), but (as above) I think that's
misleading - it's really a UDP interface on top of a protocol that has
some quite different characteristics to UDP. So I think the question
should be clearer that the protocol will necessarily include various
features and restrictions on top of UDP, and the choice is whether it
includes the minimal set of features needed for security and hides
them behind a UDP-like interface or whether it includes higher-level
features and exposes them in a higher-level interface.

-- 
Philip Taylor
excors at gmail.com