UPnP/NAT Punchthrough

I have recently been working with UNET, and started work on a project using it. The game is a P2P, with one client as the server, or a host. The problem is that to get this to work, the host needs to port forward, which would deminish the players able to play by a lot.

I then went to forward my port for testing, then noticed Skype has ports forwarded automatically, and stumbled upon the feature of UPnP, and researched, and figured out it's pretty much what I need. Problem is, there's no implementation for it in Unity. I tried looking around for some C# implementations to use in my project, but I couldn't get them to work, probably because of my inferior knowledge to how C# works. Are there going to be any UPnP implementation?

I also looked up NAT Punchthrough (Or UDP Hole-punching), and figured that might be a good alternative, but less reliable. I already have a MasterServer set up that holds the hosts, and was wondering if the punchthrough would work with the message system in UNET? Or maybe a NAT Punchthrough implementation is coming, like with the old RakNet?


TL;DR:
Is there going to be UPnP implementations? (Or are there any out there?)
Is there going to be NAT-punchthrough implementations?
If not, is it possible to make my own with the Message system? (I already have a MasterServer)

 

In Unity Multiplayer the Matchmaker and Relay server are the solution to enable internet play. We're evaluating adding NAT punch through in the future but have no specifics to announce at this time.

 

I'm aware of the MatchMaker and relay server. I decided to go without it, exactly because of the relay and pro requirements.

 

PLEASE include NAT punchtrough for UNET. Without it is useless. I upgraded my game to use UNET and I have a latency of 500ms playing with people in my LAN ... Turns out UNET sends the Data from New Zealand to the US and back ... For any kind of real time scenario the relay server won't do it.

 

NAT punchthrough doesn't have anything to do with LAN. It's only when you connect to people outside the game. Just connect to the local IP instead of using the MatchMaker or whatever relay you're using.

 

Sorry I didn't express myself clearly enough. A proper library that can connect people through NAT usually is able to recognize if this isn't needed in the first place. The LAN example was just to show how useless the new system is. If I play with someone else in New Zealand it will still relay all the data to the US simply to get around the NAT ... And even if they have a server in New Zealand it will still cause a massive drop in latency for no benefits (except for Unity as you will need to pay for a not actually needed relay system).

The point is I don't know if the connection users are in one LAN or not. And too be honest I don't want to care. That is the reason to use a match maker in the first place!

The point of a matchmaking system is to connect player for me. They make a match and other people join. RaKnet and the old network handled that just fine. It will connect them locally if possible and uses NAT punch through if needed. On the other hand UNET is simply unusable so far. I am back to the old unity network again :/

 

There is MonoNAT (which I already use for my game), a C# library in its heart, but the implementation isn't that hard. It isn't the fastest, and it certainly "does everything for you". But it works, and once you have implemented it, you don't need to care any more. OpenNAT would be better, but it is a fork rewritten for C# 4.5, so using that in Unity won't happen for a while. As for matchmaking, I thought about it for some time, and I don't see how a matchmaking service like the one from unity could serve what you are aiming for (which is, by chance, what I aim for as well). I believe that a supersimple script on a server might be fairly enough to just list currently available multiplayer hosts that are looking for players. That is "centralized", but you won't be able to avoid that in internet matches.

As for LANs, I believe players are able to copy an IP address if it gets displayed to them in the right place so they don't need LAN matchmaking desperately, and if they actually do, there is certainly a way to solve that with a single broadcast message as they did "in the old days" .

 

It's not an issue if the matchmaker has high latency, it can be centralized. The code to connect players should try direct first, then nat punchthrough, then if that fails have option to use relay. The problem is the first two options don't make Unity any money, I can't see how with all their high powered network guys they had working on Unet they couldn't implement something like NAT punchthrough which is implemented in multiple free and opensource packages for decades.

 

Hi Everyone,
I'd like to clear up some of the misconceptions I see here and provide insight into our planning with respect to internet play.

First off there's a misconception that Relay facilitated internet play is inherently slow. The best response i have for "is NAT faster than Relay server routed packets" is maybe. I'll try to explain.

Internet routing is a strange and contentious beast, and it's unfortunately not safe to assume a more local geography will have a more direct connection. Here's a wiki page explaining the most common issue with this assumption: http://en.wikipedia.org/wiki/Tier_2_network

The catch is surprisingly major networks are tier 2, like Comcast for instance. So if you're in Boston and you're communicating with someone else in Boston that's not on your LAN (and particularly not on your same ISP) it's actually quite possible your packets will be routed out of your locality to then come back to your friend that's in the same city. For instance on Comcast i personally see a lot of traffic to local Boston destinations routed though New York City.

All this really means is you cant design a system assuming NAT punch through is faster, you'd really have to test both routes and go with the optimal one. The catch is even if both routes are available NAT is not always the quickest choice.

You can think of this less like having a long internet route though Relay and a short one though NAT; what you really have is two different routes through two different sets of networks and either one could be more desirable performance wise. Additionally because of things like retransmits and the quality of networks between you and your destination one route may be preferable despite having more hops or higher average latency.

For us that means other factors like stability also became really important in our initial technology decision to solve routing packets between multiple clients behind NATs. The reliability of a relay service will be near 100%; the reliability of a NAT solution will be a lot less than that given all the different implementations of punch throughs possible with various routers and at the end of the day many real world routers wont have a way to do NAT punch through.

We've seen numbers in the range of 30%-70% of NAT punch throughs work. That means if it's the only tech your game is based on, between 30%-70% of all internet games will fail and most players wont understand why.

Also, we do have several datacenter locations world wide we're going live in to try to optimize locality as best we can. Currently we have datacenters in the US, Europe, Singapore, with China announced as a future location. The fact is geography is important, but it's just a bit more complicated using that as a predictor of the best routing choices.

At the end of the day we had to decide on the right tech to target for the first version of Unity Multiplayer, and the most stable and error free approach is Relay server.

Additionally we do support local discovery directly. This allows you to send broadcast packets on your LAN to have your game auto discovered. This doesn't use Relay or Matchmaker.

Lastly, we are continuing to develop this technology. Going forward we're adding features. I don't have anything specific to announce now but everything is on the table, it's a question of development time and priority. Our goal is to provide you with the tools you need to make a successful multiplayer game, and do it in a way that allows you to focus on what's important: Creating the game itself.

TL;DR: NAT is a great option for internet play, but it can be unreliable. It works best as a fallback to something like Relay server, however to make that work we needed to make a Relay server first.

I hope this helps clear up some of our intentions with respect to the Unity Multiplayer service.

 

Libjingle/Lidgren/Raknet all have a decent enough nat punchthrough and it is nowhere close to 30% failure from any of the numbers I have read, closer to 9%. This link has stats from Google's GTalk service(uses libjiingle) showing a 92% success rate of it's users using STUN/Nat punchthrough alone, which means only 8% use their turn relay.

Jeremy: I don't think it's all about speed, part of it is the fact that NAT punchthrough is free, relay server is not. Multiplayer games have been relying on NAT punchthrough + manual port forwarding instructions as a backup for a very long time and it is well known to most gamers and accepted. I find it strange that the only option offered is a paid relay service and I will stand by that, I would expect any *new* networking library to have figured nat punchthrough in from day 1.

 

So.. 4 months later, has there been any progress on getting NAT traversal / punchthrough with UNet? I just can't take JeremyUnity's word for it that adding an extra hop through the relay servers isn't going to hurt connection speed. If a connection can be made directly with a little NAT magic then that's the connection I want.

So, is this on the roadmap yet? I've read a couple of posts including this one saying that the relay server stuff is being given priority, but that seems to be up and running now. I would really love to hear that it's coming soon so I don't have to implement OpenNat and jump through a bunch of hoops to just to get back the functionality that we had before upgrading to UNet.

 

So.. 5 months later...

 

Have same question like you, but, just calm down and wait for them

 

Matchmaking is improved in Atom Networking, secured and passed rooms... http://forum.unity3d.com/threads/atom-networking.379063/

 

I was trying a small testproject on a rootserver with a public Internet ip adress you know, and it just works(the reasons are obvious).
On a homenetwork with a router setup to use UPnP the same project dosent work , you cant connect to the server running on the home network except you route/portforward the stuff by hand....

well i mean having at least UPnP is an absolute standard today, its a must have, you cant force your players to portforward by hand in their routers, providing tutorials about it in the end or what? wtf

Unity y ju du dis? xD

 

I've recently upgraded to uNet and I too have encountered these problems. NAT punchthrough was free, relay server is not. Not to mention the CCU limitation means I can't have nearly as many people on at a time. I would LOVE to see NAT punchthrough on the roadmap.

 

i am writing a upnp system atm its early beta, it works already, needs some polish still, i am able to upnp already , i plan to assetstore it

 

Unexpereinced in this stuff, just asking, is this type thing necessary to have a server that players connect to rather than to each other? Like a unity instance acting as a server on its own?

Or would you only have to port forward the servers connection?

 

if you have a router inbetween the maschine you want to run a unity instance as a server on, you eighter need upnp or you need to route it by hand in the router else noone can connect to your unity instance that you running as a server.
one exception: if its on the LAN it should work (some routers even block here by standard settings)

 

Thanks for the answer, really appreciate it. I'll definitely keep an eye out for your system on the asset store. Best of luck!

 

i am testing this atm on 3 diffrent router brands , and a random betatester is involved, if all goes well expect a release "soonish".

Karsten.A

 

Hi there, hopefully I'm not stepping on Karsten's toe's here but I just posted my own solution for NAT Punchthrough here: http://forum.unity3d.com/threads/unet-and-nat-punchthrough-it-can-be-done.391845/

I would also like to report that Open.NAT seems to work fine for automatic port forwarding, at least in my tests so far.

 

Hi,

UPnP Manager has been sent to the Assetstore for approval, expect its arival inbetween 5-10 businessdays
the solution works proper and is already used in the Steam game Megatect .
A releasethread will follow.

Karsten

 

UPnP Manager is finally on Assetstore! https://www.assetstore.unity3d.com/en/#!/content/58179

 

Hi @Karsten I was really glad to see your asset got approved but I'm a little confused. The description makes it sound like it just does upnp but also calls it "NAT Punchthrough" but NAT Punchthrough and automatic port forwarding are not the same thing. Does your plugin just do upnp or does it also have support for punchthrough using an external facilitator like the old pre unity 5.0 days? More on nat punchthrough here: http://www.raknet.net/raknet/manual/natpunchthrough.html

 

Yeah I had same question, UPnP != NAT Punchthrough

 

thats why its set in quotes "" most people today understand both as the same, its not indeep technical the same but it leads to the same result, namely that a connection between "non public IP's" ,p2p, however becomes possible.Results is what counts.

 

Is there an ETA on NAT Punchthrough and/or Steam support?

 

But it's really not the same @Karsten and I think as @tiggus and I both demonstrate the description is just going to cause confusion. NAT Punchthrough will work in situations where upnp fails or isn't available so it's kind of disingenuous to claim that your plugin provides NAT punchthrough if it doesn't...

 

Correct, for instance I have UPnP turned off on my home router due to security concerns but NAT Punchthrough works fine. Since the asset is title "UPnP" I think that is ok, but I would expect this question a lot.

Also does it support Apple's version of UPnP? As it is totally different(NAT-PNP)

 

i removed the words "NAT Punchthrough" from the text so that network professionals like you dont get confused

 

For anyone still looking for information on NAT Punch-through / automatic port-forwarding, I just released an asset on the asset store that does it all. And yes @tiggus that includes NAT-PNP for those pesky apple devices.

Check out the forum post for more info or get it now from the asset store.

 

@thegreatzebadiah i find it a bit wierd that you program against an opensource library wich obviously does most of the work and then sell the app on assetstore, its not very ethic imo.

 

@Karsten All of the licenses for the open source software I use allow for commercial use and it's not like I've been secretive about how the plugin works. If someone else wants to figure out how to implement RakNet and Open.NAT and tie them into UNET they are more than welcome to. Or they can purchase my asset. Or they could even use the free code I put out here: https://github.com/noblewhale/NATPunchthroughClient as a base for their own solution using RakNet.

I believe building commercial tools off of open-source software is very much ethical, if not then the libraries wouldn't have been licensed under the MIT Licence which allows:

I'm sorry that we put out competing assets at almost the same time. I hope we can co-exist, and I think our assets are priced well to do so. Yours may have a few less features but it's priced more competitively. Mine is maybe a bit pricey, but it does it all. Everyone wins!

 

you said "In Unity Multiplayer the Matchmaker and Relay server are the solution to enable internet play." is this free to use?