Using Arranged Connections to punch through firewalls and router
by Affectworks · in Torque Game Engine · 12/27/2006 (4:37 pm) · 28 replies
Cool Title huh? I guess I should explain it first.
It has been a nuisance to me to always have to depend on my end users to have the knowledge of how to forward their router ports in order to host a game (and don't many if not most people have routers now days?). Then it came to my attention, about a month ago, that GG has had the technology to 'punch' through routers for years now in the form of the Torque Network Library (TNL). TNL is GPL and can be found here http://www.opentnl.org For all who don't know, here is how the Arrangement of Connections essentially works in TNL.
Quite ingenious and extremely useful with today's standard home network. This connection arrangement feature should probably be standard in all the Torque Engines, but since it is not, I am attempting to integrate it. It is not necessary to integrate all of TNL for this feature, therefore I am just working with implementing 'Punch' PacketTypes and all else that is along that same vein. This will also require a custom master server that I haven't even had an opportunity to touch yet.
So, here is the point of this thread, I am reaching out to the community in hope of helpful hints, thoughts, code snippets you may have written earlier and maybe even a periodic 'a-ta-boy! It is a goal of mine to turn this thread into a spectacular community created resource that will benefit everyone.
It has been a nuisance to me to always have to depend on my end users to have the knowledge of how to forward their router ports in order to host a game (and don't many if not most people have routers now days?). Then it came to my attention, about a month ago, that GG has had the technology to 'punch' through routers for years now in the form of the Torque Network Library (TNL). TNL is GPL and can be found here http://www.opentnl.org For all who don't know, here is how the Arrangement of Connections essentially works in TNL.
Quote:- The server sends cyclic messages to the master, so the firewall is open for the master.
- The client sends a request to the master, and receives the server IP list
- The client sends a message to the master, for inform it that it wants to contact the server
- the master sends a message to the server with client's IP
- the server contacts the client, just to open firewall (with n retry)
- the client contacts the server to entering the game (with n retry)
Quite ingenious and extremely useful with today's standard home network. This connection arrangement feature should probably be standard in all the Torque Engines, but since it is not, I am attempting to integrate it. It is not necessary to integrate all of TNL for this feature, therefore I am just working with implementing 'Punch' PacketTypes and all else that is along that same vein. This will also require a custom master server that I haven't even had an opportunity to touch yet.
So, here is the point of this thread, I am reaching out to the community in hope of helpful hints, thoughts, code snippets you may have written earlier and maybe even a periodic 'a-ta-boy! It is a goal of mine to turn this thread into a spectacular community created resource that will benefit everyone.
#22
02/02/2007 (9:57 am)
Ok, I have a question. I am reading the TNL master server code. I am looking at how the Host machine knows what 'PossibleAddresses' to check. To me it looks like (pasted code below) it just makes educated guesses at possible ports to try. It appears to take the address it is connected to and then port++ and port--. Is that really all the possible ports it checks? I'm sure that can't be it... I mean my testing shows that my client likes to send through port 1046 mostly and that is no where close to the connection NetAddress port of 28000 +/- 1.// Get our address...
Address theAddress = conn->getNetAddress();
// Record some different addresses to try...
Vector<IPAddress> possibleAddresses;
// The address, but port+1
theAddress.port++;
possibleAddresses.push_back(theAddress.toIPAddress());
// The address, with the original port
theAddress.port--;
possibleAddresses.push_back(theAddress.toIPAddress());
#23
02/02/2007 (11:48 am)
That code looks to be taking the current net address the connection is using, and send both it and the port one higher as possible connection targets... are you sure it's not using the port that sends are originating from? 
#24
NAT Problems - And a Big Opportunity For Online Multiplayer Games
08/14/2007 (1:10 am)
I'm not sure it's 100% relevant to this post but there is a similar discussion on gameproducer.net website:NAT Problems - And a Big Opportunity For Online Multiplayer Games
#25
Certainly wouldn't hurt Torque's sales either. ;)
08/14/2007 (9:12 pm)
I am just curious to see if you had gotten any further with this? Considering it is an issue that plagues many games out there, it would be really nice to see Torque having a solution.Certainly wouldn't hurt Torque's sales either. ;)
#26
08/15/2007 (5:53 am)
Can someone explain in layman's terms what this resource, if finished, would do? People are saying it's a great benefit to multiplayer games, but what is the benefit?
#27
What is being proposed here is a method of NAT traversal which will allow a 'hole' to be punched in the firewall to seamlessly allow incoming connections. The game hoster does not have to change any firewall configurations, so this removes a big barrier to hosting servers == good for the game.
08/15/2007 (8:56 am)
@Daniel: If you are hosting a game server behind a firewall, people outside that firewall cannot connect unless you can tell the firewall to let connections through and to translate the address to the internal machine [NAT].What is being proposed here is a method of NAT traversal which will allow a 'hole' to be punched in the firewall to seamlessly allow incoming connections. The game hoster does not have to change any firewall configurations, so this removes a big barrier to hosting servers == good for the game.
#28
08/16/2007 (10:50 am)
Thanks very much for the info! Yeah, now I see how that could help.
Torque 3D Owner Affectworks
... yeah. Like I said. 2+3=6, right? No? Oh, well. I'll go draw something instead.
Fredrik S