Re: [hybi] [whatwg] WebSockets: UDP

[Mark Frohnmayer <[e-mail]>]

On Fri, Jun 11, 2010 at 3:18 AM, Erik Möller <[e-mail]> wrote:
> 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.

Ah, gotcha.  I was trying to separate the cases of MTU before
fragmentation and maximum packet size (fragmented) before some host
along the way silently discards the packet.

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

I guess I was thinking more in the direction of a well conceived, well
reviewed protocol (TLS-level of scrutiny) for encryption of the
unreliable packet stream - a secure data stream is a useful primitive
and would otherwise have to be implemented at the application level.
I'd rather have security done well at the platform level (what
developers expect from a modern browser).  I'm not sure I'd agree that
it has to be super complex in order to be effective, and could likely
use much of the same functionality (ciphers, etc).

I'm also not assuming a second message channel -- if a developer is
using an API like TNL or RakNet that handles higher level data and
message guarantees then the addition of multiple message streams is
unneeded complexity.

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

Agreed.  This goes back to Phil's point that UDP by itself isn't a
great primitive to build on -- the key element for real-time
applications is that dropped packets shouldn't stall the communication
stream nor be automatically retransmitted.  A slightly higher level
approach (connection handshake, security, etc), as long as its
overhead is low, could be a more effective foundation to build on.

Cheers,
Mark