Clang runs in the browser and compiles C++ to WebAssembly

No you can't since netcode.io authenticates packets with a public/private key pair and a sequence id. If either the sequence id has been seen recently or key sig fails it won't accept the connection.

Netcode.io was built by someone who dealt with millions of clients and shipped many high volume games so this isn't anything new.

> If all you want to do is avoid head-of-line blocking on the player's network connection, then multiplexing several TCP connections (even websockets!) will provide the same latency and throughput guarantees that UDP will, getting correct NAT behaviour and resistance to D/DoS for free. Simply drop and reconnect any link on packet loss (trivial to detect on either side), and you only need enough connections to handle the maximum number of dropped packets you can tolerate within the time it takes to reconnect.

> I've seen at least one game on HN use this trick in the last year, so I know it isn't unknown.

Nope, nope and nope.

For one, packet drops tend to happen in bursts so your multiplexed TCP/IP clients just means you're resilient to N+1 drops. Detecting a packet drop is not trivial and you need to go through a whole syn/syn-ack/ack if you recreate. Dropped TCP/IP sockets also don't clean up immediately so you can easily exhaust your available socket resources with this technique.

I played the game that you mentioned and if you seen in the comments the netcode was not ideal. It was pretty obvious that there was some head-of-line blocking even with multiple sockets. Compare that to something like Subspace that ran on a single 250-400ms 56K connection seamlessly back in '99.

Look, I'm sure you're an expert in WebRTC but you don't understand the technical requirements for a realtime netcode. Rather than trying to tell us how we're 'wrong' try listening instead. Games have a pretty unique set of requirements which is exactly why you haven't seen off the shelf solutions like WebRTC gain any traction.

How exactly do you think netcode.io knows that I own (or don't own) 151.101.193.67?

What exactly do you think prevents me from modifying my own netcode.io server at 151.196.182.212 from listing that IP address as one of the game servers?

It's a legitimate connection as far as the client is concerned, and that's what I have a few billion of.

Why do you think the public/private key or sequence ID has anything to do with this? Why do you think for a denial of service attack I care if the "server" 151.101.193.67 accepts the "connection" or not?

> Netcode.io was built by someone who dealt with millions of clients and shipped many high volume games so this isn't anything new.

If it helps you, I've built software with an install-base over a billion, in a place where high latency and bugs don't just mean a dissatisfied customer, but loss of real money.

However talking credentials at this point doesn't help me. It is probably best you respond specifically to what you think is wrong with my thinking instead of bringing up how smart you think your friends are.

> packet drops tend to happen in bursts so your multiplexed TCP/IP clients just means you're resilient to N+1 drops.

If you want to send datagrams at 20hz, and your RTT is 200ms, then 10 connections is equivalent in throughput and latency to UDP: Simply send datagrams down the channel. One side detect a stall? Tear down the channel and move to the next one. Even if you lose 10 packets in a row, the 50msec timer tick means you still recover at least one channel before the 200msec mark.

It's the same as UDP because it's the same number of packets. You can convince yourself of this with tcpdump, and subtract the TCP connect/teardown packets (which aren't blocking anything).

> Look, I'm sure you're an expert in WebRTC but you don't understand the technical requirements for a realtime netcode.

Accepted, at least for these discussions.

One of the principal authors of netcode[1] says that he doesn't understand WebRTC. He says it's too complex.

I have given several examples of things it does better than the published version of netcode if it were immediately adopted by browser vendors, and unless those specific things are addressed, you are going to have a hard time convincing Google and Mozilla to include netcode.io JavaScript bindings.

I appreciate you don't think network address translation is important, and I realise you don't understand the denial of service attack vector I'm describing yet. I think these things are important because I am experienced with their impact, and I know how WebRTC protects users from these things.

You can put your energy into understanding this attack vector, and what others might lay around also hidden from view, or your can put your energy into solving the problems that might make WebRTC a poor fit for game developers. In either case, you probably need to learn WebRTC.

[1]: https://gafferongames.com/post/why_cant_i_send_udp_packets_f...

Webassembly solves a problem that existing low level bytecodes like LLVM IR do not intend to solve. LLVM IR is not stable across LLVM versions and usually is optimized for a specific architecture.

JVM bytecode is stable but high level. LLVM IR is unstable and low level. WebAssembly is stable and low level.

They all solve different problems.