Question UDP network traffic not reaching destination

[Taien]

I'm writing an online game. I've constructed a system for passing packets via serialization. For some reason, if I run the server on my local network and connect from the same PC, it works fine. But any other PC on the network and on the internet cannot seem to send packets to the server.

I have tried port forwarding, allowing it through Windows Firewall, and hosting it via various IPs such as the local IP, my public IP, etc. Nothing seems to get through. Does anyone have any ideas as to why the network traffic would be getting blocked despite being allowed through the firewalls on both PCs and being port forwarded to the server? I am at a loss.

I have been trying to solve this for months now. I thought I had discovered the culprit the other day (Windows firewall), but that's a dead end too. Nothing I do seems to allow the packets to reach their destination short of hosting and running the game on the same PC. Please, help.

You can ask me for any code you may need and I'll post it. I'm incredibly frustrated and ready to just give up on my dreams. We've spent a year working on this game and I still cannot get it to successfully receive packets over the internet.....

I'm using the UDP protocol and I know my code is correct since it works on a local level. I just don't know why the packets aren't reaching their destination over the net. I need suggestions, any suggestion which might help me solve this. I know I'm being redundant now but I'm at my wit's end. Thanks for any help anyone can provide.

 

[Skydiver]

Post the minimum code needed to reproduce the problem. There's no need to post your entire game. Just create a simple console application that lets you send and receive UDP packets.

Personally, the most common culprits I find in situations like this are:

• Windows Firewall configuration
• Antivirus Firewall configuration
• Antivirus silently blocking accepting/sending packets despite settings requesting prompting (yes, I'm looking at you latest version of Avast)
• Network not configured to allow broadcast across subnets

Out of curiosity, why did you roll your own game networking instead of using a library. Lidgren or RakNet are pretty good from what read about them.

 

[Taien]

Ok, thanks. I hadn't thought to remove the UDP code and run it separately to detect problems, that's a great idea.

As for rolling my own netcode...honestly I didn't know about Lindgren and I always like to challenge myself a bit. I'm just having a bit too much of a challenge this time, lol. Plus I found some great examples online of how to write a very tiny network layer that does what I want it to do. I'll try out extracting the UDP code and if I still can't solve it, I'll reply and post it here so you can take a look. I really appreciate the help!!

 

[NoUserHere]

I'd just like to point out that UDP is known for dropping packets, and TCP on the other hand is much more reliable from that standpoint. Curious, why you chose UDP anyway?

 

[Taien]

Yeah but I'm not talking about just a few packets....none of them are reaching the destination.

As for why I chose UDP, there's a lot of articles on it online and from my understanding TCP/IP is just too slow for handling many game updates per second. It also works in a way where some packets may not even be sent until a certain size threshold is reached. UDP is better because it's much faster and while there may be an occasional dropped packet, in a game where I'm updating 30 times per second (as we will be) it doesn't matter if a few are lost. I just need to figure out what's causing them to get blocked For packets that MUST be received by the client, I've put in place some response packets so the server knows it was received. If the server/client doesn't receive the response packets, it sends the original one again about 500ms later until it does receive the response (these packets are not so much game updates - they're mostly login packets, character list packets, and world info (as it is a sandboxy game, the world is actively downloaded as needed)).

That's why If I have an incorrect perception here, feel free to correct me.

 

[Skydiver]

You are correct. The general issue with TCP for games is the throughput of messages when playing across the Internet. There tends to be blocking while waiting for packets to be assembled in order to present the data as a stream. A game that uses UDP and accepts the fact that packets may get lost or arrive out of order is usually better off.

 

[NoUserHere]

If I have an incorrect perception here, feel free to correct me.

No, you are more or less correct in your beliefs.

And while I partially agree with what Skydiver said above. I think I'll just put this link here as the first paragraph really sums it up quite well. It's actually one of the better answers I've read from that website on this topic : UDP vs TCP, how much faster is it?

There tends to be blocking while waiting for packets to be assembled in order to present the data as a stream

That part I don't necessarily agree with, as this really does depend on how you write your code and configure the network you're connecting to on TCP.

It should also be noted that routers with restrictions on packet size for data transfers can also block these packets, and there is no way around this if this is your problem.

 

[Skydiver]

this really does depend on how you write your code and configure the network you're connecting to on TCP.

Yes. If you have full control over the network configuration end-to-end, TCP will be great. But when you start getting into the wild wild west of various people's ad hoc network configurations, or someone trying to play in a hotel with an over subscribed WiFi and/or internet connection, then things get much harder.

It should also be noted that routers with restrictions on packet size for data transfers can also block these packets

And somebody's personal experience going down the UDP code, to TCP code, and the going back to UDP (using Lidgren) and hitting the large packet size issue:

Choosing A Network Library in C#

I am a bad, bad man for not having blogged about this sooner. Last year I blogged about How I Chose SlimDX as my graphics/sound/etc library of choice. And I’ve been meaning to blog about how I chose my network library, and what I think of it, yet have failed to do so. This was…

arcengames.com