Issues connecting to Example Menu demo from different LANs

[gg67]

Initially, I changed the Example Menu to connect to an AWS TCP Lobby to find all active game servers. This worked fine, and I could see game servers that had been created on different LANs. However, when I clicked on one of the game servers to join, I get the error message "Unable to connect". I figured it was a port forwarding thing since I'm pretty sure the routers I'm messing with don't have UPnP. Thus, I manually forwarded ports 5127-5129 on my home router to my machine and expected at least others would be able to connect to me. No dice. At this point I had been using a buddy to test my application from his network but decided it would be easier to start up another AWS Windows VM to act as a test game client. This leads me to my current testing environment.

Machine 1 (Mac) running on my home network, with ports 5127-5129 forwarded to my machine.
Machine 2 (Windows Server 2012 VM) running on AWS, with ports 5127-5129 open to my home IP and the Unity app has been given permissions to go through the windows firewall.

Both machines are running the Example Menu, and I'm completely bypassing the Lobby Server for now and just directly connecting to one machine to another using their respective IPs. First I start a game server on Machine 1, manually type in Machine 1's IP on Machine 2's app, press connect, and get the error, "Unable to Connect". I would think this would work since I have my home ports forwarded. Then I try the other way, start a game server on Machine 2, manually type in Machine 2's IP in Machine 1's app, and press connect. Same thing. And since I've made sure my home IP is allowed to hit the AWS VM and have the correct ports forward on AWS, I would assume this would work as well.

Any help would be greatly appreciated!

[ArenMook]

AWS requires you to open ports in two places -- via the web config, and on Windows side itself. I flat out disabled the windows firewall in order to get it to work (as it's pointless with the primary firewall anyway).

[gg67]

Great! Turning off the firewall did the trick, although I don't know why it wasn't working before since I had the specific ports opening. Now for a few follow up questions.

1) When I incorporate a TCP Lobby, the game server IPs that show up are sometimes the internal IP, not the external, which obviously causes issues when connecting. I found a thread about this in the forums and you mention you posted elsewhere about it but I couldn't find any of those posts. http://www.tasharen.com/forum/index.php?topic=6071.msg28777#msg28777

2) How well would an AWS Windows instance acting as a Game Server work? After an initial test the ping is super high and since I'm using AWS' free tier it makes sense. I guess it depends on how much data I'm moving over the network?

3) A little unrelated, but how does the server.dat file work? I'm going to guess and say it stores server data and a different one is created for any game server that is created?

Thanks!

[ArenMook]

1. Yes, sometimes it fails to resolve it. I will do a work-around for it in the future.

2. Free tier is pretty crappy, yes. You will get a ping of 120-200 ms with the free tier. It's good for a meeting lobby, or a turn-based game, but certainly not for any kind of a real-time game. I have no experience with Amazon's paid servers, so can't advise past that. I'm sure they're better though.

3. Server.dat simply saves all RFC calls that were deemed persistent (Target.AllSaved, Target.OthersSaved). When the server starts up again, the RFC calls get loaded from it, restoring the state.

[gg67]

Has a work-around been implemented regarding the issue where TNet fails to resolve the external IP? If not, can you point me in the direction how you were planning to do it? From what I can tell, you're just hitting a DNS server to get the external ip and I don't understand why that would ever fail.

Thanks!

[ArenMook]

Simple -- if the first attempt fails, keep trying until it does.

Sometimes HTTP calls seem to fail, and since that's what TNet has to rely on to get the remotely detected IP, that fails in turn. Re-trying until it succeeds should be simple enough.