The following is an important term called Nat.
Nat is short for net address translation (Network Address Translation). That is to say, a LAN is usually connected to Internet shared access through a proxy gateway server with a public IP address. The machine in the LAN does not have a public IP address. It only has an intranet address. If it wants to communicate with the HTTP server on the Internet, the Proxy Gateway creates a port to associate with the machine in the LAN, and exchange data with the HTTP server through this port. In the end, the Intranet machine-> Proxy gateway-> HTTP server maintains a ing relationship between the respective ports during a session, especially the port ing between the Proxy gateway and the Intranet machine, so that the Proxy gateway does not forward the received data to the network, the machine is wrong.
In the gateway, machines in the LAN map ports and connect to the Internet through NAT. Therefore, Nat is also called "port ing ". After port ing, it is maintained during a session. For TCP connections, they are not destroyed until the connection is disconnected, but for UDP, there is an indefinite lifetime, for example, 2 seconds.
If two machines A and B are in two local networks, they need to communicate over the Internet, which is P2P (point-to-point) connection communication.
Currently, the Internet uses the IPv4 protocol and 32-bit IP addresses, which are mainly used for C/S-form communication. resources to be shared are concentrated on Internet servers. IPv4 is extremely unfriendly to support P2P distributed resource sharing. First, the 32-bit IP address is not enough, and the public IP address is getting increasingly tight. You can only use the LAN to share the public IP address. The LAN is designed to temporarily cope with IP depletion, the long-term solution is to study IPv6. Second, machines in two local networks need to communicate with each other. Since the other party does not have a public IP address, it is impossible to directly call the other party. Therefore, it is necessary to use a third-party "intermediary" (machine or software) to indirectly connect, solutions:
First, the implementation of the data link layer protocol in the LAN is to write a protocol similar to TCP/IP, which replaces the TCP/IP protocol in windows, it directly obtains data based on the network card hardware. This is very complicated.
Second, the Internet server is used for data transfer, but the transfer of large data volumes is obviously restricted by the load limit of servers and networks.
Third, relying on Internet servers as "matchmakers", the two machines in different LAN are introduced to each other. After they establish a connection, the servers are separated from each other. In this way, the server tells the NAT port ing relationship of a to B, and the NAT port ing relationship of B to A, so that AB knows each other's port ing relationship, you can establish a connection. Because the port ing between A and B is dynamically established by their respective proxy gateways, the dynamically established ing port has to be notified to the other party.
Fourth: the third method above can also adopt static port ing, so that the intermediary server does not need to introduce a and B. On the proxy gateways of all parties, you can perform static ing between a port (such as 1350) and a machine (such as the Intranet IP address 200.200.200.100 and port 1360) on the proxy tool, in this way, the proxy gateway automatically sends data from Port 1350 to port 1360 of port 200.200.200.100. Before communication, you must configure the port ing relationship of the other party. How many machines in the network need to communicate, and how many different ports need to be mapped, and how many configurations are required for machines in the other LAN. Setting up HTTP, FTP, and other servers in the LAN is achieved through static ing ports, which are generally not the default ports 80 and 23 for HTTP and FTP, therefore, accesses to such sites often include port numbers in URLs.
It can be seen that the first two methods are not desirable in simple applications, but the last two methods are feasible. They also have their own shortcomings. The third type of dynamic ing port requires an intermediate server, and the fourth type of static ing port. In the case that many machines need to communicate, manual port ing and configuration are cumbersome. When one party adds a machine, it needs to add configuration to the other party.
The combination of dynamic and static methods can be inferred, but its feasibility must be tested. It can be designed in this way to let all communication machines know and locate each other. We can perform static port ing on only one machine in the LAN at the Proxy gateway, and all the machines in the LAN are registered with it. The two local networks have only one ing configuration for each other. To communicate with machines that do not have static ing ports between two LAN networks, the machines with ing are used as "Introduction ".
There are still many problems with lan and Nat. For example, if the structure of the LAN is different, there may be a sub-lan in the LAN. The Lan may be a NAT proxy structure, but it may also be an HTTP proxy, sock4, sock5 proxy and other structures, Nat is divided into strict and non-strict Nat, strict Nat restrictions, more difficult to P2P. However, you can consider changing the hardware structure, for example, changing strict Nat to non-strict Nat. If the hardware cannot be changed, 10% of Internet systems cannot implement P2P, unless the IPv6 protocol is being developed.
The only technical challenge to be solved by P2P is how to discover, locate, and address the other party, that is, how to penetrate NAT, HTTP, sock, and other proxies, and how to penetrate the firewall to find the other party and establish communication. Because most LAN networks use the NAT proxy structure, the previous Nat discussion is more detailed and the most discussed on the Internet. In contrast, it is easier to penetrate HTTP and sock proxies. In addition, there are still some ways to discover peer-to-peer through NAT, such as multicasting. However, because the existing Internet is unfriendly to multicasting, multicast is connectionless and unreliable, in fact, the current difficulty.
Many of the software is based on the above technologies to achieve P2P communication, the famous include MSN, QQ and BitTorrent download software.
In fact, many P2P protocols and Development kits have emerged for P2P communication, especially P2P communication between two different LAN networks. For example, sun's Java Development Kit JXTA, Microsoft has a P2P beta development kit on Windows XP platform, Intel announced. the P2P application development kit on the. NET platform is available at Microsoft. NET platform news site www.gotdotnet.com for users to download for free.
But they are used for development.ProgramIt is very cumbersome. We need to simply implement the function.
If you want to study more carefully, download the development kit from Sun's website and Microsoft website, or go to Google
Search protocols and sdks.
the following two instances describe the connection process, including the simple pseudo Code .
we do not want to implement P2P on the IP layer. Instead, we want to establish P2P on the application layer using the socket provided by windows, and write P2P using the raw socket at most.
first, let's look at how we implement "Intermediary (non-transit)" P2P for servers on the public network.
Principles:
For example, after the two AB machines are in two different LAN, the server acts as an intermediary and the connection process is checked first.
A first connects to the server and uses UDP to send packets to the server. This package includes user information of a, similar to QQ's
QQ number and nickname. Server side, you can use csocket: getpeername () to obtain the IP address and port of A, but the obtained IP address and port should be the public network publicip of A's proxy gateway and Its ing port natport, the ing port is the NAT port temporarily allocated by the Proxy gateway of A for this UDP communication. It can be asserted that the obtained port must not be a's intranet IP address or Intranet UDP port.
The server then saves a's public IP address, ing port, and user information to (memory list or database), marking that a has been launched. The server immediately sends other online user information to A, including the public IP address and Nat port of the proxy gateway of other users. A Also saves and displays the information of online users as a list, and expects user a to make a selection.
For B, the above launch process also exists.
When user a makes a choice and wants to communicate with online user B, user a first sends a UDP packet to the public IP address and Nat port of user B, and immediately sends a UDP packet to the server, ask the server to notify B and ask B to send a UDP packet to.
In other words, 1. A sends a packet to publicb, 2. A sends a packet to server, 3. server sends a packet to publicb, 4. B sends a packet to Publica.
The description above uses the word "public", which represents the public IP address of the proxy gateway and Its ing port.
Because the gateways of A and B both store their respective port ing relationships and send the data to the gateway, the gateway forwards the data to a and B According to the ing relationship.
When both A and B receive the UDP packets sent by the other party, the connection is declared successful, the server can be detached, and AB can be used for UDP communication.
Why is it so troublesome?
A's gateway (. a nat port (. natport) to a, used for this UDP session between A and server, but the gateway of a clearly marks that this Nat port can only be used for UDP communication between A and server, it cannot be used. In addition, the temporarily allocated port can only maintain a short validity period, maybe a second or two. If a does not communicate with the server during this period, the ing port is declared invalid. The next time a communicates with the server, the gateway of A allocates a new port. This section indicates three points:
1. for communication between A and server, Gateway A needs to allocate a NAT port for transit.
2. The Nat port can only be used for communication between server a and server.
3. The Nat port has a lifetime. If a does not communicate with the server for a long time, the port is declared invalid.
These troubles make the connection process much more difficult.
The communication between A and B refers to the port ing established at the respective gateways When AB is connected to the server separately. To avoid the trouble at and, A and B must send packets to each other almost simultaneously during the first connection.
If a and B send packets to the other party when they are different, their respective gateways will take into account the other party's package, because the package is not sent from the server, it is called an unsolicited package.
In addition, even if the gateways of AB do not consider packets sent from other servers, their respective Nat ports also have a validity period. Then a and server, B and server have to send heartbeat packets to maintain their respective ing ports and ensure that they do not expire.
In the above process, if the connection between A and B fails, you can loop through this process until a limited number of times, the connection fails. The original text of this article is as follows:
Clients behind different NATs
Suppose clients a and B both have private IP addresses and lie behind
Different network address translators. The peer-to-peer application
Running on clients A and B and on server s each use UDP port 1234.
And B have each initiated UDP communication sessions with server s,
Causing Nat a to assign its own public UDP port 62000 for a's session
With S, and causing Nat B to assign its port 31000 to B's session
With s, respectively.
Server s
18.181.0.31: 1234
|
|
+ ---------------------- +
|
Nat a NAT B
155.99.25.11: 62000 138.76.29.7: 31000
|
|
Client A client B
10.0.0.0.1: 1234 10.1.1.3: 1234
Now suppose that client a wants to establish a UDP Communication
Session directly with client B. If a simply starts sending UDP
Request to B's public address, 138.76.29.7: 31000, then Nat B will
Typically discard these incoming messages because the source address
And port number does not match those of S, with which the original
Outgoing session was established. Similarly, if B simply starts
Sending UDP requests to a's public address, then Nat a will discard
These messages.
Suppose a starts sending UDP requests to B's public address, however,
And simultaneously relays a request through Server s to B, asking B
To start sending UDP requests to a's public address. A's outgoing
Messages directed to B's Public Address (138.76.29.7: 31000) will
Cause Nat a to open up a new communication session between a's
Private address and B's public address. At the same time, B's
Messages to a's Public Address (155.99.25.11: 62000) will cause Nat B
To open up a new communication session between B's private address
And a's public address. Once the new UDP sessions have been opened
Up in each direction, Client A and B can communicate with each other
Directly without further reference to or burden on the "Introduction"
Server s
This is roughly the case. The following are some pseudocodes of the above process, which are not easy to understand. It is better to read the previous discussion.
Next we will discuss another method for sending packets simultaneously between A and B, as well as about static port ing, who can do "intermediary ",
Whether to establish TCP communication and other details and their extensions.
Const tchar * serverip = _ T ("61.10.10.10"); // The pre-configured
Const uint SERVERPORT = 4500; // The UDP port of the intermediary server, which is configured in advance
Tchar pubip [256]; // public IP address of the proxy gateway of the other machine
Uint pubport; // the public network ing port of the proxy gateway of the other machine
Uint clientport = 4501; // UDP ports of A and B
Connect to the server using UDP. below is the customer's (AB's socket)
Class cclientsocket: Public csocket
{
Public:
Virtual void onreceive (INT nerrcode );
}
Void cclientsocket: onreceive (INT nerrcode)
{
Int nflag, * PFLAG; // UDP packet flag, 4 bytes in the header
Tchar peerip [128]; // UDP peer IP Address
Uint peerport; // UDP Peer Port
Char recbuf [64]; // assume the package size is 64
// Analyze the peer IP address and port, namely, peerip and peerport.
Sockaddr SA;
Int sockaddrlen = sizeof (SA );
Getpeername (& SA, & sockaddrlen );
// Retrieve the peerip and peerport from the SA
Receive (recbuf, 64 );
PFLAG = (int *) recbuf;
Nflag = * PFLAG;
If (lstrcmp (peerip, serverip) = 0) // if it is the information returned by the server
{
Switch (nflag)
{
Case 0: // indicates that the connection to the server is successful. recbuf is another online user returned by the server.
// Information (including the peer public IP address and port), which is assumed to be B's Information
// Retrieve the IP address and port of the proxy gateway of B from recbuf and put it into the peerip and peerport.
Lstrcpy (pubip, peerip); // peerip should be the public IP address of the proxy gateway of the other party
Pubport = peerport; // At the same time, peerport should be the public network ing port of the proxy gateway of the other party
// Next, send a UDP packet to B's proxy public IP address, fill in recbuf, and set the flag to 0
Sendto (recbuf, 64, pubport, pubip );
// Call the server to notify B immediately. Ask B to send a UDP packet to a, fill in recbuf, and set the flag to 1.
Sendto (recbuf, 64, SERVERPORT, serverip );
Break;
Case 1: // indicates a notification from the server, asking me (B) to send a UDP packet to
// Recbuf contains the proxy public IP address and port A, which are obtained and put into the peerip and peerport.
Lstrcpy (pubip, peerip); // peerip should be the public IP address of the proxy gateway of the other party
Pubport = peerport; // At the same time, peerport should be the public network ing port of the proxy gateway of the other party
// Send a UDP packet to a, fill in the recbuf, and set the flag to 1
Sendto (recbuf, 64, pubport, pubip );
Break;
.
.
.
Default:
Break;
}
}
Else // information returned by other peer customers
{
Switch (nflag)
{
Case 0: // identify to directly receive a UDP packet
Break;
Case 1: // identifies the UDP packet sent back by B. However, it is sent by server notification B.
// At this point, we can determine whether AB is successfully connected to each other, that is, whether UDP packet B sent from A to B is received, and B is sent
// If the UDP packet a sent to a is also received, the connection is successful. Otherwise, repeat the preceding process.
Break;
.
.
.
Default:
Break;
}
}
}
The client first connects to the server. After receiving the message, the server returns information about all online peer users.
Cclientsocket Cs;
Char sbuf [64]; // The sbuf package ID is 0. You can fill in any other information, such as user information.
CS. Create (clientport, sock_dgram );
CS. sendto (sbuf, 64, SERVERPORT, serverip );
Class cserversocket: Public csocket
{
Public:
Virtual void onreceive (INT nerrcode );
}
Void cserversocket: onreceive (INT nerrcode)
{
Int nflag, * PFLAG; // UDP packet flag, 4 bytes in the header
Tchar peerip [128]; // UDP peer IP Address
Uint peerport; // UDP Peer Port
Char recbuf [64]; // assume the package size is 64
// Analyze the peer IP address and port, namely, peerip and peerport.
Sockaddr SA;
Int sockaddrlen = sizeof (SA );
Getpeername (& SA, & sockaddrlen );
// Retrieve the peerip and peerport from the SA
receive (recbuf, 64);
PFLAG = (int *) recbuf;
nflag = * PFLAG;
switch (nflag)
{< br> case 0: // identifies a customer connection
// returns all online users to the customer
break;
case 1: // for notifications from a, ask me to notify B, ask B to send a UDP packet to a's public IP address
// Extract B's IP address and port from recbuf and put it into peerip and peerport, fill in recbuf, flag: 1
sendto (recbuf, 64, peerport, peerip);
break;
}< BR >}