[whatwg] WebSockets: UDP
emoller at opera.com
Wed Jun 2 23:28:41 PDT 2010
On Wed, 02 Jun 2010 19:48:05 +0200, Philip Taylor
<excors+whatwg at gmail.com> wrote:
I'm glad the discussion on this has taken off a bit. I've spoken to a few
more game devs and even though it's still relatively few there's a slight
majority that prefer the interface to be at the "Torque/RakNet-level"
rather than at the "UDP-socket-wrapper-level". I'm hoping I can talk a few
of them into joining the list and taking a more active part in the
> So they seem to suggest things like:
> - many games need a combination of reliable and unreliable-ordered and
> unreliable-unordered messages.
One thing to remember here is that browsers have other means for
communication as well. I'm not saying we shouldn't support reliable
messages over UDP, but just pointing out the option. I believe for example
World of Warcraft uses this strategy and sends reliable traffic over TCP
while movement and other real-time data goes over UDP.
> - many games need to send large messages (so the libraries do
> automatic fragmentation).
Again, this is probably because games have no other means of communication
than the NW-library. I'd think these large reliable messages would mostly
be files that need to be transferred asynchronously for which browsers
already have the tried and tested XMLHttpRequest.
> - many games need to efficiently send tiny messages (so the libraries
> do automatic aggregation).
This is probably true for many other use-cases than games, but at least in
my experience games typically use a bit-packer or range-coder to build the
complete packet that needs to be sent. But again, it's a matter of what
level you want to place the interface.
> 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
> - 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
I don't quite follow what you mean here. Can you expand on this with an
More information about the whatwg