Re: [hybi] [whatwg] WebSockets: UDP

[Erik Möller <[e-mail]>]

On Wed, 02 Jun 2010 19:48:05 +0200, Philip Taylor  
<[e-mail]> wrote:

I'm glad the discussion on this has taken off a bit. I've spoken to a few  
more game devs and even though it's still relatively few there's a slight  
majority that prefer the interface to be at the "Torque/RakNet-level"  
rather than at the "UDP-socket-wrapper-level". I'm hoping I can talk a few  
of them into joining the list and taking a more active part in the  
discussions.

> So they seem to suggest things like:
> - many games need a combination of reliable and unreliable-ordered and
> unreliable-unordered messages.

One thing to remember here is that browsers have other means for  
communication as well. I'm not saying we shouldn't support reliable  
messages over UDP, but just pointing out the option. I believe for example  
World of Warcraft uses this strategy and sends reliable traffic over TCP  
while movement and other real-time data goes over UDP.

> - many games need to send large messages (so the libraries do
> automatic fragmentation).

Again, this is probably because games have no other means of communication  
than the NW-library. I'd think these large reliable messages would mostly  
be files that need to be transferred asynchronously for which browsers  
already have the tried and tested XMLHttpRequest.

> - many games need to efficiently send tiny messages (so the libraries
> do automatic aggregation).

This is probably true for many other use-cases than games, but at least in  
my experience games typically use a bit-packer or range-coder to build the  
complete packet that needs to be sent. But again, it's a matter of what  
level you want to place the interface.

> Perhaps also:
> - Cap or dynamic limit on bandwidth (you don't want a single web page
> flooding the user's network connection and starving all the TCP
> connections)
> - Protection against session hijacking

Great

> - Protection against an attacker initiating a legitimate socket with a
> user and then redirecting it (with some kind of IP (un)hijacking) to a
> service behind the user's firewall (which isn't a problem when using
> TCP since the service will ignore packets when it hasn't done the TCP
> handshake; but UDP services might respond to a single packet from the
> middle of a websocket stream, so every single packet will have to be
> careful not to be misinterpreted dangerously by unsuspecting
> services).

I don't quite follow what you mean here. Can you expand on this with an  
example?

-- 
Erik Möller
Core Developer
Opera Software