Re: [hybi] [whatwg] WebSockets: UDP

[Erik Möller <[e-mail]>]

On Fri, 11 Jun 2010 00:21:38 +0200, Mark Frohnmayer  
<[e-mail]> 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  
RakNet/TorqueSocket.

> 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.

> I'd propose that doing this in the javascript level would result in
> 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.

-- 
Erik Möller
Core Developer
Opera Software