W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2010

[whatwg] [hybi] WebSockets: UDP

From: Erik Möller <emoller@opera.com>
Date: Wed, 02 Jun 2010 10:47:57 +0200
Message-ID: <op.vdnz17bsr4mipi@emoller-pc.gothenburg.osa>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC