Jump to content

  • Log In with Google      Sign In   
  • Create Account


Client/Server model without port forwarding


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 rukiruki   Members   -  Reputation: 161

Like
0Likes
Like

Posted 10 July 2013 - 07:31 PM

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



Sponsor:

#2 hplus0603   Moderators   -  Reputation: 4955

Like
1Likes
Like

Posted 10 July 2013 - 09:22 PM

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.


Edited by hplus0603, 10 July 2013 - 09:23 PM.

enum Bool { True, False, FileNotFound };

#3 rukiruki   Members   -  Reputation: 161

Like
0Likes
Like

Posted 11 July 2013 - 03:26 PM

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?



#4 Khatharr   Crossbones+   -  Reputation: 2817

Like
0Likes
Like

Posted 11 July 2013 - 08:32 PM

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.


void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#5 hplus0603   Moderators   -  Reputation: 4955

Like
0Likes
Like

Posted 12 July 2013 - 10:12 AM

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.
enum Bool { True, False, FileNotFound };

#6 Khatharr   Crossbones+   -  Reputation: 2817

Like
0Likes
Like

Posted 12 July 2013 - 03:21 PM



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?


void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

#7 hplus0603   Moderators   -  Reputation: 4955

Like
0Likes
Like

Posted 12 July 2013 - 11:06 PM

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.
enum Bool { True, False, FileNotFound };

#8 Khatharr   Crossbones+   -  Reputation: 2817

Like
0Likes
Like

Posted 13 July 2013 - 04:45 PM

Ouch.


void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS