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

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.

You can’t run google docs offline because what would that even mean? One of the main features of google docs is the live collaborative editing. It’s a multiplayer game that requires a host server.

You can architect your game to be friendly to being archived or you can make it completely impossible by introducing a dependency on the network. This is true for native games and web games.

If a game is fully available on the client side - it doesn't just need to run on the client side, but have everything available on the client side, data files and all - then yes you can archive it. But this is a very limited case and so far only the most simplistic games can be distributed like that. And TBH considering the DRM craze that games have, if anything i'd expect companies to try and make such archival as difficult as possible.

> You can’t run google docs offline because what would that even mean?

Having a word processor, spreadsheet, etc available offline.

> One of the main features of google docs is the live collaborative editing. It’s a multiplayer game that requires a host server.

It is a feature but i'd say that the main feature is being able to edit documents. In terms of games, it is a game with multiplayer features that still requires a host server for its singleplayer part (which is generally something that is frowned upon).

> You can architect your game to be friendly to being archived or you can make it completely impossible by introducing a dependency on the network.

You are talking from the point of view of the developer, i am talking from the point of view of the user. It should be obvious from when i wrote "How can you preserve a game that you have not full access to its files? Only the developer has that power and developers for the most part have shown over and over that they do not care about the games and applications they make after a couple of years or so". It is the user that suffers from such choices, not the developer.

Please try read my posts with the eyes of a user, with the concerns of a user's and try to avoid any developer bias.

> This is true for native games and web games.

Technically yes, but things aren't black and white - there are "natural" tendencies in each approach with the web approach leaning heavily towards network reliant applications and the native approach avoiding 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. 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.

[1]: futuretech.blinkenlights.nl/misc/cpumemory.pdf

> However I don't think you know enough about the domain to be able to sell it successfully.

Perhaps, and it is a small domain: The only people who think WebRTC is "too complicated" seem to be game developers.