I want to be able to create a game which lets users become the server, and their friends connect to it. I do not want to provide a permanent host myself, but i will do if this resolves the following issue:

The problem I'm having is that it requires the host guy to forward/unblock their ports. This isn't very ideal since some people don't know how to do this. I suppose I could use a "public port"? such as 8080, but wont that affect other programs using that port?

I'm using TCP/IP winsock 2 in c++

I know that some games get away without requiring port forwarding, how on earth do they do this? I have read the FAQ posted here and the only idea I could get from it was some sort of NAT punch through, but I'm not too sure what that is

You are correct that you need NAT punch-through to get through residential NAT routers, if you don't want to require port forwarding.

You can read about it in <a href='http://www.mindcontrol.org/~hplus/nat-punch.html'>my article on NAT punch-through</a> or in the chapter about the same thing in Game Programming Gems 5. You can also google for other resources.

Note that NAT punch-through generally works best for UDP networking, but the theory also works fine for TCP connections using "simultaneous open." In practice, that's less often actually successful than UDP, though, depending on implementation specifics of residential NAT routers.

Thanks hplus0603, I read that article last night annd it was a good read. Just a quick question- if you successfully do the NAT punch-through with UDP, can you then successfully connect with TCP without the need of using TCP NAt punch-through?

Would you need to explicitly bind the peer-to-peer socket prior to transmitting for this?

IOW -

Clients with to server using local IP and ephemeral local port.

Server tells clients about one another.

Clients drops server connection and explicitly bind a new socket to the local port that was ephemerally selected by connecting to the server.

Clients toss packets at one another until they get a response from the other indicating punch-through success.

if you successfully do the NAT punch-through with UDP, can you then successfully connect with TCP without the need of using TCP NAt punch-through?

Not necessarily. UDP punch-through support is reported as more widely supported than TCP punch-through support, both in firewall devices, and in operating systems (although you need to go back pretty far in Windows versions to not see simultaneous-open support at this point.)

In general, UDP port numbers, and TCP port numbers, are totally unrelated -- they're like house numbers on different streets. Just because there's a McDonald's at 1234 UDP Street, doesn't mean there's necessarily another McDonald's at 1234 TCP street :-)

Would you need to explicitly bind the peer-to-peer socket prior to transmitting for this?

For UDP, no, as you can re-use the same socket for all connections. For TCP, yes, as you need one socket per connection, and all the sockets using punch-through need to use the same local port. You also need to turn on SO_REUSEADDR before doing that binding.

Would you need to explicitly bind the peer-to-peer socket prior to transmitting for this?

For UDP, no, as you can re-use the same socket for all connections. For TCP, yes, as you need one socket per connection, and all the sockets using punch-through need to use the same local port. You also need to turn on SO_REUSEADDR before doing that binding.

Ah, that's what I meant, yes. I should have been more clear. So punch-through for TCP would get a little complicated... Maybe it would help to launch a flurry of spurious initial packets (using a raw socket) prior to attempting the actual connection?

Maybe it would help to launch a flurry of spurious initial packets (using a raw socket) prior to attempting the actual connection?

Unlikely. What you want to do is set the TTL low (say, to 2) and ramp it up 1 at a time while trying to connect, to make sure you get your packet out of your firewall before the other end gets its packet to your firewall, as some firewalls will blacklist incoming connection attempts and an outgoing connection attempt won't remove that blacklisting.

Ouch.