[whatwg] WebSockets: UDP

[Philip Taylor]

On Tue, Jun 1, 2010 at 9:02 PM, Erik Möller <emoller at opera.com> wrote:
> On Tue, 01 Jun 2010 21:14:33 +0200, Philip Taylor <excors+whatwg at gmail.com>
> wrote:
>
>> More feedback is certainly good, though I think the libraries I
>> mentioned (DirectPlay/OpenTNL/RakNet/ENet (there's probably more)) are
>> useful as an indicator of common real needs (as opposed to edge-case
>> or merely perceived needs) - they've been used by quite a few games
>> and they seem to have largely converged on a core set of features, so
>> that's better than just guessing.
>>
>> I guess many commercial games write their own instead of reusing
>> third-party libraries, and I guess they often reimplement very similar
>> concepts to these, but it would be good to have more reliable
>> information about that.
>>
>
> I was hoping to be able to avoid looking at what the interfaces of a high vs
> low level option would look like this early on in the discussions, but
> perhaps we need to do just that; look at Torque, RakNet etc and find a least
> common denominator and see what the reactions would be to such an interface.

I'm trying to think of them mainly as indirect examples of use cases,
rather than as direct examples of interfaces. Under the assumption
that most games either use a library like these or implement a
comparable one themselves, and that the library designs are driven by
the game requirements, if a feature is supported by most of the
libraries then it's probably needed by many games; and if a feature is
unsupported in many of the libraries then it's probably unnecessary
for most games. (Also an assumption: games running in web browsers
will have similar needs to native games (though lagging many years
behind state-of-the-art); and we only ought to aim to support the
needs of most games, not all games.)

So they seem to suggest things like:
- many games need a combination of reliable and unreliable-ordered and
unreliable-unordered messages.
- many games need to send large messages (so the libraries do
automatic fragmentation).
- many games need to efficiently send tiny messages (so the libraries
do automatic aggregation).
- many games need some kind of security (I have no idea exactly what,
or how much is still relevant when the client is JavaScript and
trivial to tamper with).
- many games need to prioritise certain messages when bandwidth is limited.
- most games don't need low-level control over individual datagrams
and precise packet loss feedback, they're okay with the socket details
being abstracted away.
- ... probably lots more (and/or less); I'm not very familiar with the
details of the libraries so this is unlikely to be an accurate list,
but I think it may be a useful way to analyse the requirements.

(The solution suggested in your initial post
(socket.send(data_smaller_than_mtu) going over UDP) seems to be one
extreme, which combines with higher-level JS libraries to satisfy
these needs. I think I initially suggested the other extreme of
encoding all the features into the browser API. I guess the best
tradeoff depends largely on what non-game use cases exist that should
be satisfied by the same solution.)

> So, what would the minimal set of limitations be to make a "UDP WebSocket"
> browser-safe?
>
> -No listen sockets
> -No multicast
> -Reliable handshake with origin info
> -Automatic keep-alives
> -Reliable close handshake
> -Socket is bound to one address for the duration of its lifetime
> -Sockets open sequentially (like current DOS protection in WebSockets)
> -Cap on number of open sockets per server and total per user agent

Perhaps also:
- Cap or dynamic limit on bandwidth (you don't want a single web page
flooding the user's network connection and starving all the TCP
connections)
- Protection against session hijacking
- Protection against an attacker initiating a legitimate socket with a
user and then redirecting it (with some kind of IP (un)hijacking) to a
service behind the user's firewall (which isn't a problem when using
TCP since the service will ignore packets when it hasn't done the TCP
handshake; but UDP services might respond to a single packet from the
middle of a websocket stream, so every single packet will have to be
careful not to be misinterpreted dangerously by unsuspecting
services).

-- 
Philip Taylor
excors at gmail.com