Re: NAT Negotiation

This is what everybody does pretty much. The link I included in my previous reply is a good rxplanation of the issues invoilved ( http://www.mindcontrol.org/~hplus/nat-punch.html )

I believe some NATs will increment port numbers and that would be a good guess to try, but I also read that they may assign random port numbers. Seems pretty hard to establish a connection to a NAT device randomly generating port numbers. Hmmm...

----- Original Message ----- 
From: "Magnus Auvinen" <[email protected]>
To: <[email protected]>
Sent: Monday, January 12, 2004 7:49 PM
Subject: RE: [GD-General] NAT Negotiation


> If I've understand this correctly you have two clients (named C1 and C2)
> behind NAT connected to a server (named S) and you want to establish a
> connection between the two clients without reconfiguring the NAT server.
> I've thought about this problem and I've come up with a solution that may
> work.
> 
> 1. C1 decides that it want to establish a connection between itself and C2
> so it send that request to S. 2. S starts listening to two new ports and
> sends one of the numbers to C1 and the other C2. 3. C1 and C2 respond to
> this packet. 4. S now have the current port numbers of the two clients NAT.
> Assuming that the NAT will give the next "connection" a port one step higher
> then this it sends out C2 port number+1 to C1 and vice versa. 5. C1 and C2
> starts sending each other packets (about 3-5 with 100ms delay should be
> enough) on the assigned ports from the server until they get a response.
> 
> Now the C1 and C2 can communicate with each other. I don't know if this
> works because of the assumption at point 4. You could perhaps use some other
> algorithm to predict what port will be the next one (don't have PP installed
> so I can't look at the .ppt file). Another problem is if the NAT is under a
> lot of pressure a lot of new entries will be made in the dynamic routing
> table so the assumption fails, but the procedure can be repeated until
> success. Also, if the NAT is smart it can refuse to use a port that has data
> that has been transmitted to it recently. This means that at point 5 the
> client must send the packets at the same time within one half of a RTT. A
> lot of problems but this are the only way I found to solve the problem.
>  
> Please try it if you want. I don't know if it works. Perhaps there are
> better ways to solve it.
> 
> :)
> 
> .magnus auvinen
> 
> -----Original Message-----
> From: Brett Bibby [mailto:[email protected]] 
> Sent: den 12 januari 2004 09:18
> To: [email protected]
> Subject: [GD-General] NAT Negotiation
> 
> 
> 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=3667950
> 
> 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 
> 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 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 
> to be flippant or derogatory, but only to point out that A.) it's a 
> 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 
> in _theory_ (but rarely in practice, at least in the past 5 years or 
> so), the reverse port mapping can change on a per packet basis.  This 
> is described in a bit more detail in my article on multiplayer 
> 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 
> other _without opening up any ports_.  At least, that's my 
> understanding.  This avoids the entire "explaining to users how NAT 
> 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 
> that you can tell users what ports to open/forward) but you should 
> 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. 
> 
> No, you'll receive the other person's _public_ address and port 
> mapping (ideally) that allows you to communicate with them directly.  
> At least, that's what I'm assuming they're trying to do.  If you 
> received 192.168.1.100, well, that's not too helpful since it'll just 
> route to your own internal network (on a router that uses that 
> mapping).
> 
> Brian
> 
> **End Brian Hook's Reply**
> **Begin Second Post**
> 
> > This is precariously on the border of being OT and should probably be 
> > 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 
> > other _without opening up any ports_.  At least, that's my 
> > understanding.  This avoids the entire "explaining to users how NAT 
> > 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?
> 
> > 
> > > 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.
> > 
> 
> 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?
>  
> > > 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. 
> > 
> > No, you'll receive the other person's _public_ address and port 
> > mapping (ideally) that allows you to communicate with them directly.  
> > At least, that's what I'm assuming they're trying to do.  If you 
> > received 192.168.1.100, well, that's not too helpful since it'll just 
> > route to your own internal network (on a router that uses that 
> > mapping).
> > 
> 
> 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**
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Gamedevlists-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Gamedevlists-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7