Jump to content
  • Advertisement
Sign in to follow this  
Klutzershy

Getting my head around UDP

This topic is 2549 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I want to make an online FPS. I'm using game maker and I want to try to use entirely UDP for the first time instead of just TCP. What I still don't understand, however, is how exactly the relationship between the server and client works if both are behind firewalls.

From what I do understand, the server still must port-forward. But the client can receive messages from the server without port-forwarding because of "hole-punching", where when the client sends a packet, the firewall is temporarily opened up to receive packets on the same port. Am I right about that? Another thing I'm confused about is that you need to use multiple ports for a 2-way connection. If so, since I'm not planning on direct client-to-client connections, can I use one port for server-to-client and another for client-to-server for any client?

Otherwise, it's the same and I should just make connecting to the server retry or timeout after a certain while (if the packet wasn't acknowledged), right?.

Thanks!

Share this post


Link to post
Share on other sites
Advertisement

From what I do understand, the server still must port-forward. But the client can receive messages from the server without port-forwarding because of "hole-punching", where when the client sends a packet, the firewall is temporarily opened up to receive packets on the same port. Am I right about that? Another thing I'm confused about is that you need to use multiple ports for a 2-way connection. If so, since I'm not planning on direct client-to-client connections, can I use one port for server-to-client and another for client-to-server for any client?


Hole punching has nothing to do with it if you port forward to the server. UDP works through NAT firewalls because NAT firewalls know how to re-write and forward UDP packets (just like they do with TCP packets), and then re-write and send them back when responses come in. Because UDP doesn't have state, the firewall will keep the port rewrite mapping open for a while after it's seen each packet -- between 1 and 10 minutes is a common value. Note that it is important that the server uses recvfrom() to get the address of the client (which will be the firewall address), and responds back to exactly that address, so the firewall gets the packet and can forward it back to the original client.

For a UDP client, when starting up, I would send perhaps 3 or 4 UDP packets, waiting 500 milliseconds after each, and if I still don't have a response after 3 seconds total, I would declare the server not responding.

Share this post


Link to post
Share on other sites

But the client doesn't have to port-forward, right?


NAT works like a one-way gate. The people on the inside can get out, but people on the outside cannot come in.

Once the person on the inside has opened the gate, the two can happily communicate all they want across their connection until they are done and the system closes the gate behind them.



Those inside a properly-configured NAT don't need to do anything special to connect to a public address. They simply open the connection and the magic happens. The person can be behind many layers of NAT routers, it doesn't matter as long as the destination is a public address.




As long as you are attempting to connect to a public Internet address, the client doesn't need to do any work.

If you need to make connections back in to the client, such as many games that use VoIP or other libraries to connect directly, those connections will need to port forward or take other steps to overcome any NAT routers between them. It can be tricky, especially since it is more common to see two or three or even five NAT layers between a home consumer and the public Internet.

Share this post


Link to post
Share on other sites
Great. I'm not planning on peer-to-peer connections so port-forwarding for clients shouldn't be an issue :)

Thanks!

EDIT:
There's one thing I still don't get. Would the server use a different port to listen to each client or is it fine to listen to all the clients on a single port since they all have different IP's (and different sockets, I presume).

Share this post


Link to post
Share on other sites

There's one thing I still don't get. Would the server use a different port to listen to each client or is it fine to listen to all the clients on a single port since they all have different IP's (and different sockets, I presume).
[/quote]
Just use one socket. Opening a socket for each client would make managing a server behind a NAT much more difficult, to the point of impracticality.

Share this post


Link to post
Share on other sites

Great. I'm not planning on peer-to-peer connections so port-forwarding for clients shouldn't be an issue :)

Thanks!

EDIT:
There's one thing I still don't get. Would the server use a different port to listen to each client or is it fine to listen to all the clients on a single port since they all have different IP's (and different sockets, I presume).


With UDP you don't have a connection per say so one socket on one port on the server and use recvfrom to find out which ip and port you have to send the reply to. (using sendto)

Share this post


Link to post
Share on other sites
Ah. So the server only needs one listening socket because you don't need a real connection between two sockets. I think that's it now :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!