NATs

In order to ensure anonymity in Web3 social networking and provide users with convenient social tools, INTO has built a decentralized private chat tool based on UDP technology, while providing rich functions and supporting various rich media. The technical principles are as follows:

A. The clients are behind different NATs

Assuming that the addresses of client A and client B are both intranet addresses and follow different NATs. A. The P2P application running on B and server S both use UDP port 1234. A and B respectively initialize UDP communication with the server, and the address mapping is shown in the figure:

Now let's assume that client A intends to directly establish a UDP communication session with client B. If A sends UDP data directly to B's public address 138.76.29.7:31000, NAT B is likely to ignore the incoming data (unless it is a Full Cone NAT), as the source address and port do not Match S and only established a session with S. Sending messages directly from B to A is similar. Assuming A starts sending UDP data to B's public address while sending a relay request to server S, requiring B to start sending UDP information to A's public address. The output information from A to B will cause NAT A to open a new communication session between A's internal network address，and B's external network address, and the same applies to B to A. Once a new UDP session is opened in both directions, client A and client B can communicate directly without having to boot server S. UDP hole punching technology has many useful properties. Once a P2P link is established, both sides of the link can act as a "guiding server" to assist clients behind other middleware in drilling holes, greatly reducing the server's load. The application does not need to know what middleware is (if any), as the above process can also establish communication links without middleware or with multiple middleware.

B. The clients are behind the same NAT

Now consider a scenario where two clients A and B happen to be behind the same NAT (and may not be aware of it themselves), so they are within the same intranet segment. Client A and server S have established a UDP session, and NAT has allocated public port 62000 for this. B has also established a session with S and assigned it to port 62001, as shown in the following figure:

Suppose A and B use the UDP hole punching technology described in the previous section to establish a P2P path, what will happen?

Firstly, A and B will obtain the other party's public IP and port number observed by S, and then send information to the other party's address. The two clients can only communicate normally when NAT allows internal hosts to initiate UDP sessions with other internal hosts, We refer to this situation as ‘look back translation’ because data arriving at NAT from within is 'looped back' to the internal network instead of being forwarded to the external network.

For example, when A sends a UDP packet to B's public address, the packet's original source IP address and port address are 10.0.0.1:1234, and the destination address is 155.99.25.11:62001. After NAT receives the packet, it converts it to source 155.99.25.11:62000 (A's public address) and purpose 10.1.1.3:1234, and then forwards it to B. Even if NAT supports loopback transmission, such conversion and forwarding are not necessary in this situation, and may increase the conversation delay between A and B and increase the burden on NAT.

The solution to this problem is very intuitive. When A and B initially exchange address information through S, they should include their own IP address and port number (from their own perspective), as well as their own address and port number from the server. Then the client simultaneously starts sending data to each other from two addresses known to the other party and uses the first successfully communicated address as the other party's address. If two clients are in the same NAT, the data is sent to the other party's internal network segments