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

-- 
regards, Kornel

Reply via email to