Blargh, darn the routers.. I have some network code known as MTUDP, from some game code book or something.. Anyway, I completely stole it and integrated it into my game, changing some interface stuff around slightly. So, it's pretty stable code for UDP networking, supporting reliable and unreliable packets, host management, some other features... Anyway, I have a game, a game server, and a lobby server. One problem I have is where the game server can get a message through to the lobby, because it directly specifies the IP address. The lobby receives the message, but cannot get a message back to the game server, I'm guessing because the router is messing up the IP that the lobby gets, or something. So, I'm guessing my lobby server needs to not be behind a router.. and then.. some other issues will obvously show up... blah.. Anyone have any info or articles related to this that they think might be helpful? I'm not asking for specific help yet, not until I can do some more testing and figure out if I need to change anything.. Thanks!

N0ob,

I've been experiencing the same thing with my server when it comes to clients connecting remotely and as of yet have not managed to recify this. I know what code you are referring to because I own that book myself but it doesn't address certain issues such as this.

I was actually wondering the other day why my Quake III server always worked while behind a firewall, but it's because the master server keeps track of the external port and address when calling recvfrom() (this is a wild guess but I'm pretty sure I'm right on this) and stores it off. The problem you're experiencing is that you're trying to send to the internal port which is behind the firewall, not the external exposed address which is the one you want to hit.

I'll search around for articles once I'm off work since you're not looking for help so much now as articles but I'd look into using recvfrom() no matter what, particularly when using UDP. In this way you can store off the server's external port and address (as far as the router is concerned) and it will handle routing it back to the internal client (in this case the server). One thing to keep in mind as well is that certain routers will translate the port every x minutes either after a period of inactivity or simply because it feels like it which is something else you might need to take into consideration. Natrually, this is all assuming you're using UDP, I don't use TCP personally so don't really have much to add when it comes to that subject.

I apologise ahead of time if this reply has nothing to do with what you asked, I had some difficulty understanding parts of your post as they just seemed to run together (and I'm in a rush being at work and all ^_^).

Permafried-

essentially, in simpler terms the algorithm for getting around routers/firewalls/etc is this:

open a connection from inside the router/firewall/etc to an external server with a public & static IP address. the machine inside the router is the client, the machine with the static IP is the server. you then keep the connection open and use that to ferry your data. should the server require additional connections, you pass a message down the already open connection and the client opens a new connection to the server (probably by sending an initiation message that lets the server know that this is the connection it requested). if the client loses connection to the server, it is obviously the clients responsibility to re-establish the connection since the server can't open connections to the client. if you want a nice solid connection status, you can have timeouts on clients on the server side such that even in the event of a loss of connection, the client is not immediately considered 'disconnected' (basically you give them enough time to try and re-establish a connection).

basically, for a nice online gaming experience you need at least one machine that has a static and public IP address. this machine can then act as a bridge between clients that are behind their respective routers/firewalls. you cannot connect 2 machines that are both behind firewalls/routers, unless there is specific stuff done with the configuration of the router/firewall to allow traffic on specific ports to reach a specific client machine (but you can't do that programatically, it has to be done by the router/firewall admin).

-me

Is there any way to send the messages directly? I realise that a 3rd party server is always necessary - but are the messages themselves directly p2p or must they be bounced off the server? How do they do it for direct p2p IM systems that tend to work behind a firewall.

Or is it simply that the open socket is hijacked by the other client?

Once you have gotten matchmaking and introduction working, the messages after that are strictly p2p without bouncing through your static-IP server.

More information here.

I've been sitting here pondering just why you can't do p2p if both clients are behind routers... and then I think i realized that this is assuming there is no port-forwarding (for some reason i was thinking that it was still not possible, even with port forwarding). So, you don't need the third machine if one or both are using port forwarding..? Am I right?

When you say "router" I presume you mean network address translating box or internet connection sharing device. The Internet is full of routers, all servers are behind routers.

If you use port forwarding for a specific port, then your forwarded-to device will look like it's on the public internet, and NAT punch-through need not apply. However, most regular consumers don't know how to port forward, or don't want to bother, or may even be behind devices that don't allow port forwarding configuration. In fact, some ISPs will give you a NAT-ed IP that's not even public!

Some NAT routers must initiate the outgoing connection to create the appropriate mapping, so that not even non-NAT hosts with static IPs and good credentials can connect to them. In that case, the first peer must always establish the connection, or at least "unlock" the NAT when notified by a 3rd party matchmaker.

I've written a few documents on the process:

Types of NAT
Detecting NAT
Coping with NAT

Good luck.