From today, he will translate Peer-to-Peer (P2P) Communication Across Middleboxes, and do not follow the order of chapters.
Original copyright: CopyRight (c) The Internet Society (2003). All Rights Reserved.
Original address: http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
The translation copyright has declaration: Please refer to the author or website of this article indicate: http://blog.9cbs.net/hxhbluestar to respect the translator's labor results!
3.4. UDP port number prediction UPD port number predicted A variant of the UDP hole punching technique discussed above exists that allows P2P UDP sessions to be created in the presence of some symmetric NATs. This method is sometimes called the "N 1" technique [ BiDir] and is expedition in detail by takeda [sym-stun]. The method Works by Analyzing the Behavior of the Nat and Attempting to Predict The Public Port Numbers It Will Assign To Future Sessions.
Consider Again The Situation in Which Two Clients, A and B, Each Behind A Separate Nat, Have Each Established UDP Connections with a Permanently Addressable Server S:
Let us consider such a situation, there are two clients A and B, they are all behind different NATs, they all open a UDP connection to Server S with fixed IP: as shown below
NAT A has assigned its own UDP port 62000 to the communication session between A and S, and NAT B has assigned its port 31000 to the session between B and S. By communicating through server S, A and B learn each other's public IP addresses and port numbers as observed by S. Client A now starts sending UDP messages to port 31001 at address 138.76.29.7 (note the port number increment), and client B simultaneously starts sending messages to port 62001 at address 155.99.25.11. If NATs A and B assign port numbers to new sessions sequentially, and if not much time has passed since the AS and BS sessions were initiated, then a working bi-directional communication channel between A and B should result.A's messages to B cause NAT A to open up a new session, to which NAT A will (hopefully) assign public port number 62001, because 62001 is next in sequence after the port number 62000 it previously assigned to the session between A and S. Similarly, B's messages to A will cause NAT B TO open a new session, to which it will (hopefully) assign port number 31001. If both clients have correctly guessed the port numbers each NAT assigns to the new sessions, then a bi-directional UDP communication channel will have been established as shown below.
NAT A assigns its own UDP port 62000 to keep the client A communication session with the server S, NAT B is also assigned a 31000 port to keep the client B and the communication session of the server S. By dialogue with server S, both client A and client B know each other's real IP and ports mapped.
Client A sends a UDP message to 138.76.29.7:31001 (note the increase in the port number), and the client B sends a UDP message to 155.99.25.11:62001. If NAT A and NAT B continue to assign a new session to a new session, there is not much time consumption from the session time of A-S and B-S, then a two-way session channel between client A and client B is established.
The message delivered by the client A caused Nat a to open a new session and we hope that NAT A will assign the 62001 port to this new session, because 62001 is followed by 62000, NAT will automatically assign to the server S The port number of the new session between the client A; Session; if the two clients are correctly guessing the port number of the other party's new session assigned, then the two-way connection of this client A-client B is turned on. The results are shown below: Obviously there are many things that can cause this trick to fail If the predicted port number at either NAT already happens to be in use by an unrelated session, then the NAT will skip over that port number and the. connection attempt will fail. If either NAT sometimes or always chooses port numbers non-sequentially, then the trick will fail. If a different client behind NAT A (or B respectively) opens up a new outgoing UDP connection to any external destination after A ( B) establishes its connection with S but before sending its first message to B (A), then the unrelated client will inadvertently "steal" the desired port number. This trick is therefore much less likely to work when either NAT involved is under load.
Obviously, many factors can cause this method to fail: If this prophecy new port (62001, and 31001) happens to be used by an unrelated session, then NAT will skip this port number, this connection will declare If two NATs sometimes or always generate new port numbers in order, then this method is not there.
If a different client X (or after NAT B) is hidden in Nat B, it opens a new "out" UDP connection, and regardless of this connection; as long as this action occurs in the client A After the server S is connected, the client A is connected to the client B before the client B; then this unrelated client X will "steal" to the port we desire to allocate. Therefore, this method becomes so fragile and unbearable, as long as any NAT contains the problems encountered above, this method will not work.
Since in practice a P2P application implementing this trick would still need to work if the NATs are cone NATs, or if one is a cone NAT and the other is a symmetric NAT, the application would need to detect beforehand what kind of NAT is involved on either end [STUN] and modify its behavior accordingly, increasing the complexity of the algorithm and the general brittleness of the network.Finally, port number prediction has no chance of working if either client is behind two or more levels of NAT and the NAT ( S) Closest to The Client Are Symmetric. For all of these reasons, it is not recommended That New Applications IMPLEMENT THIS TRICK; IT IS Mentioned Here For Historical and InformationAl Purposes.
Since the use of this method to practice P2P, this method is still practical in a CONE NAT series; if one party is CONE NAT and the other party is Symmetric Nat, then the application should be priorcted in advance. What type of NAT is, then make the correct behavior to process communication, which increases the complexity of the algorithm and reduces the universality in a real network environment.
Finally, if the P2P is at the two or more NAT above, and these NATs are close to this client is symmetric, the port number propheter is invalid!
Therefore, it is not recommended to use this method to write new P2P applications, which is also the experience and lessons of history!
