[whatwg] [hybi] WebSockets: UDP

[Erik Möller]

During the Opera Network Seminar held in Oslo this week I discussed the  
possible addition of a new wsd: URL scheme to WebSockets that would allow  
relaxing the packet resends and enable demanding real-time applications to  
be written. I'd like to summarize some of the conclusions a few of us came  
to when discussing this (informally).

Regarding the discussions on at what level the API of a UDP-WebSocket  
should be: One of the most important aspects to remember are that for this  
to be interesting to application developers we need all the browser  
vendors to support this feature in a compatible way. Therefore it doesn't  
seem reasonable to standardize and spec a higher level network API akin to  
RakNet / Torque Socket and hope all vendors will be willing to spend the  
(quite large amount of) resources required for their own implementation of  
TCP over UDP, bandwidth throttling etc. In our opinion we're much better  
off standardizing a minimal UDP-like socket. For most application  
developers it seems likely they will be able to work with a mix of  
XMLHttpRequest, WebSockets and this new UDP-WebSocket to achieve the same  
functionality provided by those higher level APIs. If deemed necessary for  
an application the higher level network API can be written in JavaScript  
and work on-top of the much smaller hopefully cross-browser compatible  
UDP-WebSocket API.

As discussed the following features/limitations are suggested:
-Same API as WebSockets with the possible addition of an attribute that  
allows the application developer to find the path MTU of a connected  
socket.
-Max allowed send size is 65,507 bytes.
-Socket is bound to one remote address at creation and stays connected to  
that host for the duration of its lifetime.
-IP Broadcast/Multicast addresses are not valid remote addresses and only  
a set range of ports are valid.
-Reliable handshake with origin info (Connection timeout will trigger  
close event.)
-Automatic keep-alives (to detect force close at remote host and keep NAT  
traversal active)
-Reliable close handshake
-Sockets open sequentially (like current DOS protection in WebSockets) or  
perhaps have a limit of one socket per remote host.
-Cap on number of open sockets per host and global user-agent limit.

Some additional points that were suggested on this list were:
-Key exchange and encryption
  If you do want to have key exchange and encryption you really shouldn't  
reinvent the wheel but rather use a secure WebSocket connection in  
addition to the UDP-WebSocket. Adding key exchange and encryption to the  
UDP-WebSocket is discouraged.

-Client puzzles to reduce connection depletion/CPU depletion attacks to  
the handshake.
  If the goal is to prevent DOS attacks on the accepting server this seems  
futile. Client puzzles only raises the bar ever so slightly for an  
attacker so this is also discouraged.

-Packet delivery notification to be a part of the API.
  Again this is believed to be better left outside the UDP-WebSockets spec  
and implemented in javascript if the application developer requires it.

Best Regards,

-- 
Erik Möller
Core Developer
Opera Software