How to play the principle of peer

Transferred from: http://blog.pfan.cn/fengfei/18828.html

First introduce some basic concepts:
NAT (Network Address
translators), network address translation: Network address translation is a growing lack of IP address in the case of the production, its main purpose is to be able to address reuse. Nat is divided into two main classes, the basic NAT and NAPT (Network
Address/port Translator).
The first NAT is a functional module that runs on the router.

The first proposed is the basic NAT, which is based on the fact that only a small number of nodes in a private network (domain) need to be connected to an external network (hehe, which was proposed in the middle of the 90 century). Then there are only a few nodes in this subnet that require the world's only IP address, and the IP addresses of the other nodes should be reusable.
Therefore, the basic NAT implementation of the function is very simple, in the subnet using a reserved IP subnet segment, these IP is not visible to the outside. Only a few IP addresses in the subnet can correspond to truly global unique IP addresses. If these nodes require access to an external network, then basic NAT is responsible for translating the subnet IP of the node into a globally unique IP and sending it out. (Basic NAT changes the original IP address in the IP packet, but does not change the port in the IP packet)
Refer to RFC 1631 for basic NAT

Another kind of NAT is called NAPT, and from the name we can see that napt not only changes the IP address of the IP datagram that passes through the NAT device, but also changes the TCP/UDP port of the IP datagram. Basic NAT Device Maybe we don't see much (hehe, I haven't seen it), Napt is the protagonist of our real discussion. See:
Server S1
18.181.0.31:1235
|
^ Session 1 (a-s1) ^ |
| 18.181.0.31:1235 | |
V 155.99.25.11:62000 v |
|
Nat
155.99.25.11
|
^ Session 1 (a-s1) ^ |
| 18.181.0.31:1235 | |
V 10.0.0.1:1234 v |
|
Client A
10.0.0.1:1234
There is a private network 10.*.*.*,client
A is one of the computers, the network gateway (a NAT device) of the external network IP is 155.99.25.11 (there should be an intranet IP address, such as 10.0.0.10). If the client
A process in a (this process creates a UDP
Socket, this socket bound 1234 port) want to access the external host 18.181.0.31 1235 port, then what happens when the packet passes NAT?
First NAT will change the original IP address of this packet, instead 155.99.25.11. Nat then creates a session for the transfer (the session is an abstract concept, and if it is TCP, perhaps the session is started by a SYN packet and ended with a fin packet.) And UDP, with this IP port of the first UDP start, the end, hehe, maybe a few minutes, maybe a few hours, this depends on the specific implementation of the session and assign a port, such as 62000, and then change the packet source port is 62000. So it was (10.0.0.1:1234->18.181.0.31:1235) that the packet was turned into the internet (155.99.25.11:62000->18.181.0.31:1235).
Once Nat has created a session, Nat remembers that port 62000 corresponds to port 1234 of 10.0.0.1, and data sent from 18.181.0.31 to Port 62000 will be automatically forwarded to 10.0.0.1 by Nat. (Note: This is to say that the data sent to port 62000 will be forwarded, the other IP data sent to the port will be 18.181.0.31 by NAT) so the client
A is established with the server S1 as a connection.

Hehe, the above basic knowledge may be a lot of people know, then the following is the key part.
Take a look at the following scenario:
Server S1 Server S2
18.181.0.31:1235 138.76.29.7:1235
| |
| |
+----------------------+----------------------+
|
^ Session 1 (a-s1) ^ | ^ Session 2 (a-s2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
V 155.99.25.11:62000 v | V 155.99.25.11:62000 V
|
Cone NAT
155.99.25.11
|
^ Session 1 (a-s1) ^ | ^ Session 2 (a-s2) ^
| 18.181.0.31:1235 | | | 138.76.29.7:1235 |
V 10.0.0.1:1234 v | V 10.0.0.1:1234 V
|
Client A
10.0.0.1:1234
In the example above, if the original Socket of client A (the UDP socket that is bound to port 1234) goes to another server
S2 sends a UDP packet, what happens when this UDP packet passes through NAT?
There may be two situations where NAT creates a session again and assigns a port number to the session again (for example: 62001). The other is that NAT creates a session again, but does not assign a new port number, but instead uses the originally assigned port number 62000. The first kind of NAT is called symmetric
NAT, the latter called Cone.
Nat. We expect that our NAT is the second, hehe, if your NAT happens to be the first one, then there is likely to be a lot of peer software failure. (Fortunately, the vast majority of Nat now belongs to the latter, namely cone
NAT)

            Well, we see that with NAT, it's easy to connect a computer to a subnet (NAT is equivalent to Transparent, Subnets and extranet computers do not need to know the NAT situation.
            However, it is difficult for an external computer to access computers within the subnet (which is what peer-to-peer needs).
            So if we want to send a datagram from outside to the intranet computer, what's the way? First of all, we have to play a "hole" in the NAT on the intranet (that is, we said in a NAT on a session), this hole can not be played by the outside, can only be played by the host inside the intranet. And this hole is a direction, such as from the inside of a host (such as: 192.168.0.10) to an external IP (such as: 219.237.60.1) to send a UDP packet, then in this intranet NAT device to play a direction for the 219.237.60.1 "hole", (this is called udp 
            hole 
             Punching technology) after 219.237.60.1 can be through this hole and the intranet 192.168.0.10 contact. (But other IPs cannot take advantage of this hole).

            Oh, now it's our turn to peer. With the above theory, the implementation of the two intranet host communication is the last step: that is the chicken eggs or eggs, the problem of chicken, both sides can not initiate the connection request, who do not know who's public address, then how can we hit this hole? We need an intermediary to contact the two intranet hosts.
            Now let's take a look at the process of one-peer software, for example:

            Server S (219.237.60.1)
             |
            |
            +----------------------+---------------- ------+
            | |
            Nat A (extranet ip:202.187.45.3) NAT B (extranet IP : 187.34.1.56)
            | (Intranet ip:192.168.0.1) | (intranet ip:192.168.0.1)
            | |
            Client A (192.168.0.20:4000) client B ( 192.168.0.10:40000)

First, client a logs on to the server, and NAT a allocates a port of 60000 for this session, so the client that server s receives
The address of A is 202.187.45.3:60000, which is the extranet address of client A. Similarly, Client b logs on to server S,nat
b The port assigned to this session is 40000, then the address of B received by Server S is 187.34.1.56:40000.
At this point, both client A and client B can communicate with server S. If client a wants to send the message directly to the client at this time
b, then he can get B's public address 187.34.1.56:40000 from server S, is not the client
A send a message to this address client B will be able to receive it? The answer is no, because if you send this message, NAT
B will discard this information (because such information is unsolicited, and for security purposes, most NAT will execute the discard action). What we need now is a NAT.
B hit a hole in the direction of 202.187.45.3 (that is, client A's extranet address), then the client
A send the message to 187.34.1.56:40000, and Client B will receive it. Who will send this hole command, hehe, of course, the server S.
Summarize this process: If client A wants to send a message to client B, then client a sends a command to server S, requesting the server
s command Client B to client
A hole in the direction. Oh, is not very around the mouth, but it doesn't matter, think about it is very clear, let alone the source code it (Hou teacher said: No secret in front of the source code
8), then client a can communicate with Client B via the client B's extranet address.

Note: The above procedure is only suitable for cone NAT, if it is symmetric NAT, then client B to the client
A hole port has been reassigned, and Client B will not be able to know the port (if symmetric
NAT ports are assigned sequentially, so we might be able to guess the port number, but we don't recommend this method of guessing the port because there are too many factors that could lead to failure.

Another article connected to:

Here's an explanation of what I don't think is missing in the above article.
Private address/port and public address/port: We know that most networks now use NAPT (Network Address/port Translator), which is the function of an external dialogue after the NAT IP address and port number will be rewritten, In this case, the IP address and port number that the client considers to be used in a session are private addresses/ports, and the IP address and port number that have been rewritten after NAPT is called public address/ports. Or you can understand that the private address/port is your family nickname and public address/ The port is your truly public name. How to get the user's private address/port number, this is very simple, and to get the public address/port number will be connected to another machine by the machine to see the IP address and port number to represent.

If you understand what's above, enter our code below and explain the implementation of the key section here:

The client first obtains its own private address/terminal, then sends the login request to the server side, the server side can know this client's public address/terminal after obtaining this request, the server will save their private address for each logged-in client Port and public address/port.

              OK, the key punch-hole process starts below. Suppose client  A to talk to Client b, but a does not know the address of B, even if it is understood that the principle of NAT will be rejected for the first time, because Client b NAT considers this to be a request from an external sender. This time, A If you find that you did not save the address of B, or the session request sent to B failed, it will ask the server side to let B to a hole, the b->a session meaning that it makes nat b think a address/port is the address/port that can be passed, This will not be rejected by Nat b again when a conversation is sent to B. An analogy to explain the hole in the process, a want to B home, but by the butler Nat b of B refused, the reason is: I never listen to my family B mentioned your name, when a found a, b all know the friend server, asked the server to give a letter to B, let B to tell the housekeeper that a is my friend, so, B and Butler Nat b said, A is I know friend, so A's visit request will not be the housekeeper Nat b refused. In short, A UDP hole is a process that is saved by the server so that it can communicate directly with each other, and the server helps to establish the connection, which is no longer involved after the establishment of the indirect.

The following is a simulation of the process of peer chat source code, the process is very simple, p2pserver run on a computer with a public IP, p2pclient run after two different NAT (note that if two clients run on a NAT, this program will probably not run properly, It depends on whether your NAT supports loopback.
Translation, see Http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt, of course, this problem can be resolved by both parties to first try to connect to each other's intranet IP, But this code just to verify the principle, and did not deal with these problems), after the computer can be logged on to the computer to get the user name, after logging on to the computer through send
The username message is sent in the format. If sent successfully, you have made a successful connection directly with the other party.
The program now supports three commands: Send, Getu, exit

Send format: Send username message
Function: Send message to Username

Getu format: Getu
function: Get a list of current server users

Exit Format: Exit
Function: Log off the connection to the server (the server does not automatically monitor whether the customer is hanging wire)

Code is very short, I believe it is easy to understand, if there is any problem, you can send me e-mail [email protected]
or send a short message on the CSDN. At the same time, please forward this article, but want to retain the author Copyright 8-).
_05/04052509317298.rar "
Http://www.ppcn.net/upload/2004_05/04052509317298.rar

Another introduction to hole-punching technology (supplemental)

UDP hole technology relies on the public firewall and cone NAT, allowing appropriate, planned end-to-end applications to "punch holes" through NAT, even when both hosts are behind Nat. This technique is highlighted in section 5.1 [NAT PROT] of RFC3027 and informally described in Internet[kegel], and is also applied to some of the most recent protocols, such as the [Teredo,ice] protocol. However, we should note that the "technique" as its name, the reliability of the UDP hole technology is all dependent on UDP.
Here are two typical scenarios that describe how connected applications communicate on a planned basis, the first scenario where we assume that two clients are behind a different NAT, and the second scenario, we assume that two clients are behind the same NAT, but they don't know each other ( They are in the same NAT).



Client communication after a different NAT

We assume that both client A and client B have their own private IP addresses, and that after the different NAT, the end-to-end programs run between the client A,client B,s, and they both open UDP port 1234. Client A and Client B first establish a communication session with S, where Nat a assigns its own UDP port 62000 to client A and S, and Nat B assigns its own UDP port 31000 to the session of client B and S.

If client a wants to establish a UDP direct connection with client B at this time, if client a simply sends a UDP message to the public address of client B 138.76.29.7:31000, NAT B will discard this information without consideration (unless NAT B is a full cone NAT) because the address information contained in this UDP message does not match the address information of server s that is stored in NAT b when client B and server s establish a connection. Similarly, if CLIENT B does the same thing, the UDP message sent is also discarded by NAT A.

If client a starts sending a UDP message to the public address of client B, at the same time, he sends an invitation message to client B via s relay, requesting that Client B also sends a UDP message to client A on the public address of client A. The information sent by client A to client B's public IP (138.76.29.7:31000) causes NAT A to open a new communication session between the private address of client A and the public address of client B, while Nat B A new communication session is also opened between the private address of client B and the public network address of Client A (155.99.25.11:62000). Once the new UDP session is opened to each other, client A and client B can communicate directly, without having to matchmaking with S. (This is called the hole-punching technology)!

How to play the principle of peer