On Tue, 01 Jun 2010 21:14:33 +0200, Philip Taylor
<excors+wha...@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
