Hi I am slightly confused on how UDP Hole Punching works and how I would implement it. According to this wikipedia article: https://en.m.wikipedia.org/wiki/UDP_hole_punching#Flow Both the clients that want to establish a p2p connection must set up a UDP conversation with the server in order to exchange ip's and punch holes. What I am confused on is lets say client a wants to initiate a p2p conversation with client b. How would client b know to connect to the sever in order for the clients to swap ip's? This is required else they would not know the other clients ip. Am I misunderstanding this concept somehow?
0
votes
The clients both need to know how to contact the server (somehow), and both clients need to contact the server in advance so that the server can know that they are running.
– Jeremy Friesner
So should I store each client that exist in the application's public ip and update it periodically? So that each time one client wants to communicate with another client it will just grab from the server the client's ip they want to communicate with? Sorry I am new to this stuff.
– user7501172
One way to do it would be to have each client ping the server (via UDP packet or TCP connection) periodically, and whenever the server receives this ping-message it should store the source IP address (as returned by recvfrom() or getpeername() on the server) in a local data structure, along with any identifying information the client wants to include in the ping-data. Then whenever another client queries the server for client-location-information, the server will (hopefully) have that info available to send to the client.
– Jeremy Friesner
I was thinking something similar. Thank you for the help.
– user7501172
1 Answers
0
votes
In the regular case the peers do not have static IP addresses and also public ports are allocated dynamically with transient routing rules, valid for typically 1 to 3 minutes.
There is no way to guess the dynamic port of the dual peer and even there is no way to establish immediate routing to it without predefined forwarding rules.
In contrast to often transcribed documentation, the hole punching through router + internet service provider is actually done with sending UDP packets to a public mediator server.
The peers contact each other by re-using exactly the public ip/port currently seen by the mediator server.
The mediator server's router necessarily has a forwarding rule to the server, so the server is publicly reachable and a public communication can be initated.
If the mediator server does not have a static address, a public DNS server is required to resolve the server's dynamic address.
For trapping local port mapping and returning packets to the right target, all three nodes will maintain a mapping of a unique static node identifier to the current ip/port of incoming packets; each of the clients needs to send periodically alive message with client identifier to the mediator server and counterpart; the mediator server responds with an alive-acknowledge message carrying the mediator server's current public address/port. Here, optional port mapping rules of the routers are to be considered to get the actual public ports.
The dynamic adjustment of remote ports makes it difficult to have several independent communication channels, at least I'm not aware of a fork mechanism for UDP servers.
If there is a requirement for independent communication channels, e.g. like in FTP you have a command port and a streaming port, the packet protocol may be extended by a logical port and incoming packets may be dispatched according to the logical port.
Finally there are security risks:
1.) the communication could be hi-jacked, by anyone sniffing on any node of the routing path; he could send and alive message from a different address to one of the peers and so would inherit the peer's communication stream. The minimum solution here is to add authentication to the alive messages.
2.) Certainly, encryption is mandatory for user data in any public network! Due to uncertainty of delivery of UDP packets, encryption is just possible on packet base, as e.g. AES/ECB does, and so should be chosen strong.
