Original copyright: Copyright (c) The Internet Society (2003).? All rights address: http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt translation copyright statement: please Quote the author or website of this article indicate: http://blog.9cbs.net/hxhblueestar to respect the translator's labor results!
3. P2P communication technology based on proxy service
This chapter reviews some of the currently populated point-to-point communication technologies based on the current proxy device, from the forefront of the application or protocol designer.
3.1. RELAYING
3.1 forwarding
The most reliable, but it is also the lowest point-to-point communication method, which is to communicate with P2P network as a C / S structure, forward information through (servers). For example, as shown below, both clients A and B have initialized a TCP or UDP connection with the server S, the server S has a public network fixed IP address, and the two clients are distributed in different private networks, so that Their respective NAT proxy servers will not allow them to be directly connected.
The most reliable, but least efficient, method of implementing peer-to-peer communication in the presence of a middlebox is to make the peer-to-peer communication look to the network like client / server communication through relaying. For example, suppose two client hosts, A and B, have each initiated TCP or UDP connections with a well-known server S a permanent IP address having. The clients reside on separate private networks, however, and their respective middleboxes prevent either client from directly initiating a connection to The Other.
Instead, two clients can forward the server S as a message. For example, in order to send a message to B, A first sends a message to the server S, the server S has been established when the server S has been initialized, and the information is forwarded to B.
Instead of attempting a direct connection, the two clients can simply use the server S to relay messages between them. For example, to send a message to client B, client A simply sends the message to server S along its already-established client / server Connection, And Server S Then Sends The Message On To Client B Using Its Existing Client / Server Connection with B.
The advantage of this method is that when both clients are connected to the server, it will always work.
But its disadvantages are also obvious: it will fully depend on and consume the resources and performance and network bandwidth of the server. The communication reaction time of the two clients will increase significantly, even if they always be connected to the server. A protocol named TURN [TURN] defines a model using forwarding technology to reliably communicate. This method has the advantage that it will always work as long as both clients have connectivity to the server. Its obvious disadvantages are that it consumes the server's processing power and network bandwidth unnecessarily, and communication latency between the two clients is likely to be increased even IF The Server IS Well- Connected. The Turn Protocol [TURN] Defines a method of implementing relative in a relationively secure fashion.
3.2. Connection Reversal
3.2 Reverse connection
Here, the second technique is introduced, but it can only be in the case of only one end on both ends of the communication. For example, it is assumed that the client A is behind NAT, and the client B has a public IP address, as shown below.
The Second Technique Works IF Only One of the Clients Is Behind A Middlebox. For Example, Suppose Client A Is Behind A Nat But Client B Has A Globally Routable IP Address, AS in The Following Diagram:
The private IP address of the client A is
10.0.0
.1, and use TCP port 1234, the client A initializes a connection to server S (IP = 18.181.0.31: 1235). NAT A (IP = 155.99.25.11) Assigns a 62,000 TCP port to this connection. Therefore, the server S believes that the IP address of the client A is 155.99.25.11:62000. However, the client B has a fixed IP address 138.76.29.7, in this end-to-end connection, client B uses TCP port 1234.
Client a Has Private IP Address
10.0.0
.1, and the application is using TCP port 1234. This client has established a connection with server S at public IP address 18.181.0.31 and port 1235. NAT A has assigned TCP port 62000, at its own public IP address 155.99.25.11, to serve as the temporary public endpoint address for A's session with S: therefore, server S believes that client A is at IP address 155.99.25.11 using port 62000. Client B, however, has its own permanent IP address, 138.76.29.7, and The Peer-to-Peer Application On B Is Accepting TCP Connections At Port 1234. Now we assume that the client B will initialize a peer-to-end connection session with the client a. B will be attempted first
Any address of connection A - Client a thinks it is its own address, ie
10.0.0
.1: 1234. Or observe from the server S, that is, 155.99.25.11:62000. However, whether it is connected to which one in the address is connected, it is impossible to succeed. The first case: attempting to connect directly to 10.0.0.1 will definitely fail, because 10.0.0.1 is not a IP address that can be routed on public online; second case, the TCP SYN request from B will be able to reach the port NAT A port 62000, but Nat A will reject this connection request because only outgoing connections are allowed (enter).
NOW Suppose Client B Would Like to Initiate a Peer-to-Peer Communication Session With Client A. B Might First Attempt To Contact Client A Either At The Address Client A Believes Itself to Have, Namely
10.0.0
.1: 1234, OR at The Address of a as Observed by Server S, Namely 55.99.25.11:62000. In Either Case, However, The Connection Will Fail. In The First Case, Traffic Directed to IP Address
10.0.0
.1 Will Simply Be Dropped by The Network Because
10.0.0
.1 is not a publicly routable IP address. In the second case, the TCP SYN request from B will arrive at NAT A directed to port 62000, but NAT A will reject the connection request because only outgoing connections are allowed.
After all attempts fail, client b can only borrow server S to pass a request to client A, request a "flip" connection to client B, and client A, in accepting this through server After the request to forward, a TCP connection to the client B communication will open (on the public IP address and port number of B). NAT A allows this connection to pass because this connection originated inside NAT A, and the client B can be subject to this connection because B is not in NAT. After attempting and failing to establish a direct connection to A, client B can use server S to relay a request to client A to initiate a "reversed" connection to client B. Client A, upon eceiving this relayed request through S, opens a TCP connection to client B at B's public IP address and port number. NAT A allows the connection to proceed because it is originating inside the firewall, and client B can receive the connection because it is not behind a middlebox.
There is currently a lot of P2P systems. Its main limit is that this technology can only take effect on one end after NAT. However, today's true situation is that more and more clients are in NAT, then this method is not feasible. Because the reverse connection is not a universal solution, it is not recommended here. The application can choose to try to do a reverse connection, but it is possible that the message will be returned automatically - if the other end message delivery mechanism is neither "forward" nor "reverse" connection.
A variety of current peer-to-peer systems implement this technique Its main limitation, of course, is that it only works as long as only one of the communicating peers is behind a NAT:. In the increasingly common case where both peers are behind NATs, the method fails. Because connection reversal is not a general solution to the problem, it is nOT recommended as a primary strategy. Applications may choose to attempt connection reversal, but should be able to fall back automatically on another mechanism such as relaying if NEITHER A "Forward" NOR A "Reverse" Connection Can Be Established.
