I've noticed that with TCP/IP firewalls are less of a problem in multiplayer gaming, only the server side has to have the specific port open (to incoming connections), whereas the client side 90%+ of the time will have all ports open (to outgoing connections), i.e. like HTTP port 80, you can always connect to web addresses (for two way communication), but you have to open up your port 80 if you want to host a website on your computer (if you have a firewall that is). Now, with UDP it's a lot trickier. The majority of people have all UDP ports closed (to incoming messages), so for the most part they can only send out UDP packets, but can't receive. I was wondering if there was any way around this? btw: Can you have two sockets on the same port e.g. UDP on port 2000, and TCP/IP on port 2000? or will they clash?

Quote:

Original post by Memir Now, with UDP it's a lot trickier. The majority of people have all UDP ports closed (to incoming messages), so for the most part they can only send out UDP packets, but can't receive. I was wondering if there was any way around this?

Most if not all not-braindead packet filters can recognize a UDP packet "related" to a previous one, so if a client sends from a specific port, it will also accept replies on that port.

Quote:

btw: Can you have two sockets on the same port e.g. UDP on port 2000, and TCP/IP on port 2000? or will they clash?

Other than both concepts of a communications endpoint are called "port", they aren't related. So there's no problem with using TCP and UDP ports with the same number at the same time.

As long as you don't do stupid stuff, UDP should work fine. You should:

- Bind the client socket to inaddr_any and port 0 (or not bind it at all)
- Have the server send packets back to the same port number it receieved them from (Perhaps exclude reserved ports < 1024)

You should not:

- Bind to a well-known port on the client-side
- Send to a well-known port on the server-side

This is because a router will probably do NAT (most people do these days) and change the client's outgoing port number from what it thinks it is using to something completely different.

However, the NAT will also apply this transformation in reverse to incoming packets, so the process is transparent to the client.

But if you start using well-known port numbers for your client, you're asking for trouble.

Mark

k, thanks guys. this is working now...

ok i've got another question.

if two computers (different locations/IP) have a UDP port closed. if they both send out a UDP packet to eachother's IP's will that open up the UDP for further 2-way communication, or does atleast one computer have to have their UDP open? i suspect the latter is the case, otherwise you wouldn't have to set up UDP ports for multiplayer games such as Starcraft, Warcraft 3 etc. (everyone would just send out dummy UDP messages to eachother in the game to open up their UDP ports).

Well this is my current project => www.playonlinesoccer.com <= it's an online football/soccer game. so you can see where the UDP communications come in. I'll be putting up a new version(s) today. So your welcome to playtest it.

[Edited by - Memir on September 19, 2005 7:06:39 AM]

If both machines are NAT'd, you can't establish communications directly between them. This is non-negotiable and applies equally to TCP and UDP.

You're going to have to be more specific about "open" and "closed".

If by "open" you mean "With a static NAT forwarding rule from a router which would otherwise do dynamic NAT", then yes, you can do it provided at least one of them has such a rule.

But of course they need to be set up on a per-port basis.

In the absence of NAT, you should be able to just connect from one box to another.

Mark

If by "firewall" you really mean "NAT" then you will need a third introducer service to make the UDP connection "go". This is mentioned (with links) in the FAQ.

Note that TCP ports and UDP ports are different name spaces (that just happen to each be 16 bits) so it's perfectly fine to have a TCP socket and a UDP socket both listening to ports that happen to have the same integer value. Traffic on one is totally separate from traffic on another, both as far as networking is concerned, as well as the firewall.