- From: Erik Möller <emoller@opera.com>
- Date: Wed, 02 Jun 2010 10:47:57 +0200
On Wed, 02 Jun 2010 01:07:48 +0200, Mark Frohnmayer <mark.frohnmayer at gmail.com> wrote: > 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). For those who missed Mark's initial post on the subject his TorqueSocket API can be found here: http://github.com/nardo/torque_sockets/raw/master/TorqueSocket_API.txt Perhaps we could communally have a look at how this compares to other common network libraries to find a least common denominator of functionality? > 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? Although it sure complicates things I don't see why WebSockets couldn't be extended to allow peer-to-peer connections if we really wanted to. User agent A and B connects to WebSocket server C who keeps a list of clients connected to it. A and B are informed of the id's of connected clients and both decide to set up a peer-to-peer connection. A and B simultaneously call socket.connect_to_peer() passing a peer id and the call returns a new WebSocket in connecting mode. The user agents communicate with the server over the server-socket, retrieves the necessary information to connect to the peer including what origin to expect and off we go. (Server implementations would of course be free to not support this if they choose) As long as the usual DOS/tamper protection is there it should be possible... then there's the success rate of UDP NAT hole punching... -- Erik M?ller Core Developer Opera Software
Received on Wednesday, 2 June 2010 01:47:57 UTC