[GD-General] NAT Negotiation
Brought to you by:
vexxed72
|
From: Brett B. <res...@ga...> - 2004-01-12 08:16:32
|
This thread is being transferred form the GD-Algorithms list as Brian = pointed out it may be OT for the algorithms list. I apologize if this = attempt to transfer doesn't go well :-) **Original Post** Yet another network post <sigh>... I searched the archives for NAT and came up with 14 posts. Some say NAT = is a problem, others say it's no problem especially when using a third = server connected directly to the internet. Google results in a number of = old pages, many with outdated links. My problem is that I need to come = up with some sort of internal NAT solution (if it's really needed?) = because we need to support multiple platforms, and I cannot find any = third party solution (including Gamespy or open source) that covers all = the platforms or compilable for them. Let's say I have two machines, both behind NATs. They both think their = address is 192.168.1.100, but to the outside world it's 123.123.123.123 = and 124.124.124.124 (whatever). The only way for these two machines to = ever find each other is through some third party, and they are at = 125.125.125.125. They each get their address locally (192.168.1.100) and send that to the = server in a packet it can understand. The server reads the packet and = also notes the ip address of the received packet, so now the server has = both the public and private address of a given client. It then sends = each of the clients the other's address(es) and they try to contact each = other. Is this correct so far? Does it work because the NAT assigned different = internal port numbers to the outgoing requests so it uses that to route = the incoming packets back to the requestor? If so, this seems = deceptively simple. Why does Gamespy mention they have to do other = things too? http://www.igda.org/oc/IGDAGamespyNAT.ppt In a slide near the end they say they do some port guessing based upon = common patterns. Why would they need this if a third party server is = used? Also, Brian Hook mentions in one of his posts in the archive about using = the lower 16 bits of the ip address as a unique identifier. Why would I = need to do this? http://sourceforge.net/mailarchive/message.php?msg_id=3D3667950 There is also a mention that you shouldn't hard code port numbers. Is = there a recommended way to generate one? Finally, what if I am playing a game where two of us are behind a NAT on = a LAN but connected to the same game on the internet. It's likely that I = would recieve an address from the server of some other player's private = address that would coincide with the address of my friend. When I = contact them at that address they reply and I get the wrong connection. = Is this what Brian was using the low 16 bits as an identifier for in = order to distinguish between people using the same private address = accidentally contacting another machine on their LAN? Thanks Brett ** End Original Post ** ** Reply by Brian Hook** This is precariously on the border of being OT and should probably be=20 handled on gd-general, but I don't think it's flagrant (but it's Tom's=20 list, so if he disagrees, we can take it to gd-general) > I searched the archives for NAT and came up with 14 posts. Some say > NAT is a problem, others say it's no problem especially when using NAT is not a problem if you know what you're doing. That's not meant=20 to be flippant or derogatory, but only to point out that A.) it's a=20 hairy problem to the uninitiated and B.) it's a solvable problem. > They each get their address locally (192.168.1.100) and send that > to the server in a packet it can understand. The server reads the > packet and also notes the ip address of the received packet, so now > the server has both the public and private address of a given > client. It then sends each of the clients the other's address(es) > and they try to contact each other. Sounds about right. > Is this correct so far? Does it work because the NAT assigned > different internal port numbers to the outgoing requests so it uses > that to route the incoming packets back to the requestor? Yes, but you can't rely on this. UDP is a connectionless protocol, so=20 in _theory_ (but rarely in practice, at least in the past 5 years or=20 so), the reverse port mapping can change on a per packet basis. This=20 is described in a bit more detail in my article on multiplayer=20 programming you can find at bookofhook.com > In a slide near the end they say they do some port guessing based > upon common patterns. Why would they need this if a third party > server is used? What they're trying to do is allow two players to connect to each=20 other _without opening up any ports_. At least, that's my=20 understanding. This avoids the entire "explaining to users how NAT=20 works and why they can't host a server" problem. > Also, Brian Hook mentions in one of his posts in the archive about > using the lower 16 bits of the ip address as a unique identifier. > Why would I need to do this? To resolve clients behind a NAT. > There is also a mention that you shouldn't hard code port numbers. > Is there a recommended way to generate one? Which port numbers? For your server, you should hardcode them (so=20 that you can tell users what ports to open/forward) but you should=20 also allow them to be relocated in case there's a conflict. > Finally, what if I am playing a game where two of us are behind a > NAT on a LAN but connected to the same game on the internet. It's > likely that I would recieve an address from the server of some > other player's private address that would coincide with the address > of my friend.=20 No, you'll receive the other person's _public_ address and port=20 mapping (ideally) that allows you to communicate with them directly. =20 At least, that's what I'm assuming they're trying to do. If you=20 received 192.168.1.100, well, that's not too helpful since it'll just=20 route to your own internal network (on a router that uses that=20 mapping). Brian **End Brian Hook's Reply** **Begin Second Post** > This is precariously on the border of being OT and should probably be=20 > handled on gd-general, but I don't think it's flagrant (but it's Tom's = > list, so if he disagrees, we can take it to gd-general) I posted it here since there was discussion before on this list with no = mention of OT at that time. Let me know if you want it moved to = GD-General and I will do so immediately. > What they're trying to do is allow two players to connect to each=20 > other _without opening up any ports_. At least, that's my=20 > understanding. This avoids the entire "explaining to users how NAT=20 > works and why they can't host a server" problem. Couldn't they host a server as long as the third party matchmaking = server game out thier public ip? Or is the rarely changing port number = the problem here too? There isn't much difference between a client and a = server once the third party matchmaking knows the correct ip and port = number is there? >=20 > > Also, Brian Hook mentions in one of his posts in the archive about > > using the lower 16 bits of the ip address as a unique identifier. > > Why would I need to do this? >=20 > To resolve clients behind a NAT. >=20 So this number would be used to identify players internally rather than = ip/port, and when I want to send the packet I lookup the ip/port based = upon this? =20 > > Finally, what if I am playing a game where two of us are behind a > > NAT on a LAN but connected to the same game on the internet. It's > > likely that I would recieve an address from the server of some > > other player's private address that would coincide with the address > > of my friend.=20 >=20 > No, you'll receive the other person's _public_ address and port=20 > mapping (ideally) that allows you to communicate with them directly. =20 > At least, that's what I'm assuming they're trying to do. If you=20 > received 192.168.1.100, well, that's not too helpful since it'll just=20 > route to your own internal network (on a router that uses that=20 > mapping). >=20 Is this correct? So if I'm behind the same NAT as my friend, will the = router detect the outgoing public ip address and port and reroute it = back inside directly to them? Brett ** End Second Post** |