🔒 Locked

NATResolver worth it?

Started by Tubular Nov 28, 2004 at 4:51 AM 5 replies 1.4k views

Original Post

Nov 28, 2004 at 4:51 AM

Ok, I know this topic is close to the other NAT thread, but I didn't want to steal his answers from him. [smile] So here's the deal. When I originally wrote my internet support, I was using DX8. Strangely enough, the NATResolver8 interface and the other NAT compatibility suggestions are only in the DX9 documentation, so I didn't follow the guidelines there. [rolleyes] Instead I went from my own network knowledge which told me, "If a NAT is in the way, you won't be able to connect to a sever without port forwarding. And you can't set up forwarding without a static port. QED, I should have a static port for my internet games." My game is set up as a two-player-only Peer-to-Peer connection, which uses a web server on the open internet to snag the list of addresses of running hosts. The game port is static (12345) and specified in a host enumeration using the address listed on the server (ie, the public address), which I originally just used to obtain ping before allowing the player to choose where to connect. Basically, each game runs both a client and a host DP8Peer, and depending on whether you get invited or you invite someone else, the unused Peer is closed. Now that I've seen the DX9 docs, I see that this should work pretty well. I can see on my own computer that DP opens up the port for my game on the windows firewall, and since I'm enumerating every host on the list, on some NAT servers they should be able to connect to me through the port that opens. I enumerate using the public address, which the webserver gets from the HTTP requests to add the servers to the list, and according to the docs, any UPnP NAT servers should automatically set up port forwarding to the private address when the server launches. Now here's the deal. The game works on the open internet. If you run a server behind NAT and set up port forwarding manually, that works too. But it seems that in all other cases, you can not connect to, or even enumerate the server. In my own personal case, my machine is behind a NAT being run by my crappy ISP, so it's no surprise that no one can connect to me. But when I added internet support to the free demo and started seeing thousands of people online, only a small percentage of them could be enumerated. The rest have to sit around and wait for someone to come online who they can connect to, then it's a race to see who can hit "invite" first. Currently, I don't have a public server with root access to run a NATResolver on. The question is, if I did, would that even help? (It's a major pain to put out a new version for a small, one-line addition to the code to connect to a NATResolver.) Are so many people behind non-UPnP NAT servers, or is there something else going on? The docs make it sound like the NATResolver only helps with SOME NAT devices anyway. What should I do?

hplus0603

Nov 28, 2004 at 7:18 PM

Yup. That's the internet for you. The "SOME" NAT devices include most home firewalls (which are usually "cone" NAT), but doesn't include most corporate NATs (which are usually "4-way" NAT without port re-use, to cut down on Internet gaming).

The only way to get 100% coverage is to:

- make your game run over HTTP requests
- make sure those requests pass through a proxy unhindered
- run a central server which bounces data to other players

The second best is to do something like Battle.net, which is to use TCP on a single port, going to a central server which bounces data to other players.

If you can't have the central server bounce all data, using a static port, and using a central NAT resolver to introduce peers, using UDP. This will work better than just port forwarding, because port forwarding would still use, but people who can't port forward (say, two players behind the same NAT) will get the benefit of the introducer.

Tubular

Nov 29, 2004 at 12:35 AM

Ok, thanks for the response. Sounds like the answer is "it's probably worth it... maybe... sometimes." [disturbed] There's no question that I can't do a true central server which forwards all the data. The lowest prices I've seen online for a root-access server were in the $100 a month range, and at the current number of online players the bandwidth charges could be another couple hundred. I could make player servers that run on the open internet act as repeaters for other people's games, but I'm not sure the customers would like that idea. [wink] I guess I'll try to look for some other features to bundle with the upgrade along with connecting to a NATResolver, so I don't force everyone to waste their time downloading an upgrade that'll only work for 5-10% of people.

Now I just need to figure out where I'm going to run the NATResolver. [looksaround]

hplus0603

Nov 29, 2004 at 12:25 PM

If you're indie, you can always use the user base for support. Make the NAT resolver available for download, and have users run them. You provide a master list that your client gets using HTTP from a web site, every so often, and try all of them until you find one that works.

Or you can just say "port forwarding is it, folks." You can't please them all, and you shouldn't even try, unless you're Electronic Arts.

Tubular

Dec 3, 2004 at 11:12 AM

I'm surprised this thread is still near the top here! I guess this forum just gets fewer hits than the DirectX one which I usually follow. [wink]

Anyway, I was just thinking the two things you mentioned, and basically deciding that the likelyhood that someone would run a NATResolver for me was basically non-existant. (Casual games don't engender that kind of hard-core fan support, as far as I can tell.) So port forwarding will have to be it... Except[attention] Do I even need an honest-to-goodness DX NATResolver to get two IP's for most people?

I already have the public IP address for players online from the HTTP request to the player list... And a given client should know it's own private address, shouldn't it? Going from memory here, but it's something like:
Pseudocode:
GetLocalAddapterAddress(addr);
IP=addr->GetAddressComponent("ip");
So, I send the IP to the player list along with all the other player data (Name, game type, server speed, etc.) and now my player list can pass on both addresses to anyone who needs them, right?

Then the catch is I need to "multiplex" the two IPs into a single address object for use with DP8Peer->Connect() and DP8Peer->EnumHosts(). Right now I'm using the one IP I have and going (again with the pseudocode):
addr->SetAddressComponent("ip",IP);
So there ought to be something like this out there somewhere:
addr->SetAddressComponent("the_next_NATed_ip",IP2);

Granted, there is the occassional person connected to a server running Windows ICS, behind a frat-house router, behind a University server, behind an ISP firewall, but shouldn't this solve 90% of the problems that a NATResolver would solve? Maybe there's something I'm missing here. Or maybe that address "multiplexing" is either impossible, or will require the technical advice of an MS employee because it's undocumented... What do you think?

(PS. I can't host a Battlefield 1942 server on my home computer behind my ISP NAT. EA has failed me. [razz])

hplus0603

Dec 3, 2004 at 11:54 AM

Quote:
I already have the public IP address for players online from the HTTP request to the player list

But that uses a temporary, TCP-generated port number on the other end. When you go to connect, that port will not be valid anymore.

The Forum FAQ points at a resources page for NAT introduction, that explains what works, and what doesn't, and has several links to more in-depth information.

Tubular

Dec 4, 2004 at 8:51 AM

Ah, I see. Actually, it wouldn't be pointing to any port, because I set the port manually to the static game port before connecting. But it remains true that that only opens a temporary TCP port, as you say. And I wouldn't even be trying to connect to that. What a shame. I thought I had a solution...

Thanks for pointing that out before I wasted time implementing it!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.