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
