I just written a multiplayer game with winsock but i am having an issue with udp packets and firewalls. Basically if someone has a firewall like ICF in winxp they cant receive udp packets but don’t have a problem sending. I''ve seen other games where they got around this. Does anyone have any ideas for me please?

AFAIK to get past the firewall, you either have to use TCP, or you have to forward the UDP ports that your game/program uses on the firewall.

Thanks for your input. The game uses both TCP and UDP. TCP works just fine but on some people they can''t receive UDP. Its interesting to say that I just ported this from DirectPlay and that when I used DirectPlay NAT users had no problems as a client and note that DirectPlay is all UDP. The way I see it DirectPlay did something with UDP and when connecting to the server made the nat open the incomming UDP port.

Perhaps if you connect() a datagram socket it makes the router open up in a similar way as it does for tcp...

TCP is easy. inside pc sends connect packet to the NAT. the NAT rewrites the packet so it looks like its coming from the NAT pc, it also changes the source port in case multiple pcs are connecting to the same outside pc. now the host will send an ok which gets sent to a particular port in the NAT box. the NAT box then uses the port the packet came on to send the packet to the correct internal pc. it keeps this mapping till it sees a connection timeout, or TCP close packets.

UDP is more difficult. there is no connect. the inside pc sends a udp pcaket to the server. the NAT will notice this, see the source iport and dest iport which are palced in a table for the mapping. now the NAT changes the packet just like in TCP. also like TCP the mapping lasts only a certain length of time without packets (ussually a minute or so). now the server sends a packet to the NAT. the NAT will look at the dest iport for the packet, and see where its going. it checks the table and then maps the packet to goto the correct place internal. this is where the problem may occer. you see the NAT may change the incoming port, yet the game may not handle this. it may ignore the port that the client is sending on, thus when it sends the packet to the client it uses the wrong port. now the NAT gets confused since its getting packets on a port that may not be mapped, or be mapped to the wrong internal pc. this is not a problem with TCP since the only time the port is an issue is on connection. thus the mapping is pretty static. UDP has no such connection.

the fix?

well assuming that are making the mistake of sending udp packets blindly, you just need to check the source ip AND port of packets to determine which client and what to reply to when sending packets to the client. if you do this already, then get a better NAT. the reason other games work is they dont fix the source port to one value. they correctly handle the complete iport combination to determine "connections" and uniqueness of clients and where to reply to.

The problem is actually that the way the winXP firewalls work is by blocking all connections attempted that didn''t start from your computer, and allows all connections that start from your computer. Now there would probably be some sort of problem if both of you had firewalls. I''m not sure how that would work.

-=~''''^''''~=-.,_Wicked_,.-=~''''^''''~=-

quote:

---

Original post by Anonymous Poster
Perhaps if you connect() a datagram socket it makes the router open up in a similar way as it does for tcp...

---

oh please...read a book

using things like ICF (ie any nat) means that teh internl pcs dont have real internet ips. basically unless the internal pc sends a udp packet first its IMPOSSIBLE for the nat to automagically know who is supposed to recieve the packet (especially since th actual nat may be the one who is to receive the packet).

its the equvilent of me giving you some book. you dont know what to do with the book. you only know it came from me, and it was recived by your hands. you dont know if your supposed to read the book, or someone you know is supposed to get the book. (this analogy could have been done with mailboxes, and the post office as well).

the correct game would be more like:
someone you know gives you a book, and instructs you to send it to me. you then give me the book and say its from you. now you know that the person you know (call him A) might be expecting a book in return from me (call him B). so you keep that in mind and the next time you recieve a book from B you will assume it belongs to A thus pass it along to him. B technically never knows about A, and uses you as a mediator. ussually in such scenarios the server (ie B) will need to be able to send packets to none traditional ports since you (ie the nat) will rewrite the packet to come from a different port so the nat can differantiate between mulitple ppl behind the nat.

i guess i just repeated myself, but Wicked Ewok gave you information that is kinda false when dealing with udp.

firewalls and icf (ie nats) are VERY different beasts. firewalls generally filter packets and dictate who can connect to what. they dont handle sharing a connection and thus dont have problems with udp if the correct ports are open. nats on the other hand actually sharea single ip with mutliple pcs so its important that a iport pair is used to differentiate clients and that you send to the iport pair that the nat works correctly.