Hacker News Reader

Comment by drewblaisdell | Hacker News Reader

Quite literally. One of the most obvious applications of this is creating asynchronous multiplayer browser games.

Oh boy. Pretty soon we will need UDP sockets in the browser.

You can already do peer-to-peer UDP communication in a browser with Flash RTMFP protocol. If I remember right it was shipped with Flash 10, which got released 4 years ago.

WS is already kind of fire-and-forget. Socket.IO supports that, and can handle thousands of messages/second, I don't think that will be needed.

Except, it's implemented on top of TCP. So you still have the head-of-line blocking problem. In a real-time application like games, if some congestion causes a few packets to be dropped, you don't care about them any more (assuming your protocol gives absolute positions of everyone involved); but in TCP, they will be retransmitted, and later packets queued until it can catch up. As websockets are based on TCP, you can't avoid this. Even if you have a "fire and forget" message based layer built on top of TCP, the head-of-line blocking will still kill your performance, causing people with bad connections to get persistent lag rather than a few dropped frames.

That's true, but in practice networked games built on websockets are doing fine right now, and will until browsers get stable capabilities for more intensive 3D gaming (likely in around 2 years time). I guess I meant they won't be needed yet.

Well, I'm working on a web-based real-time multi-player game, and I'd say that UDP would be very welcome by me. When I'm on a good connection, TCP is fine and things work perfectly. But as soon as my connection becomes just a tiny bit unreliable and packets start dropping, it becomes completely unplayable, as TCP has to retransmit those dropped packets before any new packets are processed.

Since all we get is TCP right now though, you can take advantage of that at least and easily do things like send deltas instead of absolute positions, and even things that depend on reliable order of transmission (which you can't rely on if it were UDP), in order to reduce bandwidth use.

I don't understand why they didn't just provide an api to normal IP layer sockets, it would have given a lot more flexibility. I'm thinking the sort of lower level networking access you get in node.js

If people really wanted to send data over this weird semi-HTTP websocket protocol then someone could have implemented it as a js library on top of proper socket calls.

I'm guessing the main issue was cross-domain security, but I would have liked to see this solved using some sort of policy file that can be requested from the domain before connecting, like Flash does.

Reply on news.ycombinator.com