[whatwg] WebSockets: UDP

[Mike Belshe]

On Tue, Jun 1, 2010 at 4:24 AM, Kornel Lesinski <kornel at geekhood.net> wrote:

> On 1 Jun 2010, at 11:12, Erik Möller wrote:
>
> > 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.
>
> SCTP would be ideal for this. It's connection-oriented, but supports
> multistreaming (can deliver messages out of order, without head of line
> blocking).
>
> http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol


FYI:   SCTP is effectively non-deployable on the internet today due to NAT.

+1 on finding ways to enable UDP.  It's a key missing component to the web
platform.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100601/e3a940b7/attachment-0002.htm>