UPnP Doesn't seem to be working

[destructicorn]

I'm having some issues with UPnP on my game.  Right now any player who wants to host my game has to forward their ports,  this is a major downside since not everyone knows how.  I changed the StartRemote function in TNServerInstance.cs so that in the if(mGame.Start()) block the mUp opens my tcp and udp ports just like StartLocal does.  I assumed this would work but I'm not having any luck.  I would appreciate any direction on this.

[Duster]

(Nevermind - stupid mistake on my end when I cut and pasted the up.OpenTCP() line from somewhere...)

[Duster]

Hmm - I think I accidentally stepped on the original poster's toes when I chimed in about my own issue with UPnP then discovered my silly mistake. Sorry destructicorn if I got in the way of an answer to your question.

But a day after I got it working, it's suddenly stopped and I haven't been able to figure out quite why. I've added some logging, and from the request it sends and the successful response, it sure looks like it worked, but a simple telnet test from outside fails (one which succeeded the day before).

So aside from making sure the UPnP object doesn't get disposed (which it isn't), is there anything obvious to check in debugging this?

[ArenMook]

Unfortunately UPnP implementation differs drastically from one router to the next. Some routers, like Apple Failport flat out don't support it. Most of the time it works out of the box, but some routers also don't like repeated open/close requests that tends to happen with developers and can crap out. Furthermore some routers dont support loopback addressing (connecting to yourself using your external IP). UPnP will not cover 100% of your users. No solution will. UPnP is more reliable than NAT punchthrough, but it's far from perfect.

[Duster]

I ended up figuring out that the router was "stuck" with the port open to a second device I was testing with only sporadically - which, if the game were still running on there would seem appropriate, but it wasn't.

This got me thinking though that the best thing to do is to give as many options to the player as I could - let them hardcode their own port if they are capable of doing it manually, or having the game pick a random port so it doesn't likely hit a "stuck" port. I also added a way to change the UPnP lease time in case that would be helpful.

But the results aren't as good as I hoped, and everything points to the routers involved. It's frustrating and I don't really have the time to read the specs closely enough to get a better understanding. The plan is to just start hosting the GameServers centrally, but until that can happen, I guess I'm just wondering what other kinds of workarounds people are doing.

[pyscho2day]

I also added a way to change the UPnP lease time in case that would be helpful.

Did you add this to the repo or locally?  If locally would you be willing to share the code?

[Duster]

Just a local change, but it's simple enough - just add this somewhere:

1.         public int newLeaseDuration = 0; // "infinite"
2.         public void SetNewLeaseDuration(int duration) { newLeaseDuration = duration; }
3.  

And then change the request line in Open() like so:

1.                                 "<NewLeaseDuration>" + newLeaseDuration + "</NewLeaseDuration>\n";
2.  

Not sure if it really should go in the codebase though - at least not a simplistic version like this. Ideally, the class would keep track and renew the lease if the game gets near the expiration time. Right now I'm just at the stage of figuring out what helps the situation.

[destructicorn]

So is there not much I can do about this?  Seems like it fails to work properly most of the time.

[Duster]

What we're going to try is starting a test server on each client that just accepts a simple connection and ask the lobby server to try connecting and use the success or failure of that dictate whether we will ever tell that client to start a local GameServer.

It's not really ideal, but given that the success of a UPnP test doesn't really tell us much (or failure, for that matter), it seems the most reasonable thing to do.

[pyscho2day]

What i have done to get around the upnp ports not being opened is a multi part thing.

1st is if i start a server I will keep looking for another server to join unless some one has connected to me.
2nd is if i try and connect to a server but am not able to i add it to a temporary blacklist so that i don't try again till restarted.

This seams to work for what I am working on as servers will hopefully be always starting up or spaces open up.