[whatwg] [hybi] WebSockets: UDP
emoller at opera.com
Fri Jun 11 03:18:24 PDT 2010
On Fri, 11 Jun 2010 00:21:38 +0200, Mark Frohnmayer
<mark.frohnmayer at gmail.com> wrote:
> TorqueSocket is not in the same category as RakNet or OpenTNL
Ah, sorry I got the names mixed up, I meant to say RakNet/OpenTNL and not
> 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.
Absolutely, that's why the path-MTU attribute was suggested. The ~64k
limit is an absolute limit though at which sends can be rejected
immediately without even trying.
> If WebSocket supports an encrypted and unencrypted mode, why would the
> real-time version not support data security and integrity?
The reasoning was that if you do need data security and integrity the
secure websocket over TCP uses the same state-of-the-art implementation as
the browsers already have implemented. Secure connections over UDP would
either require a full TCP over UDP implementation (to use TLS) or a second
implementation that would need to be maintained. That implementation would
be either a very complex piece or software or clearly inferior to that
users are accustomed to.
So what's a good use-case where you want a secure connection over UDP and
cannot use a second TLS connection?
> 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).
Right, this is probably an area that needs to be looked more carefully at
if/when real work is started on a 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.
Yes, no doubt it's useful for those implementing higher level APIs. As
usual it's a matter of at what level to place the API.
More information about the whatwg