[hybi] WebSockets: UDP

Erik Möller <emoller@opera.com> Tue, 01 June 2010 10:25 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 566BA3A67B5 for <hybi@core3.amsl.com>; Tue, 1 Jun 2010 03:25:23 -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 lbfXh0heOGUg for <hybi@core3.amsl.com>; Tue, 1 Jun 2010 03:25:20 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 2DE6E3A67B3 for <hybi@ietf.org>; Tue, 1 Jun 2010 03:25:19 -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 o51AP5ut017916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <hybi@ietf.org>; Tue, 1 Jun 2010 10:25:06 GMT
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
References: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
To: Hybi <hybi@ietf.org>
Date: Tue, 01 Jun 2010 12:24:58 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: Erik Möller <emoller@opera.com>
Organization: Opera Software
Message-ID: <op.vdl9vwk1r4mipi@emoller-pc.gothenburg.osa>
In-Reply-To: <op.vdl9bszhr4mipi@emoller-pc.gothenburg.osa>
User-Agent: Opera Mail/10.53 (Win32)
Subject: [hybi] 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: Tue, 01 Jun 2010 10:25:23 -0000

[originally (mis-)posted to WHATWG, reposting here]

The use case I'd like to address in this post is Real-time client/server
games.

The majority of the on-line games of today use a client/server model over
UDP and we should try to give game developers the tools they require to
create browser based games. For many simpler games a TCP based protocol is
exactly what's needed but for most real-time games a UDP based protocol is
a requirement. Games typically send small updates to its server at 20-30Hz
over UDP and can with the help of entity interpolation and if required
entity extrapolation cope well with intermittent packet loss. When a
packet loss occur in a TCP based protocol the entire stream of data is
held up until the packet is resent meaning a game would have to revert to
entity extrapolation possibly over several seconds, leading to an
unacceptable gameplay experience.

It seems to me the WebSocket interface can be easily modified to cope with
UDP sockets (a wsd: scheme perhaps?) and it sounds like a good idea to
leverage the work already done for WebSockets in terms of interface and
framing.

The most important distinction between ws: and wsd: is that messages sent
by send() in wsd: need not be acknowledged by the peer nor be resent. To
keep the interface the same to the largest possible extent I'd suggest
implementing a simple reliable 3-way handshake over UDP, keep-alive
messages (and timeouts) and reliable close frames. If these are
implemented right the interface in it's entirety could be kept. Only one
new readonly attribute long maxMessageSize could be introduced to describe
the min path MTU (perhaps only valid once in connected mode, or perhaps
set to 0 or 576 initially and updated once in connected mode). This
attribute could also be useful to expose in ws: and wss: but in that case
be set to the internal limit of the browser / server.

The actual content of the handshake for wsd: can be vastly simplified
compared to that of ws: as there's no need to be http compliant. It could
contain just a magic identifier and length encoded strings for origin,
location and protocol.

To minimize the work needed on the spec the data framing of wsd: can be
kept identical to that of ws:, though I'd expect game developers would
choose whatever the binary framing will be once the spec is done.

I'd be very interested to hear peoples opinion on this.


-- 
Erik Möller
Core Developer
Opera Software