I'm pretty sure websocket is fifo with delivery guarantees and as far as I'm aware cannot be used in the same manner as UDP. I haven't played around with WebRTC, but that might be an option.
Airmash uses two websockets and accepts updates from whichever arrives first. It's still fifo, but if one experiences fragmentation the other might be fine.
It's an interesting design and I wonder how well it works.
Wow that multiple TCP connection trick is very interesting. Each additional idle connection would theoretically be capable of firing off a single packet instantly with no congestion control getting in the way. I'm getting flashbacks of services that would allow multiple pending HTTP long-polling requests at once, so the server could push faster than the round trip time.
I wonder what the ideal number of connections would be. It could certainly be 2 of course; I've never thought about this problem before.
Valve mentioned that in practice packets are dropped about 5% of the time, so two connections might theoretically reduce that to 5%^2, or 0.25%. Meaning out of every 1,000 seconds of playtime, only 2 seconds would be disrupted rather than 50s.
It seems unlikely to be as clear-cut as this, since two connections from the same host to the same endpoint will probably use the same route to get there. So why would using two connections avoid retransmission? But it's worth checking whether it works.
It can be worse than that since TCP/IP will do exp backoff depending on your packet loss. Which is awesome for file transfers but pretty awful for real-time data.
There's a great article way back about X-Wing vs Tie Fighter and all the pain they went through with TCP/IP[1].
I don't. The only reason I heard about it was because I happened to be playing when the dev hopped on and started messing with people. Someone asked him about architecture and they said they use two websockets to prevent congestion.
I'm skeptical about the design, but the only way to know whether it's effective is to measure it.
Carmack's great breakthroughs came from trying every logical possibility and then sticking with the ones that worked. There were dozens of dead Quake designs that no one knows about, e.g. beam trees.
One mistake I made in the early days was to go around asking people what to do or how to design something. The truth is, no one really knows the best way to design anything. The only thing you can do is think of possibilities, try them, and ruthlessly measure whether they're effective. Often the most effective designs come from unexpected combinations, which is why this dual websocket idea is worth taking seriously.
One nice property is that if it does work, it only costs 2x bandwidth. Realtime games' bandwidth grows as O(n^2) with the number of players (e.g. 90 players need updates about all 89 other players plus themselves). So doubling the bandwidth isn't a huge cost.
