UDP works on local network but not on global network

Hi,
i'm trying to create a multiplayer game where i stream the position and rotation of let us say max 200 game objects between two clients ,
i started making a test UDP connection to send simple string between two clients, it works on local network only,
i've read that i have to do some networking setup on the router to make it work on global network but i don't want to do that, i'm looking for a simple solution that works by default everywhere,
do you guys think UDP is a good way to go, what about TCP

Thank you,

 

In any network solution where there is a direct connection, a port must be open ... Where are you going to send data if there are no available ports?

 

The issue has nothing to do with UDP vs TCP. The issue is when you are behind a home consumer grade router your computer has an internal non-routable IP address assigned. Google for "Network Address Translation" for more detailed information, but I'll cover some of the basics.

A computer elsewhere on the Internet has no way to use that non-routable address to send your computer a packet. The other computer can send a packet to your router, but if your computer is acting as a server and didn't initiate the communication, then the router has no idea what the hell to do with this packet. There can be multiple computers behind the router, and doesn't know which computer to send the packet to.

So usually when behind one of these routers, your computer can open client connections but can't act as a server. When you initiate a client connection to somewhere else on the Internet, the router keeps track of that in a translation table. When it gets a response from the same destination IP and port number, it knows your computer initiated the connection so is the one to direct the response, so it forwards it to your computer.

To act as a server though, you can edit your router's configuration by enabling port forwarding. That tells the router that any communication outside the network directed at 1 or more specific ports, is always to be directed to your computer's IP address behind the router. That way your computer doesn't have to imitate the connection as a client, so it can also act as a server for those specific port numbers. So if you were to do this, you first need to decide between TCP and UDP (they use the same ports system, but are configured individually), and what specific port number(s) you will use. Often you will use just 1 port, but there are reasons to use more than 1. Then you direct those specific port number to your computer's IP address. Client's on the internet then connect to your router's external IP address at those ports, and it all works if configured correctly. If configured incorrectly, it don't work, cause details matter here.

But as far as a simple solution that works everywhere, you set up a dedicated server in a datacenter and skip all this stuff. Either the dedicated server runs the actual game, or it facilitates connecting players. Often that is done through a matchmaker system to pick players to connect together, and then either a relay server to be a middleman for all network communications or to connect the clients together using a trick often called NAT punch through. Those topics are all covered in any number of previous threads, and are big topics on their own, so I'll leave it at that for you to google more on them. Good luck.

 

On the real question of TCP vs UDP, usually you come to that decision based on how you want your game to behave if/when packets are dropped. If what you need is all networking on the client to basically halt until any lost packet is resent, because every packet is mission critical, then TCP is pretty obvious. If most of your packets are pretty trivial because the data is already too old to bother resending when lost, then UDP makes more sense and you build your own reliability system on top of that to guarantee the smaller number of important packets actually reach their destination if lost. UDP is often considered faster but you have to worry more about issues like packet size, while TCP is often considered just easier to deal with because it works more like sending a stream of data instead of small bite size individual chunks. There's also a lot of debate around this topic, and I'm sure lots of people disagree with what I've said

 

Hi @Joe-Censored thank you for taking the time to explain this to me, i've been doing my research as well and i have came up to a conclusion as a solution for this problem, hoping that i got it right

the solution is to create a server on the internet,
let us say that we have two clients A and B that have sent packets to the server, the server have the ability to know the public IP and Port of the clients, now the trick is to use the server to communicate client A public IP and port to client B and client B public IP and port to client A
now client A and B have each other public IPs and Ports , they can establish peer to peer connection with no problem

 

If NAT punch through is not a part of this, then what will happen is when client A tries to talk to client B's router, the router doesn't have a record in its table of a connection to client A's IP/port, so doesn't know what to do with it and drops the packet.

 

exactly