I go to school at Digipen. They only allow outside access through ports 8000-8005. So I can tell my program to only use those ports... but what if I did not know which ports I could use? Would it be feasible to implement a port scanner to determine the available ports? Crunching some quick numbers: ~65000 possible ports x 32 byte message (UDP header + 4 bytes) = about 2 Megs How fast could I send those 65000 msgs? Is there any overhead besides the obvious upload bandwidth? I.e. can I send 65000 msgs in the same amount of time I could upload a 2Mb file? Does this sound anywhere close to a good idea?? :) Haha, thanks for any suggestions.

Pick one port as your "standard" port. Try to use that. If it doesn't work, inform the user of the problem. Let the user pick an override port through a settings dialog.

Common now, I'm not a jackass. The output port is configurable. It is normally set to 0, which allows the OS to determine the port (usually around 1024-1030).

I'm trying to determine an open port to send from on the client's side.

You think it would bring the network admin trouble? I'm just trying to send from a lot of ports.

It wouldn't take a gross amount of time. It's not like I'm going to send 1 packet, then wait. I'm going to send about 1000 packets, then check for a reply from all of them.

Quote:Original post by Kylotan
The time consumed is nothing to do with the packet you send, it's to do with establishing the connection, and firewalled ports tend to fail silently and slowly.

It will only have to establish a connection if the packet gets through. So I will only be establishing one connection. Firewalled ports may fail silently, but I don't see how they could fail slowly. Either the packet gets to its destination in ~30ms or it doesn't. Firewalls don't slow down packets.

I don't understand how the time consumed has nothing to do with sending the packets. Nothing else in the equation takes time from the program's point of view. The prog would have to:
a) create 65000 sockets and bind them to a certain port
b) send up to 65000 packets for a total of about 2.1 megs of data
c) listen for a packet on up to 65000 ports with multiple select calls
d) receive one packet (if we get through)

Now obviously I wouldn't do those in that order. I'd probably try to batch around 500 at a time. And those 500 wouldn't be 1024-1524, I would make sure to jump around and intelligently search in the hopes that there was a batch of open ports.

What really concerns me is that professional games work behind the router that initiated this problem. Although most every game uses TCP, even games like Battlefield 2 work fine... and I fail to believe they fall back on a TCP network plan.

Quote:Original post by Kylotan
Yes, the network admin wouldn't like it, and such things tend to come up on their radar very quickly. It probably would take a 'gross' amount of time - have you tried running a port scanner yourself? The time consumed is nothing to do with the packet you send, it's to do with establishing the connection, and firewalled ports tend to fail silently and slowly.

Yep. A thorough port scan takes a "gross" amount of time. A faster approach may be to do the opposite, that is, list all TCP and UDP endpoints on your system, eg: TCPView.

Are you sure your network is filtering SOURCE ports? Most of the time, it's destination ports that are the problem.

Note that UDP, being lossy, is exceptionally hard to do solid port detection for. If you send 1000 messages, each of which is 32 bytes, then the router might only have space for 500, and dump the other 500 on the floor. You don't know if the reason you didn't get an answer was that the port is blocked, or you just exceeded some queue or bandwidth capacity somewhere.

Quote:Original post by hplus0603
Are you sure your network is filtering SOURCE ports?

Yeah, I was pretty disappointed to find out that not even the initial packet made it to my server.

I never expected it to be easy to port scan all 65000 ports... but it is really my only option. Well, the other option would be to fall back on a TCP system, but that would give me more overhead than I want. I've heard that Battlefield 2 actually falls back to TCP if the UDP is blocked. This would explain why it works from the same place that I can't get to work with my prog. Could this be true?

And its mildly okay if it takes a "gross" amount of time. Although, I'm pretty sure that it won't take any longer than uploading 2 megs of data, I may have to do it 2-3 times to make sure my packet isn't getting dropped. Yes, there are a lot of other factors that will kill performance and reliability, but this is all going to happen when the player is playing single player. And once it works, the port gets saved and it never has to execute again.

None of that really matters though, because I've heard industry routers/switches will blacklist IP's that are "hacking" like this. Can anybody confirm this?