10 replies to this topic

[dpadam450]

So for a few months I decided to just re-route game data to a server with a static IP address because I could not get peer-to-peer working. Someone said it is 100% possible to do, so anyone that has a multiplayer game on android hook me up with some code or something. This is all with UDP.

I have: a static IP for a matchmaking server (in c++)
Right now I can send both clients data to the server, and the server will route those updates back to the other players. So all the game logic works.

This means I know the IP's of the two players phones, and I can send stuff over the network. However, I have a feeling that packets are getting dropped because when the players try to send to each other, without routing everything to the server, they come from a new address that the NAT does not know of.

My test:
If I run a 2nd program on the server that is bound to a new port, the phone will not receive ANY data from that new port so:
Client sends to server @ 111.1.1.2:8004
Server sends to client from 111.1.1.2:8004
Client gets a response.

A new program sends to client from 111.1.1.2:9004 << will not make it to the phone.
111.1.1.2:8004 will still make it to phone.

This is doesn't work while I'm connected to my wifi either. So I don't know why my router would be dropping those packets.

Edited by dpadam450, 16 June 2012 - 10:14 PM.

[hplus0603]

That's pretty normal for NAT gateways, and also for certain firewall configurations even if they don't actually translate the addresses. What you need is to use the first server as a NAT introducer for NAT punch-through.
I wrote a chapter in Game Programming Gems 5 about this. An earlier web article about the same thing is here:
http://www.mindcontrol.org/~hplus/nat-punch.html

[dpadam450]

I have read that and I have written a c++ game on windows with networking before, so I assume something about java sockets I am missing or something with android. I already have the introducer, these 2 players know their IP's, they use that same socket to send data to those IPs.

I read an hour ago that a udp sockets should be able to break a firewall as long as the socket did send a request to a specific IP, it should be able to receive data back from that specific IP and that throughout its lifetime it can continually switch who it sends to and that should update who it is allowed to receive from.

Other than that I'm about to strip down to a basic application and see what happens if it isn't something completely stupid.

Edited by dpadam450, 17 June 2012 - 03:52 PM.

[hplus0603]

I have read that

I read an hour ago that a udp sockets should be able to break a firewall as long as the socket did send a request to a specific IP

Given that that's the whole gist of NAT punch-through, I wonder how you got the punch-through to work before?

[dpadam450]

Well I guess my new router/modem or some other router/modem could be using symmetric NAT. But I don't know how you are going to be able to get peer to peer from that unless you can do some port prediction.

[dpadam450]

I think it may somehow be using a specific type of symmetric NAT and will verify.

[Rasterman]

I am working on punch through as I write this, I just got my introducer setup on a remote VPS today and started testing it out. I haven't tried it from 2 different machines in my network yet, but when I run both client and server on one machine it doesn't work. My question is if you are connecting a server and client that are from the same IP (as seen by the introducer) should the introducer tell them to use their local IPs rather than try connecting via their external IPs (which are the same)? I didn't think using local IPs would work even if both client and server have the same external IP as can't you have multiple NAT layers?

Edited by Rasterman, 18 June 2012 - 10:56 PM.

[jefferytitan]

I am working on punch through as I write this, I just got my introducer setup on a remote VPS today and started testing it out. I haven't tried it from 2 different machines in my network yet, but when I run both client and server on one machine it doesn't work. My question is if you are connecting a server and client that are from the same IP (as seen by the introducer) should the introducer tell them to use their local IPs rather than try connecting via their external IPs (which are the same)? I didn't think using local IPs would work even if both client and server have the same external IP as can't you have multiple NAT layers?

I recall reading (possibly from hplus's article) that NAT punching works fine if they are across the net, can be made to work fine if they are on the same network, but often fail if on the same side of the net but different networks because there is no way either party or the server can know what IP address they will be visible to each other as.

[Rasterman]

Thanks for the info, after sleeping on it though I discovered an error in my implementation. When doing the punch through I was creating a new socket for each punch message being sent, which obviously wasn't using the correct port to connect back on. After I updated my code to use the same port as I establish the connection on it worked even from the same machine from behind the same IP, so I guess my router can punch itself!

Edited by Rasterman, 19 June 2012 - 08:44 AM.

[dpadam450]

FYI, for my router/modem I can't match-make players on the same machine. They will not work unless I send to 192.168.0.1:player_port, if I send to my routers global IP, then they will not receive each others messages.

The new system I'm doing is hole-punching that way it covers more options of NAT's
Open 3 ports:
A - port 12000
B - port 12001
C - port 12002

A -> contact server , server sees NAT port 32490
B-> contact server , server seets NAT port 32495

Server knows now that port C must bee 32500 (each new port is the previous port + 5).

So when matchmaking, the server tells each player what the port C of both players should be, by sending a reply to each players A port. Since those ports C have never sent anything, their first request/send will be to each others port C and therefore you break through.

Edited by dpadam450, 19 June 2012 - 02:32 PM.

[hplus0603]

FYI, for my router/modem I can't match-make players on the same machine.

This means that your router doesn't support "hair-pin" NAT.

Your server can detect when two players are behind the same NAT (from the same source IP from the server's point of view,) and tell them to try a local match-up. Either have the client provide the local IP address it's on, or use UDP broadcast to find the other player locally.