[whatwg] WebSockets: UDP

[Erik Möller]

On Tue, 01 Jun 2010 21:14:33 +0200, Philip Taylor  
<excors+whatwg at gmail.com> wrote:

> 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 was hoping to be able to avoid looking at what the interfaces of a high  
vs low level option would look like this early on in the discussions, but  
perhaps we need to do just that; look at Torque, RakNet etc and find a  
least common denominator and see what the reactions would be to such an  
interface. Game companies are pretty restrictive about what they discuss,  
but I think I know enough game devs to at least get some good feedback on  
what would be required to make it work well with their engine/game.

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

Yeah I wouldn't put it like that when asking :) I'm really not trying to  
sell my view, I just like to see real browser gaming in a not too distant  
future.

>
> 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.
[...]
>
> 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.

So, what would the minimal set of limitations be to make a "UDP WebSocket"  
browser-safe?

-No listen sockets
-No multicast
-Reliable handshake with origin info
-Automatic keep-alives
-Reliable close handshake
-Socket is bound to one address for the duration of its lifetime
-Sockets open sequentially (like current DOS protection in WebSockets)
-Cap on number of open sockets per server and total per user agent


-- 
Erik Möller
Core Developer
Opera Software