NAT Negotiation Change

I'm going to try to be a little computer-sciency here with a discussion.  First off I am making two assumptions here that could be completely false - so a dev could come in here and completely destroy my points.

Assumption #1: The NAT Negotiation server is getting bogged down and having a hard time processing all the requests in a reasonable amount of time.

Assumption #2: Every connection between two players goes through the NAT Negotiation server.


Ok with these two assumptions, heres the new scenario I would propose to decrease the load on the NAT server and help with its scalability with more players.  Here is the a description of what could happen.

1.  Player A hosts a game.

2.  Player B attempts to join the game.  Player B and Player A use the NAT Negotiation server to properly forward their UDP packets so they can form a peer to peer connect to eachother.

3.  Player C attempts to join the game.  Player C and Player A use the NAT Negotiation server to properly forward their UDP packets.. 

4.  Once connected, Player C uses Player A as a temporary NAT Negotiation server to connect to Player B.

5+.  All new players connect to Player A first through the NAT Negotiation server.  The connections to the other players happen through the host (Player A).

Conclusion:  This makes the requests to the NAT Negotiation server of order n (n=number of players) instead of n^2.  This would reduce traffic to the NAT servers by about 6 fold (if you assume a 3v3 is an average sized game).

Another possibility with this setup is to allows players to join the lobby once connected to Player A.  Then Player A can function as a simple chat server between players.  This could also allow Player A to boot the people who are failing to connect to other players.


Essentially, use a hybrid client-server for setting up the game, and switch to peer-to-peer when the game actually runs.


Anyway, I don't know if any of this information is useful at all, just an idea that came to mind, and the forums are public, free spaces, so I threw it out there to see if it's at all helpful.

 

6,971 views 9 replies
Reply #1 Top

I have pretty limited networking knowlegede, but based on what I've read on the forums, I don't think that the NAT negotiation server getting bogged down is the problem...I think the problem is that player connections to one another are being refused, either because the NAT traversal isn't working or because the socket connection is created incorrectly by the operating system.

This understanding has lead me to make my own uneducated guesses about solutions:

When I look at the connection information during games, I notice that when someone tries to join, he attempts a connection to everyone who is in the game, which is fine.  However, it also looks like he tries to connect to anyone else who is attempting to join, and sometimes even to people who have already left the game...I think that fixing this so that he only connects to people who are already in the game could help.

I had also thought that it would be interesting to allow players to join even if they can't connect to every other player, and asking a player who they can connect to to route their messages to the other players. The chain of players routing messages to one another could get out of control, but if we're just talking about one player routing messages to one target, then it wouldn't be too different from a client/server scenario where players send messages to a server and the server sends them to other players.

Like the first poster, I don't know whether these ideas are in any way correct or useful, but mentioning them can't hurt.

Reply #2 Top

It seems odd to me that the operating system is failing to create sockets.  That shouldn't be happening :)  Though I guess most of my experience is only with TCP socket communication.

On a side note - its pretty sad that we still depend on NAT when vIP6 could allow for some much better solutions. (Everyone gets an IP address! :) )

 

 

Reply #3 Top

Heres some information on the NAT negotiation that they use -- RakNet

http://www.jenkinssoftware.com/raknet/manual/natpunchthrough.html

I'd be curious to know how often these connects are failing the original connection of exchanging IP/Port addresses between two clients, and then moving onto phase 2 where they are just brute force guessing which ports to use to communicate.  It seems to me that most of the communications aren't happening that quickly, and this phase 2 is a majority of the cases.

Then theres the separate issue - where some routers constantly renumber the port that they are forwarding,  making your original address exchange null and void.  RakNet's solution is then to provide a UDP-Proxy server to move the data, but I would doubt Stardock is providing server resources to construct these proxies.  I could be wrong though!

That was a bunch of nerd speak, I know.  For some reason this stuff got me very interested.

 

 

Reply #4 Top

It also seems strange to me that the operating system would fail to create a socket...I was basing this claim on this post:

http://forums.demigodthegame.com/345345

Though I now noticed this post:

http://forums.demigodthegame.com/346451

which does mention server load as well.  Still, watching the connection info list, it looks to me as though players are able to find each other on Impulse well enough, it's just their connection to one another that is failing, and this really makes me think that it's a NAT traversal issue.

Reply #5 Top

Quoting Ceylin, reply 3
Heres some information on the NAT negotiation that they use -- RakNet

http://www.jenkinssoftware.com/raknet/manual/natpunchthrough.html

According to that link, the original attempt to connect the computers is:

"The server will find the external IP address of each client, and tell both clients to connect to that address at the same time."

Does that mean that the server is really just telling the clients to connect to each other at the same time?  That just sounds unreliable, doesn't it?

As for whether Stardock has the UDP Proxy servers, I'm not certain...I would guess that Stardock doesn't want to have proxy servers routing traffic from one player to another all the time, because wouldn't that be the same thing as using client/host instead of Peer-to-Peer?  But I also could be wrong.

Reply #6 Top

Here is some more information on how NAT punchthrough works with that initial connect.  I would assume that some amount of time is givein in that initial connect.  But I don't know.  I do agree with you that it seems like the connection between players takes a pretty large amount of time, or simply doesn't connect.  I do reliably connect to one of my friends all the time though - which I find interesting (he's in a different state too)

simple description

http://www.mindcontrol.org/~hplus/nat-punch.html

more in-depth

http://www.brynosaurus.com/pub/net/p2pnat/

But ya,  using a UDP proxy would be like setting up a small server to re-route information.

 

Reply #7 Top

It seems odd to me that the operating system is failing to create sockets.

As I understand it (not a dev) the issue is not so much at the OS level, but that some routers either reject the large number of socket attempts as an attack (strict security), or just panic/fail when faced with the simultaneous traffic (crappy hardware/firmware). Unfortunately you can't really tunnel past a router if it flips out at the mere sight of the traffic :p

Reply #9 Top

Quoting Werwie_011, reply 8
Did you try rerouting the subnet through friendster? 

Hmm, I should try sending Mr. Hankie an email and see if he knows how to do that.