<div class="gmail_quote">On Tue, Jun 1, 2010 at 4:24 AM, Kornel Lesinski <span dir="ltr"><<a href="mailto:kornel@geekhood.net">kornel@geekhood.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 1 Jun 2010, at 11:12, Erik Möller wrote:<br>
<br>
> The use case I'd like to address in this post is Real-time client/server games.<br>
><br>
> 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.<br>

><br>
> 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.<br>

><br>
> 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.<br>

<br>
</div>SCTP would be ideal for this. It's connection-oriented, but supports multistreaming (can deliver messages out of order, without head of line blocking).<br>
<br>
<a href="http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol" target="_blank">http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol</a></blockquote><div><br></div><div>FYI:   SCTP is effectively non-deployable on the internet today due to NAT.</div>
<div><br></div><div>+1 on finding ways to enable UDP.  It's a key missing component to the web platform. </div><div><br></div><div>Mike</div><div><br></div></div>