I'm making a multiplayer game for OS X. In the game users will all interact with one another. I'm currently using UDP for this interaction. However, firewalled users of course need to forward their ports to receive information. How does one get around this? I know that games like Quake 3 Arena and many others somehow achieve this without the need for port forwarding.
How does one deal with firewalled users?
- Thread starter itistoday
- Start date
ElDiabloConCaca
U.S.D.A. Prime
AFAIK, only hosting a game is dependent on the firewall. I can join games just fine with the firewall on, but in order to host a game, the firewall must be off and ports forwarded (on the router) to my machine...
scruffy
Notorious Olive Counter
There is a way that some P2P apps are starting to use:
Two clients behind firewalls connect out to a server. Each client sends to the server some a packet saying what UDP port it's going to be listening on, and what its externally visible IP address is, and the server forwards this info back to the other client. Now client A knows the IP address and port the client B will use, and vice versa.
Then the two clients start sending one another "hello are you there" packets, using the source port they've just announced, and the destination port that the other client has said that it would listen on.
So, client A sends stuff to client B, with source port pA and destination port pB. The firewall will expect response packets from client B, with destination port pA and source port pB, and prepare to forward those packets to the internal client. The other side's firewall will do the same.
Once both sides have received a "hello are you there" packet, sent back a "here I am" packet, and gotten the other side's "here I am" packet, they know they have an open connection. They just have to make sure to send packets often enough that the UDP connection won't get timed out by the firewalls.
Two clients behind firewalls connect out to a server. Each client sends to the server some a packet saying what UDP port it's going to be listening on, and what its externally visible IP address is, and the server forwards this info back to the other client. Now client A knows the IP address and port the client B will use, and vice versa.
Then the two clients start sending one another "hello are you there" packets, using the source port they've just announced, and the destination port that the other client has said that it would listen on.
So, client A sends stuff to client B, with source port pA and destination port pB. The firewall will expect response packets from client B, with destination port pA and source port pB, and prepare to forward those packets to the internal client. The other side's firewall will do the same.
Once both sides have received a "hello are you there" packet, sent back a "here I am" packet, and gotten the other side's "here I am" packet, they know they have an open connection. They just have to make sure to send packets often enough that the UDP connection won't get timed out by the firewalls.
that's odd though, because I had a similar model already setup, and the clients were sending each other a lot of information within very small intervals, and they weren't receving it unless the firewall had the ports forwarded. Do the send and receive ports have to be different, because in my case they were the same.
You're basically saying that if they start sending each other data, the ports will magically open up?
You're basically saying that if they start sending each other data, the ports will magically open up?
wadesworld
Mac Developer
Multicast traffic won't traverse the Internet.
On some firewalls, once the interior computer starts sending traffic, it will let return data back in.
As for the address issue, what you need to do is have a server process that's in charge of communicating with all the clients and keeping track of their external IP addresses.
Wade
On some firewalls, once the interior computer starts sending traffic, it will let return data back in.
As for the address issue, what you need to do is have a server process that's in charge of communicating with all the clients and keeping track of their external IP addresses.
Wade
Have you guys heard of this method:
A client that is not firewalled or has its ports forwarded is used as a relay to bounce information to another client, which has a direct connection to the un-firewalled client. However, I don't think this will work because what happens when there are no open clients available?
A client that is not firewalled or has its ports forwarded is used as a relay to bounce information to another client, which has a direct connection to the un-firewalled client. However, I don't think this will work because what happens when there are no open clients available?