litchralee

I'm jealous; we don't have the 454 in the USA, except as grey market imports. Good luck in this endeavor!

When I think of "offering a domain", I immediately think of DNS subdomain delegation. And on the linked page, you do say "DNS alteration encourage", which could suggest that subdomain delegation is what you had in mind.

But the rest of the text suggests more than subdomain delegation? How do you envision that self-hosted services might operate underneath the "top level" domain if not by delegation? Do you mean that an API would not create a delegation but would simply create a single record?

To be clear, a delegation of "xyz" under example.org would mean that some other DNS server is now authoritative for the entire *.xyz.example.org tree in DNS. That allows the delegate to create their own records for foobar.xyz.example.org or mail.xyz.example.org. Whereas if there was just a single AAAA record named "xyz" under the example.org domain, then the only name that will resolve is xyz.example.org; there is no additional authority to create subdomains under xyz.example.org.

In either case (a delegation or single records), you could certainly develop an API or some sort of Git repo as the source that is referenced by the top level domain's nameserver. This is quite similar to how DDNS providers work. And a while ago, someone on Mastodon (I think) used a custom nameserver to send football/soccer scores via DNS lookups. Or tunneling IP itself over DNS.

In the non-delegation case, some services might need more than one record created. For example, a simple web server at the xyz.example.org subdomain needs at least two fecords (A and AAAA) to support both Legacy IPv4 and modern IPv6 clients. If doing an email server, it would need at least an MX record, but modern DKIM and SPF might require additional TXT records and maybe SRV records.

For folks that are space constrained and would only use a trailer infrequently, folding utility trailers are available. Specifically, Harbor Freight in the USA sells one such 4x8 utility trailer for some $400. It weighs 250 lbs, though closer to 300 lbs (180 kg) after adding a 5/8" (10 mm) plywood deck; not included.

This makes it fairly reasonable to tow even with a small car, for light-but-bulky payloads (eg sectional sofa) a few times per year. Some US States like Oregon don't even require registration for such small trailers, while California has an extremely reasonable $25 plate fee that lasts 5 years.

To be abundantly clear, towing anything is a departure from run-of-the-mill driving, and carrying a load of any size presents hazards that require some attention and care. But it's entirely feasible and costs a lot less than a truck. The tradeoffs can be worth it, if it works with your use-case. It certainly does for mine.

Congrats! On the other hand, you will now be getting an influx of calls from friends whenever they're buying something from the home improvement store and it's too big to fit inside their car lol

In some cases, the game server's IP address is actually anycasted, which is an approach that (very carefully) breaks the notion that a network identity belongs to a single machine. Instead, that one IP address would actually be routed to a nearby machine which is authorized to assume the identity of the game server, and will thus handle the game traffic for that region. So long as all regions handle their traffic identically and the results are consistent as if there were one giant machine that were handling all the traffic, this can work. An example where the seams are visible are how YouTube's view counters will momentarily not match up across all geographies, because the backend servers don't sync up to each other instantly or even quickly; and few people require that precision anyway, so they just don't bother engineering it to do that. When you're providing a global service, that is exactly the sort of engineering tradeoff that must be considered, because even they do not have unlimited money.

In other situations, the game server IP address really is for a single machine, but that machine is a specialized hardware load-balancer that is situated in a cloud provider's network. All that this machine does is to be the frontend for the 5-tuple, and will create a new conversation/connection 5-tuple with a cluster of game servers within the cloud provider's network. There might be some superficial comparisons between a load-balancer and NAT, but the latter works by fraudulence whereas a load-balancer is a subcontractor.

The other commenters have provided many disparate answers that do reply to parts of your question, but allow me to approach the question holistically and thoroughly.

my basic understanding is that computer networking relies on constructs like IP addresses and port numbers to direct data packets to the correct device and application.

This is substantially correct. An IP address is a network identity of some "node" machine that participates on the network. A port number is a protocol-specific number for how to interact with a given node. For gaming, we are almost always talking about UDP as the protocol, so the port number will be a UDP port number; the same logic applies for TCP, but I'm going to gloss over that unless you specifically want details about this.

In the case of Legacy IPv4, an IP address is a 32-bit number that is usually presented as four decimal bytes separated by dots (eg 203.0.113.67). Or for modern IPv6, it will be a 128-bit number presented as hexadecimal groups of double bytes that are colon-separated, but where zeros can be abbreviated (eg 2001:db8::67). A TCP port number is any value between 1 and 65535 inclusive; 0 is technically usable but most software will not allow its use.

So, if I’m playing an online game like Minecraft or Counter-Strike, I am able to connect to the dedicated game server using the server’s IP address ... and port number

Correct. Your client aims at the server's IP address, and the UDP port number on that server. And on your end, you will have your own client IP address and client UDP port number. Implicit to the internet, we know that this must be using IP (v4 or v6 does not matter in this scenario) and the client and server only know how to speak UDP. Thus, there are five pieces of information which capture the entire connection: the source IP, source port number, destination IP, destination port number, and the protocol (UDP). In the networking parlance, we call this as the 5-tuple, because it captures the notion of a single conversation between two applications across the network.

Note that I'm specifically using the word "conversation" and not "connection" because the latter has a specific meaning in the business. A connection means that we're holding a resource open -- like a telephone line --for the entire duration that data is being exchanged. But UDP doesn't reserve resources like that, and is more like sending a post card and hoping for a reply.

The 5-tuple concept is important because like an IRL conversation, it's entirely possible to send data in the reverse direction, and while the source IP/port and destination IP/port will be reversed, it's easy to see that this is functionally the same "conversation", just in reverse. The network doesn't really care if the tables have turned: it just passes packets around. So I will simplify and say that if a 5-tuple reverses its source and destination values, then that's functionally no change at all.

I can now answer your question with technical precision: a game server can distinguish multiple game clients by using their unique 5-tuple. The rest of your question is answered by a brief explanation of various workarounds that are needed for the post-1995 Legacy IPv4 world, but which were fixed in the modern IPv6.

In some cases, each client will be connecting from their own network modem, with their own IP address assigned to them dynamically or statically by their ISP. In that case, I would imagine that the server could just keep a list of client connections and route relevant data back to each client.

This is exactly what existed pre-1995 when the end-to-end principle was alive-and-well on the public Legacy IPv4 Internet. As I mentioned before, an IP address is a network identity, and in the original conception of IP going back to ARPANet, an identity was not meant to be shared amongst multiple machines. Instead, every machine was expected to have its own IP address. However, during the 1995 explosion of dial-up users, network operators could not (or would) not) obtain new tranches of IP addresses to hand out to users, so they began using NAT as a workaround, to reduce their need for public IP addresses. But the keyword was "reduce" not "eliminate", and by 2012, the world had officially run out of available IP addresses to hand out to ISPs.

But in other cases, you might have a multiple clients playing a game behind one modem (like housemates or a LAN party where multiple players join the same remote/internet server), or a newer problem, multiple different networks sharing an IP address due to CG-NAT at the ISP level.

All of these workarounds (NAT/NPAT, CG-NAT, etc) all work by mutilating the 5-tuple and then unmutilating it for return traffic. When a home router performs NAT, it replaces the client's source IP (eg 192.168.3.42) with the router's (eg 203.0.113.67), and usually also replaces the client's UDP port (eg 12345) with a random one available on the router (eg 45467). The resulting 5-tuple is what the game server will receive. NAT must save the mapping (12345 -> 45467) for future reference.

When the game server wants to reply, it will -- exactly the same as the case with the end-to-end principle -- reverse the source/destination fields in the 5-tuple, and send the packet. This means the destination is now the home router's IP (203.0.113.670 and UDP port (45467). What NAT will now do is to again modify the source IP (to restore the original value of 192.168.3.42) and then use its stored mapping to restore the original UDP port number of 12345.

From the client's perspective, it receives a reversed 5-tuple of the one it sent to earlier. Thus, it's perfectly happy to receive that traffic and nobody is the wiser.

In which case, from the perspective of the server, multiple players would be playing from the same IP address and communicating over the same port, right?

Recall that NAT on the router will: 1) generate a random, new UDP port number, and 2) store the mapping of the originator's port number. So if there are two clients at home playing Minecraft, the router will have generated a different random UDP port number for each, meaning the 5-tuple that arrives to the game server will match 4 out of 5 parts, but not all five. The crucial -- and only -- distinction between these two clients at the same house are that they present a different source UDP port number to the server. And that is also how the game server will treat those two clients separately.

If the home router were to spontaneously reboot -- thus forgetting the NAT mapping table for UDP port numbers -- then both clients cannot recover the conversation at all, even after the home router is back online: the mappings are lost, and nothing can be done but to reconnect to the game server as a new 5-tuple. The end-to-end scenario does not have this problem, and pre-1995, routers did in-fact crash more often than they do now. Genuinely, today's Legacy IPv4 service is poorer than it was in the past, and certainly poorer than what modern IPv6 can deliver.

So how does the server differentiate between >2 players connecting from the same IP address and communicating over the same port?

As long as the home router has available UDP port numbers, NAT can continue to randomly generate a unique UDP port number for each client that is behind the NAT. Since UDP port numbers can be as large at 65535, that's a lot of clients. Though practically, no home router would ever see that many Minecraft clients. Even CG-NAT tends to only support approximately 64-128 clients on a single Legacy IPv4 address.

As for why, all this mutilation of packets takes a little bit longer than just passing the packet through the internet. It is not fun for the ISP to have to build CG-NAT infrastructure. It is not fun to build home router firmware that will get blamed for the user's bandwidth or firewall problems. Also, NAT would require a (relatively large) table in memory store lots of mappings, and so they just don't do that for consumer routers.

In the USA, AT&T's fibre internet modem/router is known to max out after a critical number of UDP conversations or TCP connections, because the NAT feature has run out of memory. This is precisely why some people bypass the modem/router (so they can use their own high-end router) or will use IPv6 for their connection-intensive workloads, like sharing Linux ISOs.

Or does it not even try, and instead just broadcast all of the relevant game data to every client?

Game servers definitely do not do this, because broadcast is not permitted on the public Internet whatsoever, whether on Legacy IPv4 or modern IPv6. The original conception of the internet did describe "multicast" which can target a group of IPs on a network, but this was never well-implemented for IPv4 and is only implemented on LANs for IPv6. The public internet does not support multicast, for a number of historical and bandwidth/security reasons.

If a game server wanted to send the same data to each client, one after another, it can. But it still must know the 5-tuple that identifies each client. Fortunately, the game server's OS will have taken care to record this info (eg BSD sockets).

And if that’s the case, how do huge games like battle royales or MMOs handle sending game state to a large number of users?

The way that MMOs deal with 100k+ clients goes deep into the realm of clustering, load-balancing, and network engineering. The only things that get more complex than that are high-bandwidth applications involving hundreds of thousands of clients (eg Netflix) or are massive hyper-scaler cloud providers (eg Azure, Alibaba).

That said, the fundamentals are still there: clients are identified by their 5-tuple, and all the engineering done to spread that load must still end up producing a reply that has the reversed 5-tuple.

(cont)

In case this is useful:

If you have a chopstick, you can tape the new string to the back and push the chopstick through the hole to guide the string. Other solid objects like a wire coat hook can work, but you have to make sure the tip won't snag.

This and the comment it replies to make the categorical error which is to assume that NAT exists as part-and-parcel to firewalling. This is not the case. Many American university and corporate networks do still adhere to the end-to-end principle by giving every device a public IP address. They can do this because they are among the few legacy entities that actually have enough for their needs, such as a Class A (aka /8) subnet on Legacy IP. At the same time, these entities employ firewalls that don't allow unsolicited inbound traffic (and sometimes also block disallowed outbound traffic).

NAT is not a firewall, and the OP correctly points out that by using NAT or CGNAT, the end to end principle is demolished, with no way for the victims to recover. OP mentions "firewalls" exactly twice, to compare how they are not firewalls and are still necessary in spite of NAT. Nobody is credibly suggesting that everyone should switch to IPv6 without a firewall. Every single domestic router for the past two decades has included a firewall, and that would not change in an all IPv6 world.

I wish to reiterate an example I've used in the past, which is that the most famous address in the USA is 1600 Pennsylvania Ave, Washington DC. Anyone can send letters and parcels directly to this address as-written, with no need to rewrite the address to first arrive at the Secret Service. And yet, all such parcels and letters will be thoroughly scrutinized by the Secret Service anyway at an off-site facility, and some indeed will be let through to the occupants of the residence. NAT is address mutilation, and the United States Postal Service does not require nor allow that.

I wish to be abundantly clear that I wasn't attacking your position, but that folks on the fence about "what makes a proper English word" should have some examples where English does the thing that makes the language fairly ~~incomprehensible~~ unique.

Not sure if this was intentional

I absolutely intended that and I'm glad you noticed! The doppelkupplungsgetriebe example is also a reference to an episode of Top Gear (UK). I meant to hyperlink both to their respective YouTube videos but entirely forgot.

Is this really a problem though? Compound words in English can be spaced, hyphenated, and sometimes even parenthesized. German has the word "doppelkupplungsgetriebe" which means "dual clutch gearbox" but whether the first pair is hyphenated or not, these three words in English together refer to a single object, a type of automobile transmission.

Separating the word into its parts is no different than splitting "hypoglycemia" (hypo meaning low, glyco meaning sugar, and -emia meaning presence in blood) into its parts: useful for understanding, but cannot substitute for the original compound word. The difference between the English and German word is a matter of spelling and punctuation.

Meanwhile, English has a genuine lack of a word for joy from the misfortune of others, that we borrow the word verbatim from English. The vacuum of a word meant we looked farther afield. And while that word was imported, I imagine there's a similar challenge finding an English word for "the warm feeling of sand between ones toes at the beach". The need for words is solved by usage, not by prescribing rules that prohibit importation.

I like the techwear vibe here. Well done!