Re: [hybi] [whatwg] WebSockets: UDP

[Mark Frohnmayer <[e-mail]>]

On Tue, Jun 1, 2010 at 1:02 PM, Erik Möller <[e-mail]> wrote:
>
> 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.

Glad to see this discussion rolling!  For what it's worth, the Torque
Sockets design effort was to take a stab at answering this question --
what is the least-common-denominator "webby" API/protocol that's
sufficiently useful to be a common foundation for real time games.  I
did the first stab at porting OpenTNL (now tnl2) atop it; from my
reading of the RTP protocol that should easily layer as well, but it
would be worth getting the perspective of some other high-level
network stack folks (RakNet, etc).

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

Hmm... given the number of different approaches to higher-level game
networking I'd hate to see a high-level straightjacket where a
well-conceived low level API could easily support all of the existing
solutions out there.  The more complex the API the larger the attack
surface at the trusted level and the more difficulty in getting
existing stakeholders (game and browser makers) on board.

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

Only feedback here would be I think p2p should be looked at in this
pass -- many client/server game instances are peers from the
perspective of the hosting service (XBox Live, Quake, Half-Life,
Battle.net) -- forcing all game traffic to pass through the hosting
domain is a severe constraint.  My question -- what does a "webby" p2p
solution look like regarding Origin restrictions, etc?

> -No multicast

> -Reliable handshake with origin info
> -Automatic keep-alives
> -Reliable close handshake

While we're at it, I'd add key exchange, encryption and client puzzles
to reduce connection depletion/CPU depletion attacks to the handshake.
 The protocol you seem to be aiming for isn't UDP -- rather it's more
like an connected, unreliable packet stream between hosts.

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

A single UDP socket can host multiple connections (indexed by packet
source address), so even a modest limit on actual number of sockets
wouldn't be a big impediment.

I'd also advocate for packet delivery notification to be a part of the
API -- with a known success or failure status on packet delivery many
of the higher level data transmission policies become trivial, and
should be essentially zero overhead at the protocol level.  Without
notification the higher level code has to do manual packet
acknowledgement as Phil mentioned.

Regards,
Mark