UPnP/NAT Punchthrough

Unity Engine
1

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)

2

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.

3

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

4

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.

3 Likes
5

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.

6

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 :confused:

7

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” :).

8

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.

1 Like
9

Hi tiggus,
BTW what you can recommend from these (free and opensource and working:) ) libraries? :slight_smile:
regards
Alex

10

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: Tier 2 network - Wikipedia

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.

2 Likes
11

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.

8 Likes
12

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.

13

So… 5 months later…

14

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

2 Likes
15

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

16

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? :smile: wtf

Unity y ju du dis? xD

2 Likes
17

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.

1 Like
18

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

3 Likes
19

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?

20

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)