[whatwg] [hybi] WebSockets: UDP
mark.frohnmayer at gmail.com
Thu Jun 10 15:21:38 PDT 2010
On Thu, Jun 10, 2010 at 12:35 PM, Erik Möller <emoller at opera.com> wrote:
> 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
TorqueSocket is not in the same category as RakNet or OpenTNL -- the
point of the TorqueSocket effort was to find the web equivalent of a
minimal UDP'ish socket (understanding of course that it would be in
the context of a connected packet stream). RakNet and OpenTNL provide
higher level data guarantees, RPC, object state replication, etc.
TorqueSocket is a simple send/recv packet protocol - it does no TCP
over UDP or bandwidth throttling.
> 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.
I'd recommend doing some real-world testing for max packet size. Back
when the original QuakeWorld came out it started by sending a large
connect packet (could be ~8K) and a good number of routers would just
drop those packets unconditionally. The solution (iirc) was to keep
all packet sends below the Ethernet max of 1500 bytes. I haven't
verified this lately to see if that's still the case, but it seems
real-world functionality should be considered.
> 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.
If WebSocket supports an encrypted and unencrypted mode, why would the
real-time version not support data security and integrity?
> -Client puzzles to reduce connection depletion/CPU depletion attacks to the
> 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.
Client puzzles allow the host to allocate zero resources for a pending
connection until it knows that the source address of the client
request is valid and that the client has done some work; you could
still take a similar (though not client computationally expensive)
approach by having the host hash the client identity (IP/port) with a
server-generated secret. Any approach that allocates memory or does
work on the host without verifying the client source address first is
vulnerable to a super-trivial DOS attack (connection depletion before
even any bandwidth overwhelm).
> -Packet delivery notification to be a part of the API.
> Again this is believed to be better left outside the UDP-WebSockets spec
unnecessary extra overhead (sequence numbering, acknowledgements) that
could easily be a part of the underlying protocol. Having implemented
multiple iterations of a high-level networking API, the notification
function is a critical, low-overhead tool for making effective
higher-level data guarantees possible.
More information about the whatwg