> Zero technical reasons other than an ad hoc attack on game development practices.
These have been brought up ad nauseam so I didn't think it was useful to go over them.
The biggest reason UDPSocket doesn't just show up in browsers is that:
• Browser vendors don't want to accidentally make it easy to trivially D/DoS servers
• Browser vendors don't want to accidentally make it easy to trivially D/DoS clients
• It's not clear how to handle NAT traversal except when (interactively) trying to traverse NAT
But let's say we don't need anything more complicated than basic hole punching, P2P or cross-origin UDPSocket, and we can solve the trivial D/DoS issue with some kind of Allow-UDPSocket-From HTTP header, or OPTIONS or whatever. And maybe we have some kind of weird HTTP/2.0 transaction that does TURN/STUN automatically. Maybe.
Then we can have UDPSocket and you can implement netcode in JavaScript if you want!
However, WebRTC has already solved all those problems. Including the NAT one (that SDP/STUN/ICE stuff is there for a reason!). And obviously P2P, but also including some you probably haven't thought of, like issues around IP fragmentation (1200 byte packets!? DTLS fragments things itself for a reason!), and whether rolling custom crypto was a good idea.
> Unless you have a client library that can be paired to that server which takes up less than 200kb of mem you won't see adoption.
200k should be plenty: The dumb client can speak a slightly trimmed down WebRTC (e.g. limited to only a single codec) to keep the size down. My webserver which is just about as fast as they get, is only about 1kb of code on the hotpath.
But this doesn't answer my questions about a market: I don't sell to game developers, and I genuinely don't know if building a tiny+performant WebRTC client and server business is worth my time.
Is it?
How much will a game development studio pay to have this problem solved for them?
DDos is already handled cleanly by something like netcode.io using access tokens.
Anything more than the most trivial NAT traversal isn't needed since any online game worth their salt uses dedicated servers in order to prevent cheating and gamestate manipulation.
The fact that you're bringing up a 1200 byte packet limit shows that you have no understanding of the domain space. Most networking stacks keep the packet size well under 200 bytes since they don't want to saturate the connection and dead-reckoning deals with state reconciliation.
Binary size also matters, so the fact that you want to bring in a whole codec when it may not be wanted isn't a great selling point either.
I'm sure there's a market out there given how RAD Tools and other middleware companies do just fine. However I don't think you know enough about the domain to be able to sell it successfully.
> DDos is already handled cleanly by something like netcode.io using access tokens.
I can set up a netcode.io server and cause it to list any IP addresses I want as "server addresses", then cause a netcode.io client accept that challenge token and permit traffic to that address. If netcode.io is widespread (i.e. in browsers) I can buy some advertising to knock out any client or server I want.
Unless you are in advertising, you might not be aware I can do that: I can purchase something like a million clients for something like $10. Knowing how certain formats work make it possible to purchase more traffic for even cheaper.
These attacks are well known to Google and the WebRTC designers and as such, is not possible with WebRTC: The browser does not permit traffic at volume until ICE/SDP negotiation is complete which means that signalling must have occurred.
By simply limiting the netcode.io clients size to the games that use it (i.e. games distributed with one of the non-browser implementations of netcode.io), this attack is mitigated substantially, but as soon as we try to use netcode.io as a "simpler webRTC" it falls flat on it's face.
Splat.
Perhaps we are lucky that the window.netcode browser extension isn't more popular, or that all those users have ad blockers.
Anyway. The workaround I suggested would probably be sufficient to stop this attack as stated, but it requires a netcode 1.1 or maybe a 2.0 since all clients and servers need to be upgraded. And there might also be other attacks.
> Anything more than the most trivial NAT traversal isn't needed since any online game worth their salt uses dedicated servers in order to prevent cheating and gamestate manipulation.
What Cisco calls Dynamic NAT doesn't work with this scheme. It is popular. Perhaps these people don't play games because game servers don't support their network configuration, or perhaps these people don't play games for another reason.
Non-game uses of UDP are very interested in talking to these networks however. It will be difficult to get buy-in from other parties interested in UDP unless you solve these problems.
> Most networking stacks keep the packet size well under 200 bytes since they don't want to saturate the connection and dead-reckoning deals with state reconciliation.
IP packets fragment once they go above a certain size. That size can only be discovered by experimentation, but will never be smaller than 576 bytes. Many networks block the standard discovery process (called Path-MTU discovery) for misguided reasons, but protocol developers still have to deal with it.
If your UDP packets are bigger than this size, and everything else is working, then losing either fragment will delay the receipt of the datagram and waste kernel memory. Developers who can do their own fragmentation smarter use setsockopt+IP_DONTFRAG and save everyone a potential denial of service opportunity.
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.
> Binary size also matters, so the fact that you want to bring in a whole codec when it may not be wanted isn't a great selling point either.
That statement might have been over your head. Sorry about that.
1kb of code "on the hot path" is a shorthand way of describing the code that is executing in L1 and refers absolutely to binary size. My i7 only has 64kb of L1, and anything larger than that requires memory fetch and waits. Keeping the hot path within L1 is a good way to get 1000x speedups (and is a big part of why my code tends to be so fast).
Ulrich Drepper's "what every programmer should know about memory"[1] might be good introductory material for some of these concepts, and I highly recommend you read it.
> I can set up a netcode.io server and cause it to list any IP addresses I want as "server addresses", then cause a netcode.io client accept that challenge token and permit traffic to that address.
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.
> 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.
These have been brought up ad nauseam so I didn't think it was useful to go over them.
The biggest reason UDPSocket doesn't just show up in browsers is that:
• Browser vendors don't want to accidentally make it easy to trivially D/DoS servers
• Browser vendors don't want to accidentally make it easy to trivially D/DoS clients
• It's not clear how to handle NAT traversal except when (interactively) trying to traverse NAT
But let's say we don't need anything more complicated than basic hole punching, P2P or cross-origin UDPSocket, and we can solve the trivial D/DoS issue with some kind of Allow-UDPSocket-From HTTP header, or OPTIONS or whatever. And maybe we have some kind of weird HTTP/2.0 transaction that does TURN/STUN automatically. Maybe.
Then we can have UDPSocket and you can implement netcode in JavaScript if you want!
However, WebRTC has already solved all those problems. Including the NAT one (that SDP/STUN/ICE stuff is there for a reason!). And obviously P2P, but also including some you probably haven't thought of, like issues around IP fragmentation (1200 byte packets!? DTLS fragments things itself for a reason!), and whether rolling custom crypto was a good idea.
> Unless you have a client library that can be paired to that server which takes up less than 200kb of mem you won't see adoption.
200k should be plenty: The dumb client can speak a slightly trimmed down WebRTC (e.g. limited to only a single codec) to keep the size down. My webserver which is just about as fast as they get, is only about 1kb of code on the hotpath.
But this doesn't answer my questions about a market: I don't sell to game developers, and I genuinely don't know if building a tiny+performant WebRTC client and server business is worth my time.
Is it?
How much will a game development studio pay to have this problem solved for them?