Abstract:
A method for constructing a network topology is applied in a streaming delivery system. The streaming delivery system includes: a center server (CS-P), an edge server (ES-P), a request scheduling server (RRS-P), and a client. The disclosed embodiments utilizes the upload capabilities of the client to transmit a part of streaming data, thus consuming fewer center server resources. By constructing the network topology, the disclosed embodiments enable the client to obtain a part of streaming data from other clients, reduces the load capability requirements for the server, and ensures that a streaming delivery network may provide streaming live services with higher bandwidths and better quality.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application is a continuation of International Application No. PCT/CN2008/071072, filed on May 23, 2008, titled “A METHOD FOR CLIENT NODE NETWORK TOPOLOGY CONSTRUCTION AND A SYSTEM FOR STREAM MEDIA DELIVERY”, which claims the priority of CN application No. 200710110570.6, filed on Jun. 5, 2007, titled “A METHOD FOR CLIENT NODE NETWORK TOPOLOGY CONSTRUCTION AND A SYSTEM FOR STREAM MEDIA DELIVERY”, the entire contents of all of which are incorporated herein by reference. 
    
    
     FIELD OF THE DISCLOSURE 
     The present disclosure relates to computer network technologies, and in particular, to a method for constructing a network topology, a streaming delivery system, and a method for system-related entities and clients to join the streaming delivery system. 
     BACKGROUND OF THE DISCLOSURE 
     A content/media delivery network (CDN/MDN) has emerged in the conventional art, delivering website contents from a source node to an edge node closest to a user so that the user may obtain desired contents proximately, thus increasing the response speed when the user visits a website. For multimedia content, such as video on demand (VoD) and live video, because video contents are transmitted in real time and large volumes, delivering video content to an edge node closest to a user assures better quality of play for the user and significantly reduces impact on the backbone network. 
     The structure of a CDN/MDN in the conventional art is shown in  FIG. 1 . The CDN/MDN includes: 
     a global server load balancer (GSLB), adapted to schedule a media content request of a user to an edge node closest to the user; 
     a server load balancer (SLB), responsible for routing the content requests of local users, balancing loads, and selecting a best media server (MS) according to the content distribution and device load conditions, and 
     a media manager (MM), adapted to deliver media contents and schedule MSs between the center and edges, between edges and within an edge node. 
     In the CDN/MDN structure shown in  FIG. 1 , because the MS bandwidth is fixed in an edge node, the edge node may only serve a limited number of users. To satisfy users&#39; needs, the capability of an edge node needs to increase linearly with the growth of users. Thus, for the CDN/MDN structure in the conventional art, huge investments are required in an edge node. Because service requests of a user are indefinite, even though the system capability of the edge node is increased, it is difficult to fully meet all abrupt rises of user requests. As a result, once the number of concurrent user requests in an area exceeds the maximum capacity of the network, the network may only reject the service. 
     At present, many pure peer to peer (P2P) steaming software systems are already available on the Internet. A common feature of these systems is that they are able to set up mutual aid relations between clients via a scheduling module in the network. Streaming servers in the network provide only a few streams and clients (peer nodes) deliver streaming data to each other by means of the above mutual aid relations so that a large number of clients may watch streaming programs at the same time. The scheduling module does not record topology relations of node networks, and the peer nodes help each other in a best-effort way. The inventor finds that the P2P streaming software system in the conventional art does not appear to consider geographic issues, which may result in a large volume of traffic across backbone networks. Moreover, because the scheduling module does not record the topology relations of node networks and does not provide unified resource scheduling, data delivery basically relies on the mutual aid of nodes. Therefore, channel switching may take a long time and programs of large streams may be difficult to support. In addition, the unsteady nodes and the best-effort help mode may also result in unstable playing of programs. 
     In conclusion, the streaming system based on client/server mode in the conventional art causes a heavy load on the MS, whether in center mode or center-edge distribution mode. The capability of the MS determines the number of users that are served at the same time. Thus, to meet the streaming application requirements of a large number of users, streaming service providers must pour huge investments in the server. For streaming live services based on P2P technology, because the server has limited resources and may provide only few streaming data and most of nodes rely on the upload capabilities of other nodes to watch video programs, it is difficult to guarantee the quality of service (QoS). In addition, due to limitation of upload capabilities, the P2P technology cannot provide live programs at a high bit rate. 
     SUMMARY 
     Disclosed embodiments provide a method for constructing a network topology and a streaming delivery system to increase the streaming transmission rate and improve the playing quality compared with the conventional art. 
     A method for constructing a network topology is provided. The method includes: 
     receiving a request sent from a client for joining a system; 
     returning information about available edge servers to the client, and returning IDs of specified data sub-streams transmitted by the client; and when determining that sub-trees corresponding to the specified data sub-streams have lower-level trunk nodes, returning information about the lower-level trunk nodes of the sub-trees, where the sub-trees are established in advance for the data sub-streams sent by a center server to the edge servers. 
     A streaming delivery system is provided. The system includes: 
     a center server, adapted to slice streaming data into multiple data sub-streams and send these data sub-streams; 
     an edge server, adapted to buffer the data sub-streams sent from the center server, and send the data sub-streams to a client node that joins the system; and 
     a request scheduling server, adapted to establish, store and update information about client network topologies and idle nodes, which specifically including the following operations: 
     receiving a request sent from the client for joining the system, returning information about available edge servers to the client, returning IDs of specified data sub-streams transmitted by the client, and returning information about lower-level trunk nodes of sub-trees when determining that the sub-trees corresponding to the specified data sub-streams have lower-level trunk nodes. 
     A request scheduling server is provided. The request scheduling server includes: 
     a receiving unit, adapted to receive a request initiated by a client for joining a system; and 
     an information delivering unit, adapted to: return information about available edge servers to the client, return IDs of specified data sub-streams transmitted by the client, and return information about lower-level trunk nodes of sub-trees when determining that the sub-trees corresponding to the specified data sub-streams have lower-level trunk nodes, where the sub-trees are established in advance for the data sub-streams sent by a center server to the edge servers. 
     A client is provided. The client includes: a joining system function unit, a exiting system function unit, 
     a joining system function unit, adapted to: initiate a request for joining a system to a request scheduling server, receive information returned by the request scheduling server, including information about edge servers, information about IDs of specified data sub-streams to be transmitted, information about lower-level trunk nodes of sub-trees corresponding to the specified data sub-streams, and information about idle nodes that transmit other data sub-streams; and send the received information about edge servers, IDs of specified data sub-streams, and information about lower-level trunk nodes to a trunk function unit, and send the received information about idle nodes to a leaf function unit; 
     a exiting system function unit, adapted to send a system exiting message to the request scheduling server and other connected clients, and disconnect the request scheduling server and other connected clients; 
     the trunk function unit, adapted to: establish connections with the edge servers or one of the lower-level trunk nodes with which the joining system function unit communicates, add the client to the sub-trees as a trunk node to receive the specified sub-streams, send the data sub-streams to a streaming playing unit, and transmit the specified data sub-streams to connected leaf nodes; 
     the leaf function unit, adapted to: establish connections with the idle nodes transmitting other data sub-streams sent by the joining system function unit, use the client as a leaf node of the sub-trees corresponding to other data sub-streams to receive other data sub-streams, and send the data sub-streams to the streaming playing unit; and 
     the streaming playing unit, adapted to combine the received data sub-streams into streaming data, and play the streaming data using a local player. 
     A method for a client to join a streaming delivery system according to some embodiments is provided: The method includes: 
     originating a request for joining the system to a request scheduling server, and receiving information, returned by the request scheduling server, about edge servers, IDs of specified data sub-streams transmitted, and information about lower-level trunk nodes returned when the request scheduling server determines that sub-trees corresponding to the specified data sub-streams have lower-level trunk nodes; 
     establishing connections with the edge servers or one of the lower-level trunk nodes, joining the sub-trees as a trunk node to receive the specified data sub-streams, and transmitting the specified data sub-streams to connected leaf nodes; and 
     when acting as a trunk node, reporting, to the request scheduling server, node status information that includes a trunk node connection relationship and information about whether the current node is idle. 
     A computer readable storage medium according to some embodiments may be adapted to store a computer program, where the computer program may enable the processor to carry out the following process: 
     receiving a request sent from a client for joining a system; and 
     returning information about available edge servers to the client, and returning IDs of specified data sub-streams transmitted by the client; when determining that sub-trees corresponding to the specified data sub-streams have lower-level trunk nodes, returning information about the lower-level trunk nodes of the sub-trees, where the sub-trees are established in advance for the data sub-streams sent by a center server to the edge servers. 
     A computer readable storage medium according to some embodiments may be adapted to store a computer program, where the computer program may enable the processor to carry out the following process: 
     originating a request for joining a system to a request scheduling server, and receiving information, returned by the request scheduling server, about edge servers, IDs of specified data sub-streams transmitted, and information about lower-level trunk nodes returned when the request scheduling server determines that sub-trees corresponding to the specified data sub-streams have lower-level trunk nodes; 
     establishing connections with the edge servers or one of the lower-level trunk nodes, joining the sub-trees as a trunk node to receive the specified data sub-streams, and transmitting the specified data sub-streams to connected leaf nodes; and 
     when acting as a trunk node, reporting, to the request scheduling server, node status information that includes a trunk node connection relationship and information about whether the current node is idle. 
     The disclosed embodiments may transmit a part of streaming data by constructing a network topology between clients, and reduce the load of the ES-P content server. Therefore, compared with the P2P streaming live networks, the embodiments provide live services with larger bandwidths and better quality. In addition, the streaming delivery network according to some embodiments avoids the impacts of long distance data transmission between the nodes on the backbone network during the P2P live cast, and limits the data transmission between the nodes to the network edge. This facilitates the mutual-aid downloading of streaming data between the nodes and recovers the network topology quickly when the nodes exit, reducing network disturbances effectively. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows a structure of a CDN/MDN in the conventional art; 
         FIG. 2  shows a structure of a streaming delivery system according to some embodiments; 
         FIG. 3  shows a structure of an RRS-P in a streaming delivery system according to some embodiments; 
         FIG. 4  shows a structure of a P2P client in a streaming delivery system according to some embodiments; 
         FIG. 5  shows another structure of a P2P client in a streaming delivery system according to some embodiments; 
         FIG. 6  shows a P2P network topology according to some embodiments; 
         FIG. 7  shows a process for a P2P client to join a streaming delivery system according to some embodiments; 
         FIG. 8  shows a process for a P2P client to join a streaming delivery system as a help node according to some embodiments; 
         FIG. 9  shows a process a P2P client to join the sub-trees in a P2P network topology as a leaf node according to some embodiments; and 
         FIG. 10  shows a process for a node to exit a streaming delivery system according to some embodiments. 
     
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
     Consistent with some embodiments, a network topology between clients is constructed, so that a client may obtain a part of streaming data (furthermore, the rest of streaming data may still be requested from a content server) from other clients. This lowers the load requirements for the server without affecting the QoS. A network topology is constructed between the clients to limit the connection between the clients in a partial network in some embodiments, thus guaranteeing the transmission quality and reducing the traffic across networks. 
     The following describes major principles, implementation modes, and benefits of the technical solution according to some embodiments with reference to the accompanying drawings. 
     The structure of a streaming delivery system according to some embodiments is shown in  FIG. 2 . The streaming delivery system includes: an end user portal (EU-Portal), a center server that supports P2P technology (CS-P), a request scheduling server that supports P2P technology (RRS-P), an edge server that supports P2P technology (ES-P), and multiple P2P clients. 
     The CS-P, RRS-P, and ES-P in the streaming delivery system are configured in the 1+1+N mode. In other words, one pair of CS-Ps, one pair of RRS-Ps and more than one ES-P are configured; the neighboring ES-Ps form a P2P autonomous domain; and each ES-P in a same edge P2P autonomous domain shares the received data sub-streams. 
     The EU-Portal is responsible for displaying and searching for streaming live contents to play different streaming programs on users&#39; demands. 
     The CS-P is adapted to slice the streaming data into multiple data sub-streams, and send the data sub-streams to the ES-P. The CS-P slices the streaming data into n data slices and generates m redundant slices by using a redundancy algorithm. After encoding the n data slices and m redundant slices into n+m independent data sub-streams, the CS-P sends these data sub-streams to the ES-P. Taking a 1 Mbps stream as an example, the traffic per second is sliced to 20 parts based on time and 22 packets are generated by using the Reed-Solomon algorithm. This means that the entire stream is sliced to 22 sub-streams, which are sent to the ES-P. 
     The ES-P is adapted to buffer the received data sub-streams, and send the sub-streams to a P2P client that joins the system. 
     The RRS-P is adapted to store the ES-P network topology, establish and store the P2P network topology. Each P2P network topology includes n+m sub-trees, where each sub-tree is adapted to transmit data sub-streams sent by a CS-P to the ES-Ps. The RRS-P is further adapted to store the information, reported by the P2P clients, about an idle node, where the idle node refers to a trunk node of which the quantity of connected leaf nodes does not reach a preset threshold. 
     The P2P client is adapted to: initiate a request for joining a system or a request for exiting a system to the RRS-P; receive the ES-P information returned by the RRS-P, IDs of specified data sub-streams transmitted by the P2P client, information about lower-level trunk nodes of the sub-trees returned when the RRS-P determines that the sub-trees corresponding to the specified data sub-streams have lower-level trunk nodes, information about idle nodes that transmit other data sub-streams returned when the RRS-P determines that there are idle nodes that transmit other data sub-streams and the P2P client requests joining the system as a watching node; join the sub-trees to receive and transmit the specified data sub-streams as a trunk node, establish connections with the returned idle nodes that transmit other data sub-streams, and receive other data sub-streams as a leaf node of the sub-trees corresponding to other data sub-streams; combine the received data sub-streams into streaming data, and play the combined streaming data using a local player. 
     Specifically, more than one ES-P is available in the system, and multiple neighboring ES-Ps form an edge P2P autonomous domain. Each ES-P in a same edge P2P autonomous domain shares the received data sub-streams. 
     Further, in the RSS-P, each streaming live channel stores a P2P network topology for each edge P2P autonomous domain. 
     Moreover, the RRS-P includes: 
     a receiving unit, adapted to receive a request for joining a system initiated by a client; 
     an information delivering unit, adapted to return the information about available ES-Ps to the client, return IDs of specified data sub-streams transmitted by the client, and return the information about the lower-level trunk nodes of the sub-trees when determining that the sub-trees corresponding to the specified data sub-streams have lower-level trunk nodes, where the sub-trees are established in advance for the data sub-streams sent by the CS-P server to the ES-Ps. 
       FIG. 3  shows a preferred RRS-P according to some embodiments, wherein the RRS-P includes a storing unit  101 , an interacting unit  102 , an updating unit  103 , and a detecting unit  104 . 
     The storing unit  101  is adapted to store the ES-P network topology, P2P network topology, and idle nodes information in the streaming delivery system. 
     The interacting unit  102  is adapted to receive a request for joining a system initiated by a P2P client, and return the information about available ES-Ps, information about lower-level trunk nodes of sub-trees corresponding to the specified data sub-streams transmitted by the P2P client, and information about idle nodes that transmit other data sub-streams, to the P2P client according to information, about the network topology and idle nodes, stored in the storing unit  101 . 
     The interacting unit  102  is further adapted to receive the node status information, reported by the P2P client after the P2P client joins the system, which includes a trunk node connection relationship and information about whether the current node is idle, and send the received node status information to the updating unit  103 ; receive an exiting system message sent from the P2P client, and send the received exiting system message to the updating unit  103 . 
     The updating unit  103  is adapted to update the P2P network topology and idle node information stored in the storing unit  101  according to the node status information and system exiting message sent from the interacting unit  102 . 
     The detecting unit  104  is adapted to detect whether the P2P client exits for exceptional reasons, and update the P2P network topology stored in the storing unit  101  when detecting that the P2P client exits for exceptional reasons. 
       FIG. 4  shows a P2P client according to some embodiments, where the P2P client includes a joining system function unit  201 , a exiting system function unit  202 , a trunk function unit  203 , a leaf function unit  204 , a streaming playing unit  205 , an information storing and updating unit  206 , and a reporting function unit  207 . 
     The joining system function unit  201  is adapted to initiate a request for joining a system to the RRS-P in the streaming delivery system, receive the information returned by the RRS-P, including ES-P information, information about lower-level trunk nodes of the sub-trees corresponding to the specified data sub-streams transmitted by the P2P client, and information about idle nodes that transmit other data sub-streams, and send the received ES-P information and information about lower-level trunk nodes to the trunk function unit  203 , and the received information about idle nodes to the leaf function unit  204 . 
     The exiting system function unit  202  is adapted to send a exiting system message to the RRS-P and other connected P2P clients, and disconnect these connections; receive the exiting system messages sent from other P2P clients; and notify the information storing and updating unit  206 . 
     The trunk function unit  203  is adapted to establish connections with the ES-Ps or one of the lower-level trunk nodes sent by the joining system function unit  201 , add the P2P client to the sub-trees as a trunk node to receive the specified data sub-streams, send the data sub-streams to the streaming playing unit  205 , transmit the specified data sub-streams to the connected leaf nodes, and send the trunk node connection relationship and quantity of connected leaf nodes to the information storing and updating unit  206 . 
     The leaf function unit  204  is adapted to: establish connections with the idle nodes transmitting other data sub-streams that are sent by the joining system function unit  201 , use the client as a leaf node of the sub-trees corresponding to other data sub-streams to receive other data sub-streams, and send the data sub-streams to the streaming playing unit  205 . 
     The streaming playing unit  205  is adapted to combine the received data sub-streams into streaming data, and play the streaming data using a local player. 
     The information storing and updating unit  206  is adapted to receive the notification sent from the exiting system function unit  202  and the trunk node connection relationship sent from the trunk function unit  203 ; update and store the upper-level trunk node information about the trunk; determine whether the current node is idle according to the quantity of connected leaf nodes; receive, store or send the upper-level trunk node information to the trunk child nodes, and receive, store or send the idle node information to upper-level and lower-level trunk nodes and leaf nodes. 
     The reporting function unit  207  is adapted to obtain the trunk node connection relationship and information about whether the current node is idle from the information storing and updating unit  206 , and report the node status information that includes the trunk node connection relationship and information about whether the current node is idle to the RRS-P. 
     Specifically, the joining system function unit  201  shown in  FIG. 5  includes: 
     a first function sub-unit  2011 , adapted to initiate a request for joining a system to the RRS-P, where the request indicates that the P2P client joins the system as a watching node; receive the information returned by the RRS-P, including ES-P information, information about idle nodes that transmit other data sub-streams, and information about lower-level trunk nodes of the sub-trees corresponding to the specified data sub-streams transmitted by the P2P client; send the received ES-P information and information about lower-level trunk nodes to the trunk function unit  203 , and the received information about idle nodes to the leaf function unit  204 ; and 
     a second function sub-unit  2012 , adapted to initiate a request for joining a system to the RRS-P, where the request indicates that the P2P client joins the system as a help node; receive the information returned by the RRS-P, including ES-P information and information about lower-level trunk nodes of the sub-trees corresponding to the specified data streams transmitted by the P2P client; and send the received ES-P information and information about lower-level trunk nodes to the trunk function unit  203 . 
     A method for constructing a network topology according to some embodiments may include: 
     receiving a request sent from a client for joining a system; and 
     returning the information about available ES-Ps to the client, and returning IDs of specified data sub-streams transmitted by the client; when determining that sub-trees corresponding to the specified data sub-streams have lower-level trunk nodes, returning the information about the lower-level trunk nodes of the sub-trees, where the sub-trees are established in advance for the data sub-streams sent by the CS-P to the ES-Ps. 
     Further, a preferred method for constructing the P2P network topology is as follows: 
     The RRS-P establishes multiple sub-trees for the data sub-streams sent by the CS-P to the ES-Ps. Each sub-tree is used to transmit a data sub-stream and includes one or more trunks. Each trunk node includes only one trunk child node. Each trunk child node is connected to one or more leaf nodes. Each trunk node and leaf node serve as a P2P client. A P2P client is used as a trunk node of only one trunk, but may be used as a leaf node of multiple sub-trees. 
     After receiving the request for joining a system from the P2P client, the RRS-P returns the information about available ES-Ps, IDs of specified data sub-streams transmitted by the P2P client, information about lower-level trunk nodes (if any) of the sub-trees corresponding to the specified data sub-streams, and information about idle nodes (if any) that transmit other data sub-streams, to the P2P client. 
     After joining the sub-trees, the P2P client reports the node status information that includes a trunk node connection relationship and information about whether the current node is idle to the RRS-P according to the information about connected trunk nodes and quantity of leaf nodes. After receiving the node status information reported by the P2P client, the RRS-P updates the locally stored P2P network topology and information about idle nodes. 
     After receiving a system exiting message sent from the P2P client, the RRS-P updates the locally stored P2P network topology. 
     Specifically, the RRS-P establishes n sub-trees according to n (the quantity of) data sub-streams sent by the CS-P to the ES-Ps, where each sub-tree is used to transmit a data sub-stream. 
     The initial values of the trunk nodes and leaf nodes of each sub-tree are null. The RRS-P specifies n P2P clients that are connected first as the first trunk nodes of the sub-trees that transmit each data sub-stream. The RRS-P also returns the information about available ES-Ps, information about specified data sub-streams transmitted by the P2P clients, and information about idle nodes that transmit other data sub-streams. 
     The RRS-P sets the threshold for the quantity of trunk nodes of each sub-tree. When receiving a request for joining a system from a P2P client, the RRS-P specifies a sub-tree for the P2P client to join, and checks whether the quantity of trunk nodes of the sub-tree reaches the preset threshold. If the quantity of trunk nodes of the sub-tree does not reach the preset threshold, the RRS-P returns the information about lower-level trunk nodes of the sub-tree. 
     If the quantity of trunk nodes of the sub-tree reaches the preset threshold, the RRS-P instructs the P2P client to obtain the specified data sub-streams that are transmitted from the returned ES-Ps, and creates trunks. 
     In this embodiment, the original streaming data is encoded into multiple independent sub-streams, for example, s 1 , s 2 , s 3 , . . . , sn, and each sub-stream is transmitted by constructing an independent topology. The topology tree that transmits sub-stream s 1  is called sub-tree s 1 , and the topology tree that transmits sub-stream sn is called sub-tree sn. To watch streaming programs, a P2P client needs to join multiple sub-trees to obtain different sub-streams of streaming data, and decodes the sub-streams into original media data. 
       FIG. 6  shows a network topology of a P2P client according to some embodiments. Streaming data stream s is divided into three independent sub-streams s 1 , s 2  and s 3 , which form sub-trees s 1 , s 2  and s 3 . In sub-tree s 1 , nodes  1 ,  4 ,  7 , and  10  are trunk nodes; in sub-tree s 2 , nodes  2 ,  5 ,  8  and  10  are trunk nodes; in sub-tree s 3 , nodes  3 ,  6 ,  9  and  12  are trunk nodes. Each trunk node has a unique trunk child node. Taking sub-tree s 1  as an example, trunk node  1  is the trunk parent node of trunk node  4 ; trunk node  7  is the trunk child node of trunk node  4 ; and trunk node  4  has a unique trunk parent node  1  and a unique trunk child node  7 . 
     Nodes  2 ,  3 ,  5 ,  6 ,  8 ,  9 ,  11  and  12  are the leaf nodes of sub-tree s 1 . The leaf nodes may obtain sub-stream s 1  only through the trunk node, but cannot forward sub-stream s 1 . For example, in  FIG. 6 , nodes  2  and  3  establish connections with trunk node  1  of sub-tree s 1 , and act as the leaf nodes of node  1  to obtain sub-stream s 1  from node  1 . 
     To join the system as a watching node, the trunk nodes of sub-tree s 1  still need to obtain sub-streams s 2  and s 3  and act as the leaf nodes of sub-trees s 2  and s 3  so as to obtain the complete data stream. In  FIG. 6 , node  1  joins sub-tree s 2  to obtain sub-stream s 2  and acts as a leaf node of sub-tree s 2 , and its leaf parent node is trunk node  2  of sub-tree s 2 . In addition, node  1  also joins sub-tree s 3  and acts as a leaf node of sub-tree s 3 , and its leaf parent node is trunk node  3  of sub-tree s 3 . 
     Leaf nodes  2 ,  3 ,  5 ,  6 ,  8 ,  9 ,  11  and  12  of sub-tree s 1  are also trunk nodes of sub-tree s 2  or s 3 . Certainly, these nodes may not act as trunk nodes of any sub-tree but only act as the leaf nodes of each sub-tree to obtain sub-streams from the trunk nodes. 
     If a node cannot obtain all the data sub-streams from other nodes in P2P mode, the node requests the data sub-streams from the ES-P. 
     Based on the streaming delivery system and P2P network topology according to the preceding embodiments, this embodiment may provide a method of joining a streaming delivery system by a P2P client. As shown in  FIG. 7 , this method includes the following steps: 
     Step 1: P2P client N 1 , as a watching node, requests joining a live channel of the P2P network. P2P client N 1  sends a request for joining a system to the RRS-P, where the request carries the live channel to be joined, and IP address and port number of N 1 . 
     The RRS-P needs to judge whether the IP address and port number carried in the request sent by node N 1  are the same as the actual ones of N 1 . If the IP address and port number carried in the request sent by node N 1  are not the same as the actual ones of N 1 , N 1  is connected as a private network node after network address translation (NAT), and cannot receive connection requests. Thus, N 1  cannot act as a trunk node to forward data sub-streams to other P2P clients, but may only receive and watch streaming programs. If the IP address and port number carried in the request sent by node N 1  are the same as the actual ones of N 1 , N 1  is a public network node and may receive connection requests and act as a trunk node to forward data sub-streams. 
     Step 2: According to the actual IP address of N 1 , the RRS-P selects one or more ES-Ps that are closer to N 1  in the network and have idle resources, and returns the ES-P information to N 1 . Generally, the RRS-P may select an ES-P with idle bandwidths and light CPU loads that is in the autonomous domain of N 1 . 
     If N 1  is a public network node, the RRS-P may further specify the data sub-streams that are delivered by N 1 . For example, if the RRS-P specifies N 1  to deliver sub-stream s 1 , that is, it specifies N 1  to join sub-tree s 1  as a trunk node, the RRS-P needs to return the information about lower-level trunk nodes of sub-tree s 1  that are in the autonomous domain of N 1  to N 1 . To control transmission delay, there cannot be too many trunk node levels in each sub-stream. Thus, each sub-stream may have multiple trunks, and there may be multiple lower-level trunk nodes. The RRS-P needs to return a certain number of lower-level trunk nodes of sub-tree s 1  to N 1 . The trunk levels need to be considered when the RRS-P returns the lower-level trunk nodes. For trunks with more than a certain number of levels, the RRS-P may not return the lower-level trunk nodes to N 1 . For other sub-trees, because N 1  does not need to deliver the sub-streams that are transmitted by the sub-trees, the RRS-P may freely select some idle nodes (must be trunk nodes with the quantity of connected leaf nodes lower than the preset threshold) in the autonomous domain of N 1 , and return the selected nodes to N 1 . 
     Step 3: N 1  requests joining the lower-level trunk nodes of the specified sub-trees as a trunk child node. In this embodiment, N 1  attempts to join sub-tree s 1  to obtain sub-stream s 1 . N 1  establishes connections with the lower-level trunk nodes of sub-tree s 1  in the returned information (because a sub-tree may have multiple trunks, the RRS-P may return one or more lower-level trunk nodes), and then requests joining these lower-level trunk nodes in turn as a trunk child node. 
     If no trunk child node is available in a lower-level trunk node that N 1  requests joining, the lower-level trunk node accepts the request of N 1 . N 1  disconnects the connections with other lower-level trunk nodes, and reports its own connection relationship to the RRS-P. If a trunk child node is already available in a lower-level trunk node, the lower-level trunk node returns the information about the trunk child node to N 1 . N 1  adds the trunk child node to the list of candidate nodes, and attempts to establish a connection with the trunk child node. The preceding process is repeated until a trunk node accepts the connection request of N 1 . 
     After joining as a trunk child node, N 1  receives the information about one or multiple upper-level trunk nodes sent from a trunk parent node, stores the information, and forwards the information to other trunk child nodes. 
     The level of a trunk node that forwards the node information about an upper-level trunk node may be set according to requirements. For example, a time to live TTL value may be carried in the node information (including IP address and port number information) of each trunk node. After each trunk node receives the node information about one or more upper-level trunk nodes sent from the trunk parent node, the TTL value is decreased by 1. When the TTL value is greater than 0, the trunk node forwards the node information to the trunk child nodes; when the TTL value is equal to 0, the trunk node stops forwarding the node information to the trunk child nodes. Each trunk node determines its own trunk parent node and other upper-level trunk nodes according to the received information about one or more upper-level trunk nodes and the carried TTL value. 
     For example, supposing each trunk node may store information about four upper-level trunk nodes at most, the following shows the storage format: 
     ((Parent node IP address/port number, 3), (Grandparent node IP address/port number, 2), (Great-grandparent node IP address/port number, 1), (Great-great grandparent node IP address/port number, 0)). 
     The TTL values corresponding to the parent node, grandparent node, great grandparent node, and great-great grandparent node are 3, 2, 1, and 0. 
     If no lower-level trunk node receives the requests of N 1  due to failures of all the lower-level trunk nodes or because N 1  fails to connect to all the lower-level trunk nodes, or if the RRS-P does not return the information about lower-level trunk nodes of sub-tree s 1  (at the beginning of establishment of the P2P network topology, the RRS-P cannot return the information about lower-level trunk nodes because no node has joined sub-tree s 1  and s 1  does not have trunk nodes), N 1  requests sub-stream s 1  from the ES-P returned by the RRS-P. 
     Step 4: N 1  requests joining the trunk nodes of other sub-trees as a leaf node. The details are as follows: 
     N 1  establishes connections with idle nodes of other sub-trees in the information returned by the RRS-P, and requests joining the idle nodes as a leaf node. If a requested node is idle, it accepts N 1  as its leaf node; otherwise, it rejects the request of N 1 . 
     Specifically, a requested trunk node accepts the join request of N 1  based on the quantity of accepted leaf nodes. If the quantity of leaf nodes connected to the trunk node already reaches the preset threshold, the trunk node is not idle and cannot accept new leaf nodes. If the quantity of leaf nodes connected to the trunk node does not reach the preset threshold, the trunk node establishes a connection with N 1  and accepts N 1  as its own leaf node. 
     Moreover, when a trunk node turns from an idle node into a non-idle node after accepting new leaf nodes or when a trunk node turns from a non-idle node to an idle node after some connected leaf nodes exit, the trunk node needs to notify the RRS-P, its trunk parent node and trunk child nodes. When there are new nodes that request joining the system, the RRS-P may return the stored idle nodes to the nodes. In a same trunk, when a trunk node receives the information about idle nodes sent or forwarded by the trunk parent node, the trunk node forwards the received information to lower-level trunk nodes; when a trunk node receives the information about idle nodes sent or forwarded by a trunk child node, the trunk node forwards the received information to upper-level trunk nodes. In this way, each trunk node may know whether multiple nodes are idle. When there are new nodes joining the system as leaf nodes, the trunk node sends the information about known idle nodes to the connected leaf nodes, and also forwards received information about idle nodes to the connected leaf nodes. Thus, a leaf node may timely and accurately know the information about some idle nodes that obtain a sub-stream. When a trunk node connected to the leaf node exits or fails, the leaf node may request the sub-stream from these idle nodes, without requesting the RRS-P, thus reducing the load of the RRS-P. 
     If N 1  fails to find a trunk node to which N 1  is connected as a leaf node after several attempts, N 1  requests the related sub-stream from the ES-P. 
     If N 1  is not a public network node, N 1  may attempt to join all sub-trees as a leaf node, and obtain the sub-streams. 
     Step 5: After joining sub-tree s 1 , N 1  becomes a lower-level trunk node of sub-tree s 1 . N 1  needs to report its information to the RRS-P, including the trunk node connection relationship and information about whether N 1  is idle. In addition, some bandwidths need to be reserved to accept trunk child nodes. N 1  may also accept other nodes as leaf nodes. 
     What has been described above is a major process of joining a network as a watching node by N 1 . In fact, N 1  may also join the network as a help node. When acting as a help node, N 1  may only serve as a trunk node of a sub-stream, and does not need to join other sub-trees to obtain other sub-streams. 
       FIG. 8  shows a process of joining a system as a help node by a P2P client. The process includes the following steps: 
     Step 1: A P2P client N 1  requests joining a P2P network to help to deliver data. N 1  sends a message to the RRS-P, where the message carries the IP address and port number of N 1 . 
     Step 2: According to the actual IP address of N 1 , the RRS-P selects one or more ES-Ps that are closer to N 1  in the network and have idle resources, and returns the ES-P information to N 1 . Generally, the RRS-P may select an ES-P with idle bandwidths and light CPU loads that is in the autonomous domain of N 1 . 
     The RSS-P may further specify channels and sub-streams that N 1  helps to deliver. For example, if the ES-P specifies N 1  to deliver sub-stream s 1  of a channel, that is, it specifies N 1  to join sub-tree s 1  as a trunk node, the RRS-P needs to return the information about lower-level trunk nodes of sub-tree s 1  that is in the autonomous domain of N 1  to N 1 . 
     To avoid transmission delay, there cannot be too many trunk node levels in each sub-stream. Thus, each sub-stream may have multiple trunks, and there may be multiple lower-level trunk nodes. The RRS-P needs to return a certain number of lower-level trunk nodes of sub-tree s 1  to N 1 . The trunk levels need to be considered when the RRS-P returns the lower-level trunk nodes. For trunks with more than a certain number of levels, the RRS-P may not return the lower-level trunk nodes to N 1 . 
     Step 3: N 1  requests joining the lower-level trunk nodes of a specified sub-tree as a trunk child node. N 1  attempts to join s 1  sub-tree, and establishes connections with the lower-level trunk nodes (one or more) of sub-tree s 1  in the information returned by the RRS-P, and then requests joining these lower-level trunk nodes in turn as a trunk child node. 
     If no trunk child node is available in the lower-level trunk nodes that N 1  requests joining, the lower-level trunk nodes accept the request of N 1 . N 1  disconnects the connections with other lower-level trunk nodes, and reports its own connection relationship to the RRS-P. If a trunk child node is already available in a lower-level trunk node that N 1  requests joining, the lower-level trunk node returns the information about the trunk child node to N 1 . N 1  continues to connect to the trunk child node. The preceding process is repeated until a trunk node accepts the connection request of N 1 . 
     If no lower-level trunk node receives the requests of N 1  due to failures of all the lower-level trunk nodes or because N 1  fails to connect to all the lower-level trunk nodes, or if the RRS-P does not return the information about lower-level trunk nodes of s 1 , N 1  requests sub-stream s 1  from the ES-P returned by the RRS-P. 
     Step 4: After joining sub-tree s 1 , N 1  becomes a lower-level trunk node of sub-tree s 1 . Thus, some bandwidths need to be reserved to accept the join requests of trunk child nodes. N 1  may also accept other nodes as leaf nodes. 
     To ensure that these help nodes may use other network applications normally, the help nodes may only occupy some bandwidths as upload bandwidths, that is, the help nodes accept only a preset quantity of leaf nodes and provide sub-streams for such leaf nodes. For example, many users access to the Internet through ADSL, with a common uplink bandwidth of 512 Kbps. The help nodes may be specified to occupy a maximum bandwidth of 250 Kbps for sub-stream delivery. 
     After becoming a trunk node of a sub-tree, N 1  reports the node status information to the RRS-P, including the trunk node connection relationship, information about whether the current node is idle, and information about whether the node is a help node. 
       FIG. 9  shows a process of joining a sub-tree as a leaf node by a new node or a private network node. The process includes the following steps: 
     Step 1: A new P2P client N 1  sends a connection request to idle nodes of sub-trees s 1 , s 2  to sn. 
     Step 2: N 1  requests joining the connected trunk nodes of each sub-tree as a leaf node. 
     If no idle node responds to the connection request of N 1 , that is, no idle node is connected to N 1  successfully, the connection fails. Then the process of joining the network as a leaf node ends. 
     Step 3: If a requested idle node agrees to accept N 1  as a leaf node, the idle node returns a response of agreeing N 1  to join and information about other locally stored idle nodes to N 1 , and forwards received information about idle nodes to all the connected leaf nodes. Thus, a leaf node may timely and accurately know the information about some idle nodes that obtain a sub-stream. When a trunk node connected to the leaf node exits or fails, the leaf node may request the sub-stream from these idle nodes, without requesting the RRS-P, thus reducing the load of the RRS-P. 
     If a requested trunk node rejects the request of N 1 , N 1  disconnects the connection with the trunk node, and deletes the trunk node from the list of candidate idle nodes. Then, N 1  goes back to step 2 and continues to send a join request to other idle nodes. 
     Step 4: If the quantity of leaf nodes connected to the trunk node reaches the preset threshold and the trunk node changes from an idle node to a non-idle node after N 1  joins the trunk node, the trunk node needs to notify the RRS-P, trunk parent node and trunk child nodes. 
     Step 5: N 1  accesses the network as a connected leaf node of the trunk node agreeing N 1  to join, and disconnects connections with other idle nodes. 
     In practical applications, after receiving a request for joining a system from a P2P client, the RRS-P may not schedule the request to the trunk if it detects that the number of levels in a trunk reaches a certain threshold. If the number of levels in each trunk of a sub-tree reaches the preset threshold, the RRS-P does not return the information about lower-level trunk nodes to the new nodes that join the system. At this time, the new nodes request the related data sub-streams from the returned ES-P. 
     Accordingly, some embodiments may provide a method for a node to exit a network.  FIG. 10  shows a process of handling the disconnection or exit of a trunk parent node by a node. The process includes the following steps: 
     Step 1: P2P clients N 1 , N 2  and N 3  are trunk nodes of sub-tree s 1 , where N 2  is the trunk parent node of N 1  and N 3  is a trunk child node of N 1 . N 4  is the leaf parent node of N 1 , and N 5  is a leaf node of N 1 . 
     When node N 1  exits or is disconnected normally, N 1  sends an exiting message to the RRS-P, all the parent nodes and child nodes. Trunk child node N 3  and leaf node N 5  of N 1  may receive the exiting message from N 1 . N 3  and N 5  may also detect the failure of connection with N 1  by scanning the connection status of N 1 . 
     Step 2: Node N 3  adds the upper-level trunk nodes, that is, trunk parent node N 2  and trunk nodes at all levels above N 2 , to the list of candidate nodes, and sends a request for joining as a trunk child node to N 2  and upper-level trunk nodes of N 2  in turn. The request sequence is as follows: N 2 , parent node of N 2 , and grandparent node of N 2  send a request to the upper-level trunk nodes of a sub-tree in turn. 
     After receiving the exiting message from N 1  or detecting that N 1  exits, the RRS-P deletes N 1  related information from the trunk topology data of N 1 . 
     After receiving the exiting message from N 1  or detecting that N 1  exits, trunk parent node N 2  deletes the connection information about N 1 , so that N 2  may accept the requests of other nodes for joining as trunk child nodes. 
     After receiving the exiting message from N 1  or detecting that N 1  exits, a leaf parent node N 4  of N 1  deletes N 1  related information. Further, the leaf parent node needs to judge whether the quantity of connected leaf nodes is smaller than the preset threshold. If so, the leaf parent node determines that it changes to an idle node, and notifies the RRS-P, trunk parent nodes and trunk child nodes. The RRS-P updates the information about locally stored idle nodes. The trunk parent nodes and trunk child nodes of N 4  update the information about locally stored idle nodes, and forward the updated information to upper-level/lower-level trunk nodes and connected leaf nodes. 
     After receiving the exiting message or detecting that N 1  exits, leaf node N 5  of N 1  attempts to obtain sub-streams from the locally recorded idle trunk nodes of sub-tree s 1 . The data of locally recorded idle trunk nodes of each sub-tree has two sources: data returned by the RRS-P at system access and data of idle nodes obtained from N 1 . If the locally recorded idle trunk nodes cannot provide sub-stream s 1 , leaf node N 5  requests the information about idle trunk nodes from sub-tree s 1 , and then requests joining these nodes to obtain the sub-stream. If N 5  still cannot obtain sub-stream s 1 , it requests sub-stream S 1  from the ES-P. 
     Step 3: After receiving a connection request from N 3 , N 2  receives the request of N 3  for joining as a trunk child node if no trunk child node is available. If N 2  rejects the request of N 3 , N 2  returns a reject message to N 3 . N 3  reports the failure of N 2  to the RRS-P, and continues to send a join request to the upper-level trunk nodes of N 2 . 
     After receiving the join request from N 3 , the upper-level trunk nodes report the information about idle nodes to N 3 . 
     If N 3  fails to establish connections with the upper-level trunk nodes and join the sub-tree as a trunk child node after several attempts, N 3  requests the sub-stream from the ES-P. The number of attempts to establish connections is set according to the number of upper-level trunk nodes stored in each trunk node; for example, each trunk node may be set to store a maximum of four upper-level trunk nodes. The format is as follows: 
     ((Parent node IP address/port number, 3), (Grandparent node IP address/port number, 2), (Great-grandparent node IP address/port number, 1), (Great-great grandparent node IP address/port number, 0)). Thus, a maximum of three attempts may be made. 
     Step 4: N 3  reports the node status information to the RSS-P, including the established trunk connection relationship and information about whether nodes at each level are idle. 
     After the new trunk connection relationship is established, N 3  updates the information about its own upper-level trunk nodes, and sends the updated information to the connected trunk child nodes. 
     When N 1  exits the system, N 1  notifies leaf parent node N 4 . When receiving the exit notification of N 1  or detecting that N 1  exits, N 4  needs to judge whether the quantity of connected leaf nodes is smaller than the preset threshold. If so, N 4  determines that it changes to an idle node, and notifies the RRS-P, trunk parent nodes and trunk child nodes. The RRS-P updates the information about locally stored idle nodes. The RRS-P updates the information about locally stored idle nodes. Trunk parent nodes and trunk child nodes of N 4  update the information about locally stored idle nodes, and forward the updated information to upper-level/lower-level trunk nodes and connected leaf nodes. 
     Therefore, in some embodiments, by using constructing the P2P network topology and utilizing the upload capabilities of P2P clients to transmit a part of streaming data between the P2P clients, the content server resources may be saved. In addition, the RRS-P constructs the P2P network topology, specifies the transmitted data sub-streams and sends information about idle nodes on a unified basis, and limits the connection between the P2P clients in a partial network, thus guaranteeing the transmission quality and reducing cross-network transmission traffic. 
     All or part of the disclosed embodiments may be implemented through software programming. The software program may be stored in a readable storage medium, such as a hard disk, a compact disk, or a floppy disk. 
     It is apparent that those skilled in the art may make various modifications and variations to the disclosed embodiments without departing from the scope of the embodiments. The disclosed embodiments are intended to cover these modifications and variations provided that they fall in the scope of protection defined by the following claims or their equivalents.