Re: [hybi] [whatwg] WebSockets: UDP

Erik Möller <emoller@opera.com> Wed, 02 June 2010 08:48 UTC

Return-Path: <emoller@opera.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58A528C168 for <hybi@core3.amsl.com>; Wed, 2 Jun 2010 01:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.699
X-Spam-Level:
X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzKc+BTGd8EW for <hybi@core3.amsl.com>; Wed, 2 Jun 2010 01:48:38 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 5360F3A6968 for <hybi@ietf.org>; Wed, 2 Jun 2010 01:48:23 -0700 (PDT)
Received: from emoller-pc.gothenburg.osa (046-tdc.opera.com [213.236.208.46] (may be forged)) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o528m6UA026426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Jun 2010 08:48:07 GMT
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: Mark Frohnmayer <mark.frohnmayer@gmail.com>
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa> <AANLkTin8TYLeOdZmKbs6IqklsS5P24Qd4kqtTV_UXp-l@mail.gmail.com> <op.vdmg3ov6r4mipi@emoller-pc.gothenburg.osa> <AANLkTim2j9xbgW4fnKYy69uZ9KwBaDvs1ypu92pG1Hxo@mail.gmail.com> <op.vdm0lrqmr4mipi@emoller-pc.gothenburg.osa> <AANLkTilAy-494wt5UebjRsdDkhTVS3LXp-toxRsuBs2Q@mail.gmail.com>
Date: Wed, 02 Jun 2010 10:47:57 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: Erik Möller <emoller@opera.com>
Organization: Opera Software
Message-ID: <op.vdnz17bsr4mipi@emoller-pc.gothenburg.osa>
In-Reply-To: <AANLkTilAy-494wt5UebjRsdDkhTVS3LXp-toxRsuBs2Q@mail.gmail.com>
User-Agent: Opera Mail/10.53 (Win32)
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Hybi <hybi@ietf.org>, Philip Taylor <excors+whatwg@gmail.com>
Subject: Re: [hybi] [whatwg] WebSockets: UDP
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2010 08:48:40 -0000

On Wed, 02 Jun 2010 01:07:48 +0200, Mark Frohnmayer  
<mark.frohnmayer@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