Hi guys and gals. I'll try and keep this as concise as possible while giving all the necessary details. This is regarding a game but I believe that this isn't necessarily a 'game' issue.

So I'm essentially making an Android game which communicates to a server (which is now my computer). The app will continuously request for updates from the server, and the server will collect the current game status and send it back to the client.

So, I got everything working while using a local ip. Then I investigated how to make a server out of my computer (This part I am very new to). So I used noip.com to set up a host dns, and set port forwarding on my router to send all data going to the port to my PC.

So now it's at the point where the android devices communicate to my PC through the hostname. However, after about a minute or so, the android device will send a message, but it will take 1-2 seconds for the server to see it. Then shortly after this begins, the connection will hang for 15-20 seconds at a time.

Things I've ruled out so far:

1) I've tried using my outside ip to send the messages instead of the hostname, same problem.

2) Doing a speedtest, I have 30 mb down and 6 mb up, so I think that's ok. These messages are presumably much smaller than other games (50 bytes back and forth) and I do a good amount of online gaming with no issue.

3) ping testing the hostname for an hour and the highest ping time was 2ms, which is much less than what I'm seeing.

4) I did confirm that neither side is hanging up, the android device is sending the message and then waits for the return, and the server is still waiting to see the message.

5) Switching back to localhost and I don't have this lag issue whatsoever.

6) I did some research on windows firewalls to confirm as best I can it's not interfering.

I'll gladly share any code/network information I can provide, but I'm not sure what would be beneficial right now, given the clues I have.

My next test will be testing this on a raspberry pi, but that will wait until tomorrow.

Thanks. :D

If you're using TCP, switch to UDP.

http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

If you're using TCP, switch to UDP.

http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

I'm using UDP. It does receive the packets 'eventually' when going through the host, it just takes a longg time (30+ seconds at its worst)

It sounds like you have a code bug somewhere.
Use Wireshark to look for packets sent to your particular port.
Separately:

The app will continuously request for updates from the server

If a "connection" exists, you can assume that the player wants the world state.
You don't need to have the client "request" the data.
Instead, the client should send "I'm alive, and here's my next input commands" messages X times per second, and the server should send "here's the latest world update and commands from all the other players" Y times per second.
The server can then look at the incoming stream, and if it hasn't seen anything from the player for something between 3 and 30 seconds, assume the client has disconnected.
Same thing for the client; if it doesn't see anything from the server for a timeout period, assume the connection has dropped.

It sounds like you have a code bug somewhere.
Use Wireshark to look for packets sent to your particular port.

Instead, the client should send "I'm alive, and here's my next input commands" messages X times per second, and the server should send "here's the latest world update and commands from all the other players" Y times per second.
The server can then look at the incoming stream, and if it hasn't seen anything from the player for something between 3 and 30 seconds, assume the client has disconnected.
Same thing for the client; if it doesn't see anything from the server for a timeout period, assume the connection has dropped.

I'll check wireshark if not tonight tomorrow. But the 2nd part of your post describes how the messages are actually sent back and forth, I think I didn't describe it too well.

If you're using TCP, switch to UDP.

http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

Upon further review, I actually am using TCP. My understanding of what TCP was not correct.

I suppose I'll have to make the switch.

No, you don't have to. TCP is perfectly fine and will not be the cause of your problem.

You're going to have to show some code, or at least share some technical details. The problem is likely to either be something weird you're doing that incurs this delay, or a slow DNS look-up from the 'NoIP' provider. You can check for the latter by connecting directly to your network's IP address instead of using the provided hostname. (And if it is a slow DNS look-up, it implies you keep making new connections each time, when you should be continuing to use an already-established one.)

You said you're doing this from Android devices. Is this over the mobile network? The latency on those can be unreal sometimes.

Agree with Khatharr. I am a professional Network Engineer (although not for a Telco) and latency over mobile networks can be very erratic. Your occasional 1-2 seconds could be related to this but the 15-20 seconds does not. No packet should take that long (even Earth to the moon is about 1.3 seconds).

Switching to UDP would not help in this case.

Most likely there is some kind of bug in your networking code itself that causes these errors to pop up? Are your sockets blocking? If so, what is the timeout set on them? Example: lets say you set 5 seconds as a timeout, and you send a packet from the sender to a receiver but it gets lost/dropped along the way, you wait 5 seconds and resend, it gets lost, you wait 5 seconds and send again and it makes it.....there is 15 seconds there due to 2 consecutive lost transmissions. Lost/dropped packets on mobile are much higher than other networks as well.

Note that "15 seconds latency" could be something as simple as "getting the framing of individual packets on a TCP connection wrong, and thus packets run into each other and the recv() call blocks."
For a newbie to network programming, there are so many things that can go wrong at the basic API level, it's hard to diagnose from a simple high-level self-reported symptom like that.