CODEWITHSUNDEEP
network-programmingudpp2pnathole-punching
tereby
tereby

Reputation: 11

P2P Networking under the each NAT

I'm doing some mobile project, that need to P2P communication with two devices.
And I faced with problem. (cause it's rare that smartphone have public ip)

I found some answers. It is 'UDP Hole Punching'.

I guess I understand about 'UDP Hole Punching' 100% conceptually, and write some codes. But it doesn't work.

This is my situation.

Device A connected NAT(A) for Wi-Fi.  
Device B connected NAT(B) for Wi-Fi.  
NAT(A) and NAT(B) is different one.  

Relay Server S bind socket and waiting for devices. (S is WebServer but Network Status is good.)  

At the first, A and B send dummy packet to S. Then S save UniqueID(to tell A and B), Public IP, Port.  

And S send information to each device A and B.   

Like this:  
 - IP Address and Port Number about A. -> send to B  
 - IP Address and Port Number about B. -> send to A  

Now A and B send UDP packet to other device based on information(IP Address and Port Number) from S.  
(15 per second. using same socket that used server-device session)

But it's not working. (actually intermittently work. maybe once in 10 times? and I don't know why success and fail. there is no any tiny little common relation.)

I think it's not NAT Type problems. I tested South Korea and 90% NAT in South Korea is not Symmetric Cone.

Upvotes: 1

Views: 680

Answers (1)

SDwarfs
SDwarfs

Reputation: 3239

  1. Depending on the implementation of the NAT, it may not work at all. NAT hole punching requires, some special form of NAT implementation: a) If the NAT recognizes UDP traffic it may (but some times does not) NAT-translate by changing the sender port number to some random port number (and changing the sender IP to the public IP address) and then redirects -for some limited period of time- incoming UDP traffic on that port back to the host behind the NAT (changing back the port number and changing the receiver IP). That's where it works. b) Another possibility is, that the NAT does redirect only traffic from special host to that opened port to the host behind the NAT. That is where it will not work. c) It's not standardized what "refreshes" the timeout for the incoming traffic rule. The timeout may be prolonged by incoming traffic. But it may be needed to have outgoing traffic to the same host (Server S) to prolong the timeout.

  2. It also seems UDP state expires very quickly for some implementations (within 100 ms in some cases). This means, you'll either need to continue to send keep alive packets to your Server 'S' -OR- you need at least to send UDP packets in shorter periods than 100 ms (e.g. once every 50 ms or 20 ms).

Upvotes: 1

Related Questions