Title of Invention

METHOD FOR ESTABLISHING A PEER TO PEER CONNECTION

Abstract

Disclosed is a method for establishing a Peer to Peer (P2P) connection, including: data packet at least including the address information of the other of the first host and the second host on receipt of a synchronization request sent by a first host; and sending, by each of the first host and the second host, a UDP data packet to the other on receipt of the synchronization data packet. Also disclosed is a system for establishing a P2P connection. According to the present invention, a P2P connection between two hosts can be established successfully in most cases, because a data packet is already sent by each of the first host and the second host when they each receives the data packet sent by the other. Therefore, the present invention increases the success rate of establishing P2P connections.

Full Text

METHOD AND SYSTEM FOR ESTABLISHING A PEER TO PEER CONNECTION Field of the Invention The present invention relates to a connection technique of nodes in a computer Background of the Invention Connections between two nodes in a network generally fall into two modes. One is client/server mode, in which a client requests for a service and a server provides the service, typically in a one-to-multiple manner. As shown in Fig. 1, a server may receive requests from multiple clients and provide services for the multiple clients, and the server and the clients are not peer to peer. The other is P2P mode, in which each two nodes in a computer network are directly interconnected as shown in Fig. 2, i.e., each two nodes are peer to peer. In client/server mode, since servers are responsible for providing services for many clients, high performance machines are typically used as servers, which results in high costs. While in P2P mode, two communication terminals are peer to peer and provide service for each other, which provides the P2P mode with prominent advantages, i.e., many PCs with average performance may be interconnected to share resources and communicate with each other, thereby remarkably reducing the costs. And also for this reason, P2P has become a new trend in network development. At present, its applications mainly cover file exchange, distributed computing, cooperating, distributed searching, electronic trading, and so on. Despite the above advantages, development of P2P is somewhat limited, because more and more computers are being under the protection of a Network Address Translator (NAT) against network virus attack. NAT is an apparatus usually integrated in routers and responsible for checking and forwarding between a private network and a public network. Since the NATs may modify the IP address and port information of a host in a private network, the NATs restrict direct communications between any two computers and only permit communications in compliance with certain rules. Therefore, it has become a main task to overcome the restriction of NATs for implementing P2P. NATs roughly fall into the following categories: Basic NAT, Cone NAT and Symmetric NAT. A Cone NAT typically associates a {local IP address, local port} with a {global IP address, global port}, then uses this associated port repeatedly for service connections from a same local IP address and port number, and keeps the associated port active as long as there is still one such connection remaining in conversation. Cone NATs further fall into several sub-categories: Full Cone NAT, Restricted Cone NAT and Port-Restricted Cone NAT. A Full Cone NAT associates a global port with a local port for a new conversation with an external terminal, and then receives communication data from any external terminal in the public network via the global port. A Restricted Cone NAT will not accept any data packet from an external IP address of an external host until a local host has sent one or more data packets to the IP address of the external host. A Port-Restricted Cone NAT will not receive any data packet from the IP address and the port identification of an external host until a local host has sent one or more data packets to the IP address and the port identification of the external host. It can be seen that Restricted Cone NATs and Port-Restricted Cone NATs can effectively protect local hosts from receiving data packets not invited. A Symmetric NAT will not keep the associated relation between a {local IP address, local port number} and a {global IP address, global port number} unchanged through all the conversations. Instead, it will assign a new global port or a global IP address to each new conversation. Since there are all kinds of NATs and each has its own specified communication manner, when a P2P connection is to be established between two nodes of different NAT type, respective NAT type of the two nodes should be firstly obtained, then the P2P connection will be established in different communication manners according to the NAT types. The method for establishing a P2P connection according to the prior art is described below. First, when a host A in a network attempts to establish a P2P connection to a host B, an external server possessing two IP addresses is usually needed to determine the NAT type of its own residing network, and then submit the NAT type to a server. Similarly, the server also keeps the NAT type submitted by host B. Host A acquires from the server the NAT type of the network where host B resides. If host B resides in a public network or the NAT type of the network where host B resides is Full Cone NAT, host A shall adopt an active mode in Fig. 3. As shown in Fig. 3, host A sends a data packet directly to host B, and host B returns a responsive data packet to host A, thereby a P2P connection is established. Otherwise, host A adopts a passive mode in Fig. 4. As shown in Fig. 4, host A instructs host B via the server to send a data packet to host A firstly, then host A returns a responsive data packet to host B, thereby a P2P connection is established. In the above passive mode, if host A resides in a public network or the NAT type of the network where host A resides is Full Cone NAT, the P2P connection can be established successfully. If the NAT type of the network where host A resides is one of Restricted Cone NAT, Port-Restricted Cone NAT and Symmetric NAT, however, since NATs of these types shall reject data packets not invited, or even discard data packets sent from a certain IP address and port number within a period of time because of regarding them as attacking packets, which makes P2P connections failed to be established. It can be seen that the success rate of establishing P2P connections is low in the prior art. Summary The main aspect of the present invention provides a method and system for establishing a P2P connection, which increases the success rate of establishing P2P connections. The present invention is achieved by the following technical schemes. A method for establishing a P2P connection includes: sending, by a server, to each of a first host and a second host, a synchronization data packet which at least includes the address information of the other of the first host and the second host on receipt of a synchronization request sent by the first host; and sending, by each of the first host and the second host, a User Datagram Protocol, UDP, data packet to the other according to the received address information of the other on receipt of the synchronization data packet. The method further includes: recording, by the server, network identifications and address information of the first host and the second host respectively. The synchronization request sent by the first host at least includes the network identification and address information of the second host. The method further includes: judging, by the second host, whether to establish a P2P connection to the first host on receipt of the synchronization data packet, and sending a UDP data packet to the first host if determining to establish a P2P connection to the first host, or terminating the process if determining not to establish a P2P connection to the first host. The method further includes: sending, by each of the first host and the second host, a responsive data packet to the other on receipt of the UDP data packet sent by the other. When the first host resides within the domain of a Restricted Cone Network Address Translator, NAT, or a Port-Restricted Cone NAT, or a Symmetric NAT, and the second host resides in a public network or within the domain of a Full Cone NAT, sending by each of the first host and the second host a UDP data packet to the other on receipt of the synchronization data packet includes: sending, by the first host on receipt of the synchronization data packet, a UDP data packet to the second host according to the received address information of the second host; and sending, by the second host on receipt of the synchronization data packet, a UDP data packet to the first host according to the received address information of the first host. When the first host resides in a public network or within the domain of a Full Cone NAT, and the second host resides within the domain of a Restricted Cone NAT, or a Port-Restricted Cone NAT or a Symmetric NAT, sending by each of the first host and the second host a UDP data packet to the other on receipt of the synchronization data packet includes: host; and sending, by the first host on receipt of the synchronization data packet, a UDP data packet to the second host according to the received address information of the second host. When the first host resides within the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT, and the second host resides within the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT, sending by each of the first host and the second host a UDP data packet to the other on receipt of the synchronization data packet includes: sending, by the first host on receipt of the synchronization data packet, a UDP data packet to the second host according to the received address information of the second host; and sending, by the second host on receipt of the synchronization data packet, a UDP data packet to the first host according to the received address information of the first host. When the first host resides within the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT, and the second host resides within the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT, sending by each of the first host and the second host a UDP data packet to the other on receipt of the synchronization data packet includes: sending, by the second host on receipt of the synchronization data packet, a UDP data packet to the first host according to the received address information of the first host; and sending, by the first host on receipt of the synchronization data packet, a UDP data packet to the second host according to the received address information of the second host. The address information at least includes a public network Internet Protocol, IP address, address and port number. A system for establishing a P2P connection includes a server, a first host and a second host; the server, on receipt of a synchronization request sent by the first host, sends to each of the first host and the second host a synchronization data packet which at least includes the address information of the other of the first host and the second host; and each of the first host and the second host, on receipt of the synchronization data packet, sends a User Datagram Protocol, UDP, data packet to the other according to the received address information of the other. A method for establishing a P2P connection includes: acquiring, by a first host, from a server the address information of a second host and Network Address Translator, NAT, information of the network where the second host resides; and if the second host resides in a public network or within the domain of a Full Cone NAT, sending, by the first host, a UDP data packet to the second host according to the acquired address information of the second host; and if the second host does not reside in a public network and does not reside within the domain of a Full Cone NAT, determining, by the first host, the NAT information of the network where the first host resides; if the first host resides in a public network or within the domain of a Full Cone NAT, instructing, by the first host, the second host via the server to send a UDP data packet to the first host; and if the first host does not reside in a public network and does not reside within the domain of a Full Cone NAT, performing the following process: sending, by the first host, a synchronization request to the server on receipt of the synchronization request, sending, by the server, to each of the first host and the second host a synchronization data packet which at least includes the address information of the other of the first host and the second host; and the other according to the received address information of the other on receipt of the synchronization data packet. It can be seen from the above scheme that in the method of the present invention, each of the two hosts send a UDP data packet to the other, thereby the NAT will regard the received data packet as valid because a data packet has already been sent to the other when receiving the data packet sent by the other, and thus a P2P connection can be successfully established between the two hosts. And this solves the problem in the prior art that a P2P connection cannot be successfully established when either host resides in the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT which both reject data packets not invited. In addition, when one host resides in the domain of a port-changing Symmetric NAT and the other host resides in the domain of a Restricted Cone NAT, the P2P connection can also be successfully established. Thus, the success rate of establishing P2P connections is greatly increased. Brief Description of the Drawings Fig. 1 is a schematic in which hosts in a network are connected in client/server mode. Fig. 2 is a schematic in which hosts in a network are connected in P2P mode. Fig. 3 is a schematic of establishing a P2P connection in an active manner according to the prior art. Fig. 4 is a schematic of establishing a P2P connection in a passive manner according to the prior art. Fig. 5 is a schematic of establishing a P2P connection in a synchronous manner according to the present invention. Fig. 6 is a flowchart of establishing a P2P connection in a synchronous manner according to the present invention. Embodiments of the Invention The present invention is further explained hereinafter in detail with reference to the accompanying drawings as well as embodiments so as to make the objective, the technical scheme and merits thereof more apparent. It should be appreciated that the embodiments offered herein are used for explaining the present invention only and shall not be used for limiting the present invention. The present invention provides a method for establishing a P2P connection in a synchronous manner as shown in Fig. 5. When desiring to establish a P2P connection to host B, host A first sends a synchronization request data packet to a server. On receipt of the synchronization request data packet, the server sends to each of host A and host B a synchronization data packet including the network information of the other one of host A and host B. And on receipt of the synchronization data packet, each of host A and host B sends to the other a User Datagram Protocol (UDP) data packet. And on receipt of the UDP data packet sent by the other, each of host A and host B returns a UDP responsive data packet to the other. Fig. 6 is a flowchart of establishing a P2P connection in a synchronous manner according to the present invention. As shown in Fig. 6, the detailed process includes the following steps. In step 601, host A and host B respectively log into a server which records the global IP addresses and global port numbers, local IP addresses and local port numbers, and network identifications (ID) of host A and host B. In step 602, when tending to establish a P2P connection to host B, host A sends to the server a synchronization request data packet at least including the local IP address and port number of host A, global IP address and port number of host A, and network ID of host B. In step 603, on receipt of the synchronization request data packet sent from host A, the server sends to each of host A and host B a synchronization data packet. The synchronization data packet sent to host A at least includes the global IP address and port number of host B and the local IP address and port number of host B, while the synchronization data packet sent to host B at least includes the global IP address and port number of host A and the local IP address and port number of host A. Then steps 604 and 606 are performed respectively. of host B in the public network and the private network. In step 605, after receiving the UDP data packet sent by host A, host B returns to host A a responsive data packet which will be accepted by the NAT of the network then host A quits the process. In step 606, on receipt of the synchronization data packet sent by the server, host B determines whether to establish a P2P connection to host A, and performs step 607 if host B determines to establish a P2P connection, or otherwise terminates the process and the P2P connection is failed to be established. In step 607, host B sends a UDP data packet to host A according to the IP addresses and port numbers of the public and the private networks of host A. And in step 608, after receiving the UDP data packet sent by host B, host A returns to host B a responsive data packet which will also be accepted by the NAT of the network where host B resides because host B has already sent a UDP data packet to host A. Thereby, the process of establishing a P2P connection between hosts A and B is completed. The effect of the above scheme is analyzed below. When host A and host B reside in a public network or within the domain of a Full Cone NAT, the P2P connection can be established successfully by the synchronous manner of establishing a P2P connection in accordance with the present invention. When host A resides within the domain of a Restricted Cone NAT, or a Port-Restricted Cone NAT or a Symmetric NAT, and host B resides in a public network or within the domain of a Full Cone NAT, a P2P connection can be established successfully as long as step 604 is performed before step 608, i.e., before host A receives a UDP data packet sent by host B, host A has already sent a UDP data packet to host B. In practice, to ensure that host A has already sent a UDP data packet to host B before host A receives a UDP data packet sent by host B, it can be configured that host B will not send a UDP data packet to host A until host A sends a UDP data packet to host B. When host A resides in a public network or within the domain of a Full Cone NAT, and host B resides within the domain of a Restricted Cone NAT, or a Port-Restricted Cone NAT or a Symmetric NAT, a P2P connection can be established sent a UDP data packet to host A before host B receives a UDP data packet sent by host A. In practice, to ensure that host B has already sent a UDP data packet to host A before receiving a UDP data packet sent by host A, it can be configured that host A will not send a UDP data packet to host B until host B sends a UDP data packet to host A. When host A resides within the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT, and host B resides within the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT, a P2P connection can be established successfully as long as step 607 is performed before step 605, or step 604 is performed before step 608. In practice, it can be configured that host B will not send a UDP data packet to host A until host A sends a UDP data packet to host B, or host A will not send a UDP data packet to host B until host B sends a UDP data packet to host A. When any of host A and host B resides within the domain of a Symmetric NAT, a P2P connection can also be established successfully in the two cases described below. Case 1, if one of host A and host B is within the domain of a port-changing Symmetric NAT, and the other is within the domain of a Restricted NAT, a P2P connection between the two hosts can be established because the Symmetric NAT will not change the source global IP address from which data packets are sent and thus the Restricted NAT as the opposite party will accept the data packets. Case 2, in some systems which map the IP address and port number in a Port-Restricted Cone NAT manner preferably for the Symmetric NAT detected, and in which Symmetric manners, e.g., iptables, are only used when a conflict may arise, a P2P connection between the two hosts can be established. It can be seen from the above analysis that establishing a P2P connection in a synchronous manner provided by the present invention can at least solves the problem that a P2P connection cannot be established when the two hosts reside within the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT, as long as each of the two hosts has already sent a data packet to the other when receiving a data packet from the other. As shown in Fig. 5, the condition is that the sum of time taken by the server to send a synchronization data packet to host A and time taken by host A to send a UDP data packet to host B is greater than the time taken by the server to send a synchronization data packet to host B, which in practice is easy to be met, thereby the present invention causes P2P connections to be established successfully more frequently, i.e., causing the success rate of establishing P2P connections increased. In addition, the present invention also includes a scheme which combines the above scheme of sending data packets simultaneously with the scheme of establishing a P2P connection according to the prior art, which is specifically described below. Host A acquires from a server the address information of host B and the NAT type of the network where host B resides. If host B resides in a public network or the NAT type of network where host B resides is Full Cone NAT, host A adopts an active manner which is as shown in Fig. 3. In Fig. 3, host A sends a data packet directly to host B according to the address information of host B. And host B returns a responsive data packet to host A, thereby a P2P connection is established. If host B does not reside in a public network and not within the domain of a Full Cone NAT, host A further determines whether host A is in a public network or within the domain of a Full Cone NAT. If host A is in a public network and not within the domain of a Full Cone NAT, host A adopts a passive manner as shown in Fig. 4. In Fig. 4, host A instructs host B via the server to first send a data packet to host A. And host A returns a responsive data packet to host B. Thereby a P2P connection is established. If host A is not in a public network and not within the domain of a Full Cone NAT, the above scheme in which data packets are sent simultaneously is adopted. According to the scheme, host A sends a synchronization request to the server, then the server simultaneously sends to each of host A and host B a synchronization data packet which at least includes the address information of the other of host A and host B. And on receipt of the synchronization data packet, each of host A and host B sends a data packet to the other. The foregoing description is only preferred embodiments of the present invention and is not for use in limiting the protection scope thereof. All the modifications, equivalent replacements or improvements in the scope of the present invention's sprit Claims 1. A method for establishing a Peer to Peer, P2P, connection, comprising: sending, by a server to each of a first host and a second host, a synchronization data packet which at least comprises the address information of the other of the first host; and sending, by each of the first host and the second host, a User Datagram Protocol, UDP, data packet to the other according to the received address information of the other on receipt of the synchronization data packet. 2. The method of Claim 1, further comprising: logging, by the first host and the second host, into the server before the synchronization request is sent from the first host to the server; and recording, by the server, network identifications and address information of the first host and the second host respectively. 3. The method of Claim 1, wherein the synchronization request sent fi*om the first host at least comprises the network identification and address information of the second host. 4. The method of Claim 1, further comprising: judging, by the second host, whether to establish a P2P connection to the first • host on receipt of the synchronization data packet, and sending a UDP data packet to the first host if determining to establish a P2P connection to the first host, or terminating the process if determining not to establish a P2P connection to the first host. 5. The method of Claim 1, further comprising: sending, by each of the first host and the second host, a responsive data packet to the other on receipt of the UDP data packet sent by the other. 6. The method of Claim 1, wherein when the first host resides within the domain of a Restricted Cone Network Address Translator, NAT, or a Port-Restricted Cone NAT, or a Symmetric NAT, and the second host resides in a public network or within the domain of a Full Cone NAT, sending by each of the first host and the second host a UDP data packet to the other on receipt of the synchronization data packet comprises: sending, by the first host on receipt of the synchronization data packet, a UDP data packet to the second host according to the received address information of the sending, by the second host on receipt of the synchronization data packet, a UDP data packet to the first host according to the received address information of the first host. 7. The method of Claim 1, wherein when the first host resides in a public network or within the domain of a Full Cone NAT, and the second host resides within the domain of a Restricted Cone NAT, or a Port-Restricted Cone NAT or a Symmetric NAT, sending by each of the first host and the second host a UDP data packet to the other on receipt of the synchronization data packet comprises: sending, by the second host on receipt of the synchronization data packet, a UDP data packet to the first host according to the received address information of the first host; and sending, by the first host on receipt of the synchronization data packet, a UDP data packet to the second host according to the received address information of the second host. 8. The method of Claim 1, wherein when the first host resides within the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT, and the second host resides within the domain of a Restricted Cone NAT or a Port-Restricted Cone NAT, sending by each of the first host and the second host a UDP data packet to the other on receipt of the synchronization data packet comprises: sending, by the first host on receipt of the synchronization data packet, a UDP data packet to the second host according to the received address information of the second host; and sending, by the second host on receipt of the synchronization data packet, a UDP data packet to the first host according to the received address information of the first host. 9. The method of any of CJaims 1-8, wherein the address information at least comprises a public network Internet Protocol, IP, address and port number. 10. The method of Claim 9, wherein the address information further comprises a local IP address and port number, 11. A system for establishing a Peer to Peer, P2P, connection, comprising a the server, on receipt of a synchronization request sent by the first host, sends to each of the first host and the second host a synchronization data packet which at least comprises the address information of the other of the first host and the second host; and each of the first host and the second host, on receipt of the synchronization data packet, sends a User Datagram Protocol, UDP, data packet to the other according to the received address information of the other. 12. A method for establishing a Peer to Peer, P2P, connection, comprising: acquiring, by a first host, from a server the address information of a second host and Network Address Translator, NAT, information of the network in which the second host resides; and if the second host resides in a public network or within the domain of a Full Cone NAT, sending, by the first host, a UDP data packet to the second host according to the acquired address information of the second host; and if the second host does not reside in a public network and does not reside within the domain of a Full Cone NAT, determining, by the first host, the NAT information of the network in which the first host resides; if the first host resides in a public network or within the domain of a Full Cone NAT, instructing, by the first host, the second host via the server to send a UDP data packet to the first host; and if the first host does not reside in a public network and does not reside within the domain of a Full Cone NAT, performing the following process: sending, by the first host, a synchronization request to the server on receipt of the synchronization request, sending, by the server, to each of the first host and the second host a synchronization data packet which at least comprises the address information of the other of the first host and the second host; and sending, by each of the first host and the second host, a UDP data packet to the other according to the received address information of the other on receipt of

Documents:

783-CHENP-2008 AMENDED PAGES OF SPECIFICATION 15-02-2013.pdf

783-CHENP-2008 AMENDED CLAIMS 08-11-2013.pdf

783-CHENP-2008 AMENDED CLAIMS 15-02-2013.pdf

783-CHENP-2008 AMENDED PAGES OF SPECIFICATION 08-11-2013.pdf

783-CHENP-2008 CORRESPONDENCE OTHERS 05-11-2012.pdf

783-CHENP-2008 EXAMINATION REPORT REPLY RECEIVED 08-11-2013.pdf

783-CHENP-2008 EXAMINATION REPORT REPLY RECEIVED 15-02-2013.pdf

783-CHENP-2008 FORM-1 08-11-2013.pdf

783-CHENP-2008 FORM-3 15-02-2013.pdf

783-CHENP-2008 OTHER PATENT DOCUMENT 15-02-2013.pdf

783-CHENP-2008 POWER OF ATTORNEY 15-02-2013.pdf

783-CHENP-2008 FORM-13 11-03-2010.pdf

783-chenp-2008-abstract.pdf

783-chenp-2008-claims.pdf

783-chenp-2008-correspondnece-others.pdf

783-chenp-2008-description(complete).pdf

783-chenp-2008-drawings.pdf

783-chenp-2008-form 1.pdf

783-chenp-2008-form 18.pdf

783-chenp-2008-form 3.pdf

783-chenp-2008-form 5.pdf