[whatwg] [hybi] WebSockets: UDP
emoller at opera.com
Thu Jun 10 12:35:39 PDT 2010
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
and work on-top of the much smaller hopefully cross-browser compatible
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
-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
-Automatic keep-alives (to detect force close at remote host and keep NAT
-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
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
More information about the whatwg