[whatwg] WebSockets: UDP

[Erik Möller]

On Tue, 01 Jun 2010 13:34:51 +0200, Philip Taylor  
<excors+whatwg at gmail.com> wrote:

> 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).
>

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.

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.  
Those who have the knowledge, time and desire to implement their own  
reliable channels/flow control/security over UDP would be free to do so,  
those who couldn't care less can always use ws: or wss: for their reliable  
traffic and just use UDP where necessary.

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"

Oh, and I guess we should continue this discussion on the HyBi list... my  
fault for not posting there in the first place.

-- 
Erik Möller
Core Developer
Opera Software