I am looking at it, I'm very bad, I'm not boring, I may see the original text.
My MSN: blovearch@hotmail.com
QQ: 27443675
I hope that there are some help to everyone, my purpose is to make friends with interest and programmers who are doing P2P, thank you for your support.
1. Introduction Today's Internet's "MiddleBoxes" has generally existed, such as network address translation (NAT), mainly because IPv4's address space consumption crisis is generated. However, asymmetric addressing and connection established by these "Middleboxes" has become a unique problem in point-to-peer (P2P) applications and protocols, including, for example, web phones and multiplayer online games. These topics may even continue to exist after using the IPv6 protocol, such as where NAT is often used as a compatible IPv4 mechanism [NAT-PT], and after NAT is no longer needed, the firewall will still exist (these issues).
The current development of "MiddleBoxes" initially plans to be used in the C / S structure, that is, those related anonymous clients actively go to connect to a fixed IP address and DNS domain name. Most "MiddleBoxes" achieve an asymmetric communication model, that is, hosts on private internal networks can communicate with hosts on public online, but external hosts on public networks cannot communicate with hostbox's. Managers are explicitly configured. In the usual case of NAPT, a client on the internal network does not have a unique unique IP address on the public network, but can share a public IP address as other clients on the same private network, and have NAPT management. These inside hosts that do not know the name and difficult access after a "middlebox" are not a problem for client software, such as web browsers, they need to connect out. Moreover, this kind of non-accessibility is sometimes considered to protect privacy.
However, in the application of point-to-point, the host on the Internet usually considers a call connection to the "customer" to establish direct and each other. The caller and the called must be behind different "middleboxes", both may not have any fixed IP addresses or other publication. For example, a usual online game architecture is to set some primitive values on the server that participates in the game to set some primary values on the server that everyone knows, and the use of the connection. Then, in order to have a more fast and effective game speed during the game, it is necessary to establish a connection directly to each other. Similarly, a shared file may allow a resource search engine that everyone knows or finds, but if file data is required, it is necessary to establish a direct connection with the host of the shared file. "MiddleBox" generates a problem when the point is connected. Because those behind "Middlebox" need to use TCP or UDP and other machine connections, there is usually no fixed-available public network ports. RFC 3235 [NAT-Appl] shows this problem, but no usual solution is provided.
In this document, we have 2 points on the P2P / Middlebox issue. First, we summarize known methods that P2P applications can work when MiddleBoxes exist. Second, we provide a set of application design guidelines based on these practices to make P2P more healthy in MiddleBoxes. Further, we provide the design guidelines to make future MiddleBoxes more efficient support support P2P applications. Our focus is to be able to penetrate Middleboxes to provide wider and more direct P2P applications.
2. Terminal In this chapter, we first briefly describe some "middlebox" terms. We focus on the two often lead to a Middlebox that causes problems in P2P applications. A firewall restricts private intranet and public Internet networks. Typically firewall is to discard those packets that it believe is unlicensed. When the packet traverses a firewall, it checks but does not modify the IP address and TCP / UDP port information in the package. Network Address Translation (NAT) When the data packet passes NAT, NAT not only checks the header information of the data, but also allows more hosts to share a few public IP addresses (usually only one) in NAT.
NAT usually has two main types: Basic Nat A Basic NAT maps an intrinsic private IP address to a public IP address, but does not replace its TCP / UDP port number when the data package passes through NAT. Basic Nat is usually only available on NAT with public IP address pools, which can be binded by it, ie, represents an internal host.
NetWork Address / Port Translator (NAPT), but most often, when the packet passes NAT, a NAPT checks and modifies its TCP / UDP port, then multiple intranet hosts can be shared with a separate public network IP. Address.
About NAT classification and terms, [NAT-TRAD] and [NAT-TERM] have more information. Additional terms for NAPTs in the future classification are defined in closer work [Stun]. When an internal host is tCP or UDP connection through a NAT and an external, NAPT assigns a public IP address and port to receive, interpret, and forwarded to the intranet. Host. This result is implemented by NAPT to establish a port binding between a (private IP address, private port), and (public IP address, public network port). During this period, NAPT performs address translation for the binded port. A problem with the P2P application is how Nat is operated when an internal host creates multiple connections from a private IP, a private port with multiple different hosts on the external network.
CONE NAT establishes a port, binds a (private IP, private port), and (public IP, common port), for application connection from the same private IP and port number, CONE NAT will reuse this binding port As long as there is a connection session, this binding port remains active. For example, in the following chart, it is desperative to establish two external sessions through a CONE NAT, from the same internal network terminal (10.0.0.1:1234) to 2 different external servers, S1 and S2. CONE NAT will only assign a public terminal, 155.99.25.11: 62000, will go to two sessions and ensure the consistency of the client port during address conversion. Basic Nat and firewall do not modify port numbers in packets in MiddleBox, which can be considered a special conne.
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:1234Symmetric NAT symmetrical NAT (Symmetric Nat), with CONE NAT, there is a significant difference in CONE NAT, and does not keep the binding (private IP, private port) and (public IP, public port) during all sessions . Instead, it will reassign a new public port for each new dialog. For example, it is envisioned that the customer A is connected to the same port to initiate two external dialogues, one and S1 connections, and the other and S2 connections. Symmetric NAT may assign a public endpoint 155.99.25.11:62000 for the first session, and assign a different public endpoint 155.99.25.11:62001 for the second session 155.99.25.11:62001. For address conversion, NAT can distinguish between the two session transmission purposes, because the external endpoints related to these sessions (S1, S2) are different, even lost the client's destination when converting through address transition. (Ie IP address NAT that is lost S1, S2 also knows how to distinguish, I understand so, maybe incorrect.)
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:62001 v | symmetric 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 | Clien T A 10.0.0.1:1234 The comparison between CONE NAT and SYMMETRIC NAT is similar to the TCP / UDP. (TCP needs to be bound, udp does not need, CONE NAT needs to be binded, Symmetric Nat does not need)
According to the NAT, the data restrictions received from known public IPs, public ports, and CONE NAT can classify more. This classification is usually UDP connections because NAT and firewalls will reject any conditional TCP connection unless it is clearly configured otherwise.
Full Cone Nat has established a public / private port binding to a new external session, a Full Cone NAT can receive data communication from any external endpoint on the public port through this public port. Full Cone Nat is often called "mixed" NAT.
Restricted CONE NAT When the network host sends one or several packets to the external host, a limited CONE NAT (RESTRICTED CONE NAT) receives a packet from this external (source) IP address. The limited CONE NAT effectively uses the principle of the firewall, refuses that there is no required data, and only receives the data from the external IP address. (By the original text, great ideas is that the network host needs to send a request to the external IP address to require data, and NAT will receive the data from this external IP address, otherwise do not receive.)
The port-restricted cone nat is a port-restricted CONE NAT (Port-Restricted Cove Nat), and only those network hosts have issued data that have been sent to an external IP address and port. A port-restricted conference can be the same as symmetric NAT, protecting the internal node does not receive an unqualified packet, but keeping a private port unchanged during the connection. (Because of the original text, that is, not only the IP of IP and external sending data is the same, the port is the same, so that the data is received. The symmetry NAT also has this effect, but this CONE NAT keeps the port constant, and symmetrical NAT To change the port number). Finally, in this document we define some new terms to categorize the behavior of P2P in MiddleBoxes:
P2P-Application In this document, P2P-Application is used as an application that runs in the terminals that participate in the P2P connection and registered in a public login server, can be a private end point, or a public end point, or two Both, and establish a preliminary session.
P2P-MiddleBoxp2p- Middlebox is MiddleBox that allows P2P applications to exchange data.
P2P-FireWall A P2P-firewall is a P2P-MiddleBox that provides firewall functions, but does not have address mapping.
P2P-NATP2P-NAT is to provide NAT function, which also provides P2P-MiddleBox for firewall functions. A P2P-MiddleBox must provide at least the CONE NAT function for UDP transmission, allowing the application to establish a complete P2P connection using UDP. Loopback Translation When a host in a private domain, its NAT tries to connect to other hosts in the public network mapping address, which is equivalent to the NAT device on the packet. Second NAT conversion. Prior to the data report to the target host, the private endpoint of the source host is converted into a common endpoint assigned by NAT, and then converts the common endpoint of the target host into the private endpoint of the target host. Our address translation mentioned above is called "LoopBack Translation" with a NAT device.
3. Technologies with Middleboxes for P2P communication This article detailed reviews technology using existing Middlebox implementation P2P communication, mainly from application or protocol.
3.1 Relaying the most reliable, but the low efficiency, the method of implementing the P2P communication is the same as the P2P communication as a network to the C / S communication during the transmission process. For example, it is ideal that two clients, A and B, each initiate a TCP or UDP connection, connecting to a server S with a fixed IP address known. The client host is in their respective private networks, but their respective Middlebox does not allow their clients to connect directly to other hosts. Server s | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NAT A NAT B | | | | Client A Client B Can not be connected directly, two clients use the S server to pass the delivery. For example, to send a message to the client B, the client A simply sends a message to the S server in a C / S connection method, and then the S server uses the C / S connection established with the client B to send this information to the customer. End B.
The advantage of this method is that as long as the two clients are connected to the server, it is effective. Its significant disadvantage is that it requires the server's processing and takes up bandwidth, and even if the server's network is in good network, there is a certain communication lag problem. Trun Protocol [TURN] defines the related methods of this P2P application.
3.2 Connection Reversal The second technique is to use only one customer under the conditions after MiddleBox. For example, imperative customer A is behind NAT but customer B has a global valid IP address, referring to the following chart:
Server S 18.181.0.31:1235 | | --------------------------------------------------------- ----- | | Nat A | 155.99.25.11:62000 | | | | CLIENT A Client B 10.0.0.1:1234 138.76.29.7:1234
Customer A has a private IP address 10.0.0.1, and an application uses TCP ports 1234. This client and the bus network IP address 18.181.0.31 and port 1235 of the server S have established a connection. NAT A is temporarily assigned a terminal address for the session of client A and server S, and its TCP port 62000, its own IP address is 155.99.25.11: Therefore, server S believes that the client A is used by IP address 155.99.25.11 The port is 62000. However, the client B has its own fixed IP address, 138.76.29.7, and the P2P application above it can receive TCP connections at port 1234. Now I want to establish a P2P connection session with the client A. B may use the address of the client A itself, i.e., 10.0.0.1:1234, may also be used on the address of the server S, 155, 99.25.11: 62000, try the connection. However, in any case, the connection will fail. In the first case, the communication package that points to the IP address 10.0.0.1 will be discarded because 10.0.0.1 is not a public fixed IP address. In the second case, the TCP SYN request package from client B will reach the 62,000 port of Nat A, but NAT A will reject this request because NAT A is only allowed to send data outward.
After the attempt and client A establish a direct connection fail, client B will transmit a request with server S, allowing client A to actively connect customers. After the client A receives a request for the transferred request through the server S, establish a TCP connection using the public IP address and port of the client B. Because this connection is initiated inside the firewall, NAT a allows this connection to establish, and client B can receive this connection because it is not behind MiddleBox. The current implementation of the P2P system has a major limitations, which can only allow one part of the P2P in NAT: and both parties are very common, this method will fail. This method is usually not recommended because this reverse connection is not a common method of solving problems. The application can choose to try a reverse connection, but when "forward" or "reverse" cannot establish a connection, the application should be able to automatically select additional connection mechanisms, such as Relaminging (ie 3.1).
3.3 UDP HOLE PUNCHING The third technology is also one of the important points of this article, which is called "udp Hole Punching" technology. When two hosts that need communication may be behind MiddleBox, UDP Hole PUNCHING relies on some features of the CONE NAT and normal firewalls, allowing the appropriate P2P application to pass MiddleBox through MiddleBox in the "Punch Holes" mode and establish them directly between each other. connection. This technique is briefly mentioned in the 5.1 section of RFC 3027 [NAT-port], and in the Internet [Kegel] non-confirmed mention, it is also used in recent protocols [TEREDO, ICE]. As mentioned in the name, this technology can only be used for UDP connections.
We will consider two special circumstances and consider how the application is perfecting the handshake connection between the two. In the first case, it is also conventional case, and two clients are required to perform P2P connections directly behind the NAT. In the second case, the two clients are behind the same NAT, but they cannot be sure (two clients are behind the same NAT).
3.3.1 Behind DiffERENT NATS is assumed to have its own private IP address, and are also behind different NATs. The P2P application runs on A, B and server S, all UDP ports 1234. A and B are each and the server S established a UDP communication connection, enabling NAT A to assign a connection with a single common port 62000, and NAT B is B is all Connect the 31000 port. 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.1:1234 10.1.1.3:1234
Now, it is now, the client A wants to build a UDP communication session directly and b. Assuming a Simple Send a UDP packet to B Public Address 138.76.29.7:31000, NAT B will discard these access data information (unless it is a Full Cone NAT) because NAT B and S have been established. External session, and the source address and port number in the information sent are not matched with s (can be referred to the above content, matching can be accepted). Similarly, if b sends a subscriber address to A, Nat A will also discard.
However, assuming that a issues a public IP address to b, but also transmits a request to B by server S, requiring B, also issuing a UDP message to a public IP address. A data package sent directly to the public IP address (138.76.29.7:31000) to make Nat A establish a new connection session between A private address and B's public address. At the same time, the information of the public address of B to A (155.99.25.11:62000) will cause NAT B to establish a new connection session between the private address of B and the public address of B. Once this new UDP connection is established between the two, clients A and B do not require "introduction" of the server S directly to communicate with each other.
There are several very useful features of UDP Hole Punching technology. Once a direct P2P connection is established in two clients behind MiddleBox, any party in the connection can play a "introducer" role, continue to establish a connection with another client, reducing the initial server The burden on S. If there is [Stun], if any of the two in the two happens behind MiddleBox, the above application will also establish a P2P communication channel. The application does not need to try to clarify the type of MiddleBox. Hole Punching technology can even be automatically used below the multi-stage NAT, multiple NAT is those who need multi-level address translation to enter public networks.
3.3.2 Behind the Same Nat is now considering the two clients (but not sure), there is a private IP address space. The client A is established with the server S to establish a UDP session, and NAT assigns a common port 62000. Client B and server S also establish a simple connection, NAT assigns a common port 62001. Server S 18.181.0.31:1234 | | NAT as 155.99.25.11:62000 BS 155.99.25.11:62001 | -------------------- --- ------------------- | | Client a Client B 10.0.0.1:1234 10.1.1.3:1234
Imagine A and B use the UDP Hole Punching technology to create an external communication route for the server S as an intermediate introduction. Then A and B will be able to obtain respective public IP addresses and port numbers through the server S, and then use these addresses to send data to the other party. Two customers can communicate with each other in this way, as long as NAT allows the host on the external network to perform UDP transmission sessions on the host on the internal network, the host can be allowed to perform UDP sessions with other internal network hosts. We designed in "Loopback Translation", because the packets from private networks arrive at NAT, will "looped back" to private networks like the public network. For example, when a A UDP package is sent to B, the package header has a source IP address and port, which is 10.0.0.1:1234, and the destination address is 155.99.25.11.62001. NAT accepts this package and converts the source address translation (mapping) to 155.99.25.11:62000 (that is, the public address of A), convert the destination address to 10.1.1.3:1234, and then send it to B. Even if the NAT supports loopback mapping, NAT's conversion and sending steps look excess, it seems to add a potential burden to NAT when communicating in A and B.
The solution to this problem is direct. When A and B swap address information on the server S, they can include their own IP addresses and port numbers, and are visible and visible to the server S. The client starts to send a packet to the other party based on their obtained address, and establish a successful communication. If the two clients are behind the same NAT, the data packet icon communication can be reached directly without the need to establish a direct connection through NAT. If the two clients are located in different NATs, the data packet reaching each other's private address will be discarded, but the client can establish a connection through the respective public addresses. Importantly, these packets need to be identified by some ways, however, in this case, the packet of the private address of the A sent to B is entirely possible to reach other terminals in A private network, B sent to a package Also like this.
3.3.3 Peers Separated by Multiple NATS (Multi-level NAT) In the topology of multiple NAT devices, if there is no knowledge of topology, it is impossible to establish an ideal P2P link between two clients. Take a look at the example below. Server S 18.181.0.31:1234 | | NAT X as 155.99.25.11:62000 BS 155.99.25.11:62001 | | ---------------------- - --------------------- | | Nat a Nat B 192.168.1.1:30000 192.168.1.2:31000 | | | | Client a Client B 10.0.0.1: 1234 10.1.1.3:3:1234
Suppose NAT X is a large NAT set by an Internet Service Provider (ISP), with many users on some public IP addresses, Nat A and B are NAT gateways of small user groups, by ISP users themselves alone Configuration, with its own private network and user group, use IP addresses provided by ISP. Only Server S and NAT X have their own global fixed IP addresses, while Nat A and B "public" IP addresses are actually private address in the ISP address domain, and the address of client a and b come on Nat A and B. It is also a private address. Whenever the client needs to establish an external connection to the server S, it will cause Nat A and B and the client to create a separate public / private connection, then let Nat X create a public / private connection for each connection session.
Now that customers A and B are trying to establish a direct P2P UDP connection. For the client A, the best way is to send a data information to the client b in NAT B, the public IP address of the address domain belonging to ISP 192.168.1.2:31000, the client B is sending information A Public IP address in Nat a 192.168.1.1:30000 (the original NAT B is not a pen error, or I understand the problem?). Unfortunately, A and B did not know how these addresses, because the server S can only see the client "global" public IP address, which is 155.99.25.11:62000 and 155.99.25.11:62001. Even if a and b have some ways to get these addresses, but they still can't guarantee that these addresses are useful, because these addresses allocated by ISP private address domain may be allocated by the private address assigned by the customer. The client therefore no choice to communicate only the common IP address known by the server S and rely on NAT X to provide LoopBack Translation. 3.3.4 Consistent Prot Binddings Hole Punching Technology There is a place to note: it can only work in two NATs are CONE NAT (or no NAT firewall), as long as the UDP port is still using It needs to keep a fixed port to bind a given (private IP, private UDP port) and one (public IP, public UDP port). Like symmetric NAT, assign a new common port for each new connection session, for a UDP application, to reuse an existing address conversion in order to and different external communication is not possible. (This is a bit confused, then look at.) Since Cone NAT is quite common, the UDP Hole Punching technology is also quite wide, but there is a small part of the peer NAT configuration, so this technology cannot be supported.
3.4 UDP Port Number PREDIX
The UDP Hole Punching technology has been discussed above, which allows P2P UDP connection sessions to be created in some pairs of NATs. This method is sometimes referred to as "N 1" technology [bidir] and is described in detail by Takeda [Sym-Stun]. This method analyzes NAT's working mode and attempts to predict the common port assigned to future connection sessions. Rejuvenating the status, A and B of the two customers again, and the UDP connection has been established with a server S with a permanent address behind the respective NAT. Server S 18.181.0.31:1234 | | --------------------------------------- ----- | | Symmetric Nat A Symmetric Nat B AS 155.99.25.11:62000 BS 138.76.29.7:31000 | | | | Client a Client B 10.0.0.1:1234 10.1.1.3:1234nat A Assign a belonging to your own The UDP port 62000 is established to establish a communication connection between A and S, and the NAT B assigns a 31000 port for establishing a connection between B and S. By communication with the server, A and B can get the other party's common IP address and port number from the server S. Client A now sends a UDP packet to address 138.76.29.7, port 31001 (pay attention to the number of ports), and client B simultaneously transmits a data packet to address 155, 99.25.11, port 62001. If Nat A and B are allocated to allocate ports in turn, if it is not established from the A-S and B-S connection, there is a two-way communication channel between A and B to work. A to B packets let Nat A establish a new connection, NAT A (desired) assigns a common port 62001 because the 62,000 port of the connection session before A and S, next is 62001. Similarly, the packets B to A will let Nat B open a new connection and allocate (also desired) to allocate a port 31001. If the client can correctly predict the NAT set to the new connection allocation, a two-way UDP communication channel will be built as shown in the following figure.
Server S 18.181.0.31:1234 | | --------------------------------------- ----- | | Nat a Nat B AS 155.99.25.11:62000 BS 138.76.29.7:7:31000 AB 15.99.25.11:62001 BA 138.76.29.7:31001 | | | CLIENT A Client B 10.0.0.1:1234 10.1 . 1.3: 1234 Obviously, there are many situations that can cause this method to fail. If any of the predicted ports happen to be occupied by other unrelated connections, NAT will miss the correct port, and the connection attempt will fail. If any of the NAT is sometimes or always selecting a non-contiguous port number, this method will fail. If the connection between A (b) is established, the first packet to B (A) is sent, a different client opens a new external connection to any External hosts, unrelated clients will not pay attention to the port required for "A to B or B TO A). Therefore, this method is rarely used when either NAT contains more than one client.
In fact, if those NAT is CONE NAT, or one is a cone nat, the other is symmetrical NAT, and the P2P application in this case still needs to work, the application needs to be implemented in any one and END [Stun] Which clock is modified to modify its working mode, which adds the complex program of the algorithm and makes the network vulnerable. Finally, if any party is in NAT above 2 or more and the NAT recently been symmetrical from the client, the way the predicted port is unable to work. For all these reasons, the application is unable to implement this method. He is mentioned here for historical and information purposes (that is, tell everyone to have such a thing, I think)
3.5. Simultaneous TCP Open (TCP At the same time) After a pair of nodes have MiddleBox already existing MiddleBox, there is a way to establish a direct P2P TCP connection is sometimes used. Most TCP connections are packet from one SYN to another from a terminal, and another interrupt synchronously responds to an SYN-ACK package. In any case, for two terminals, it is feasible to establish a TCP connection with an ACK package by sending a simultaneous package and then answering an ACK package. This process is called "Simultaneous Open" (open at the same time)
If a Middlebox accepts a TCP SYN package from the outside of the private network attempts to establish a TCP connection, MiddleBox usually rejects this connection attempt in a way to discard this SYN package or send a TCP RST (Connect Reset) package. However, if the synchronization package arrives with the source and destination address port, then the MiddleBox will believe that a TCP connection has been established, and then MiddleBox will allow the packet to pass. In particular, if MiddleBox has just got and converted from the SYN package from the same address and port, it will consider the connection to be established and allowed by SYN to pass. If both clients A and B are predicted with each other, their respective MiddleBox will allocate the next TCP connection port. If one of the clients and another client build an external TCP connection, you can reach the local middlebox in the other party SYN. Send the SYN package through its local Middlebox, then the P2P TCP connection is working. Regrettably, this method may also be more vulnerable than the UDP port numbers mentioned above and more sensitive to aging. First, unless the TCP connection is performed, the two MiddleBoxes are simple firewalls or CONE NATs, and when they try to guess the public port slog, when the NAT allocates new connections, the above (UDP port prediction) is exactly the same matter. It will cause the connection to fail. In addition, if one customer sends the synchronization package too quickly reaches the opposite MiddleBox, the remote Middlebox may reject the SYN package with an RST package, which will cause the local MiddleBox to close the conversation and use when SYN will be returned in the future. Port number of the same but useless. Finally, support for Simultaneous Open as a special application of TCP, not used in a wide range of systems. Therefore, this method is only mentioned here for historical factors; it is not recommended to be used by the application. Applications who want to implement P2P direct communication on existing NAT should use UDP.
4. Application Design Guidelines (Application Design Idea)
4.1 Works with p2p middleboxes (How to work with P2P MiddleBox) Since UDP Hole Punch is the most efficient one in two P2P direct communication methods that are located between the two hosts, and it can be in a variety of existing Used on NAT, if you need to establish a valid P2P communication, this method is usually suggested, but when direct communication cannot be established, it will rely on simple propagation. (Not much not understood)
4.2 Peers Behind The Same Nat (behind the same NAT) In fact, there is a considerable number of users more than 2 IP addresses, there will be 3 or more IP addresses. In this case, telling the login server which address is very difficult. Therefore, in this case, the application should send all its IP addresses.
4.3 Peer Discovery (host discovery)
The application will send some data packets to several addresses to find which address is the most appropriate, the application may become (after the latter does not understand, it's understanding, sorry), because the host may choose one The routing address is used as an internal local area network (for example, 11.0.1.1 has been assigned by the DOD network, and the DOD is a network model). Therefore, the application should be careful to send the estimated call package. Apply for a few addresses to find a few addresses, which is suitable for a stipulate that the aristocratic use may become a significant source of 'spatial waste',
4.4 TCP P2P Applications (TCP P2P App)
The Socket API, which is widely used by programmers, is often used in the C / S structure application design. In its usual usage, a socket can bind a TCP or UDP port. An application is not allowed to use the same port (TCP or UDP) and multiple Socket bindings and multiple external hosts to establish connections (or) with a Socket listen on the port on the port to create an external connection. But the port binding limit of the above SOCKET is not a problem on UDP because UDP is based on data-based protocol. The UDP P2P application designer can use the RECVFROM () and sendto () functions to allow a socket not only sent but also accepted data packets from multiple hosts. This is not the case where TCP has. Due to TCP, each input and output connections are related to a separate socket. Linux Sockets API solves this problem with the help of the SO_REUSEADDR option (should I say this?), This option seems to be a role, but it is possible (there is no such function in the standard Single Unix). The Win32 API provides an identical call setREUseAddress. With any of the above selections, the application can multiplex multiple Sockets of a TCP port. That is to say, you can open two TCP Stream Sockets that bind them on the same port, one with listen (), another with other host connect ()
4.5 Use of Midcom Protocol ()
If the application knows that they need to cross the MiddleBox and these MIDdleBox implementation of the MIDCOM protocol, the application can easily cross the MiddleBox using the MIDCOM protocol. For example, the P2P application requires NAT MiddleBox to keep the terminal port binding state. If MIDdleBox can support MIDCOM, the P2P application can control parameters of the modification of the binding port (or binding address), such as the time of life, maxidletime (?), So the application can not only directly connect the external host but also from the external host. Connection; this does not need to keep the port binding state. You can also use the MIDCOM protocol to unbind the binding when the application is no longer needed.
5. Nat Design Guidelines (NAT Design Guide) This section discusses the design of network address transformation, they will affect P2P applications.
5.1 DepRecat The Use of Symmetric Nats (disapproval of the use of peer NAT) peer NAT is widely used in those C / S structures, such as web browsing, only need to establish an outward connection. But now, P2P applications such as real-time messages and voice conferences are widely used. The peer NAT cannot support the definition of the reserved terminal and does not apply to the P2P application. It is not recommended to use the peer NAT to support the P2P application. A P2P-MIDDLEBOX must have the characteristics of CONE NAT in the UDP communication, allowing the application to establish a stable P2P connection using UDP Hole PUNCHING technology. In theory, a P2P-MiddleBox should also allow the application to elapse both TCP or through UDP.
5.2 Add Incremental CONE-NAT Support to Symmetric Nat Devices (Added CONE-NAT to support the peer NAT device)
One allows the peer NAT device extension to support the P2P application is to allocate its transferable port space, and book a suitable port for one to one connection to make a suitable set of different sets of different connections. port. Further (future?), A NAT device can be explicitly configured by those P2P applications and host, so the NAT device can automatically allocate a P2P port by the correct port data block.
5.3 Maintain Consisten Port Bindings for UDP Ports This data is the most important and most important suggestion for NAT designers to keep a fixed port, bind a given (internal IP address, internal) UDP port) and a corresponding (public IP address, common UDP port) As long as there is any connection exists and use this port binding, this port is bound to exist. By checking the source and destination IP addresses and port numbers of each package, the NAT may filter the data packets about each connection basis (? 俺 8 understand). When a new external connection is established on a node on a private network, an existing IP address and UDP port number of the existing converted UDP connection session are used. NAT should ensure that the new UDP connection is given as an existing connection. Set a same public IP address and UDP port. 5.3.1 PreserVing Port Numbers (That is, the client is used to use the port, the NAT assignment 啥 port this mean) Some Nat, when establishing a new UDP connection, try to assign a corresponding private port number to allocate one The same common port number, if this port number happens to be available. For example, if the address is 10.0.0.1 client A creates an external UDP connection with a packet sent from port 1234, the NAT's common port 1234 happens to be available, then NAT will use the NAT public IP address for the connection. The port number 1234 is the address of the conversion client A. Since this port number is used if the internal network is using this port number, it is the only way for a NAT hold port. This method may be helpful to some of the UDP programs that wish to use the special UDP port number, but not It is recommended that the application relies on this way. In addition, a NAT should not keep the port number in a new connection, and if it is actually contradicts the purpose of maintaining the public and private terminal address binding. For example, it is assumed that the client A establishes a connection with the external server S on the internal 1234 port, and NAT A has assigned a common port 62000 for this connection because the port number 1234 is not available at this NAT. Now imagine port number 1234 on NAT can then be used, while the connection of A and S still exists, the client A creates a new connection to the external node B with the same internal port 1234. In this case, since the port binding has been established on the port 1234 and NAT of the client A, this binding should continue to keep, the new connection should also be used as a common port using 62000 ports to correspond to the client. A port 1234. NAT should not only assign a common port 1234 because of the port 1234, which is allocated for new connections: This feature is impossible to help the application in any case, because the application has been operated for a conversion port number, And it interrupts the application of the application to establish a P2P connection with UDP Hole PUNCHING technology.
5.4 MAINTAINING CONSISTENT Port Bindings for TCP Ports The characteristics of the TCP port remain ports) and the UDP address translation are consistent. CONE NAT should also keep the TCP connection private and public IP addresses. The above is the same as the UDP description. Keep the TCP terminal binding constant will increase the NAT to the P2P TCP application compatibility with multiple TCP connections from the same source port.
5.5 LARGE TIMEOUT for P2P Applications (P2P program Extra timeout?) We recommend that MiddleBox uses the minimum timeout used by MiddleBox to be used for approximately 5 minutes (300 seconds), ie, when the P2P application is bound to the port or assigns a port, Configure this idle timeout to MiddleBox. When MiddleBox is currently configured, you often try to use a shorter time. But shorter timeout is some problems. Consider a P2P application with 16 terminal nodes, they will send each 10 seconds to a packet that holds the active status to avoid NAT timeout. This is because one may be 5 times the Middlebox timeout time to hold the active packet, in which case the packet that keeps the active package will be discarded on the network. 5.6 Support Loopback Translation (Supported Self-Ring Conversion) We strongly recommend that Middlebox supports self-ring transformations, allowing hosts that can be converted from the hosts behind a MiddleBox to be converted to the same MiddleBox. Supporting self-ring transformation is quite important, especially in those large-capacity multi-layer NAT, as the first stage NAT. As described in Section 3.3.3, at the same level NAT, the second-level NAT different hosts cannot communicate with each other through the UDP Hole Punch, even if the MiddleBox keeps the endpoint in NAT, unless the first level NAT supports auto-conversion.
