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.
It's an interesting design and I wonder how well it works.
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.
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.
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.
There's a great article way back about X-Wing vs Tie Fighter and all the pain they went through with TCP/IP[1].
[1] https://www.gamasutra.com/view/feature/131781/the_internet_s...
It's a nice idea but UDP is really the right solution. Games like SubSpace were doing this back in '97 on 200-400ms connections in a seamless manner.