> 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

> 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. 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_from_a_browser/ https://gafferongames.com/post/why_cant_i_send_udp_packets_f...