CN1314250C - A robust point to point based stream scheduling method - Google Patents

Abstract

The invention belongs to the technical field of information dissemination, and relates to a robust point-to-point flow scheduling method. In this method, a scheduling server, a streaming media server, and client nodes form a live network, and different definitions are given according to the functions of each client node in the network. In the network, each client node is assigned a different Function. The request of new client nodes to join and the exit of client nodes cause changes in the network topology. Flow scheduling is realized by dynamically updating and monitoring the network topology table and changing the functions of some client nodes. This method combines the advantages of P2P technology, IP multicast technology and network proxy technology, and tries to save network bandwidth to the greatest extent. In this method, multi-data source technology is used to enhance the robustness of multicast network. At the same time, the low correlation of multiple data sources provides favorable conditions for error recovery such as retransmission.

Description

A Robust Peer-to-Peer Stream Scheduling Method

technical field

The invention belongs to the technical field of information dissemination, and in particular relates to a highly robust P2P flow scheduling method based on a live broadcast network environment.

Background technique

With the development of the Internet, especially the rapid popularization of broadband services, people are no longer satisfied with simple information such as text and images. And there are more and more demands for media services such as video and audio with richer content. Multimedia content in the network, especially continuous media content (video and audio), that is, streaming media content is increasing rapidly. Streaming media is an interdisciplinary subject of multimedia and network communication. In streaming media applications, the content provider splits and packages the compressed video data and transmits it to the receiver through the network in a "stream" manner. The receiver reassembles and decodes the received data packets while receiving the data. , play. This transmission mode is fundamentally different from other transmission modes in the network.

Video multicast, a new type of network service, needs to realize point-to-multipoint communication on the network. At present, various services on the Internet generally adopt a client/server structure, or IP unicast. This service model has a simple structure and is easy to implement, and it has played a huge role in the popularization of computer networks. However, as the scale of network services becomes larger and larger, the disadvantages of this structure become more and more obvious: in order to serve more customers, it requires more and more powerful servers, and requires more and more bandwidth at the server-side network egress. higher. Especially in the field of video services, since the bit rate of video streams is often very high, generally at least hundreds of kilobits per second (kbits/s), the pressure on the server is very heavy, and it can hardly meet the increasing user needs. Especially in video multicast, the server is actually sending the same video data to a large number of clients, which not only brings extra burden to the server, but also is a great waste of bandwidth resources. That is to say, the computing performance and network bandwidth of the server have become the main bottlenecks.

In view of the many problems existing in IP multicast, the idea of realizing multicast function at the application layer was put forward. This is the so-called application layer multicast, and its basic idea is to implement the multicast function at the application layer. However, most of the application layer multicast uses reliable servers installed in various parts of the network to complete the multicast task, and maintaining these servers requires a lot of cost.

Contents of the invention

The purpose of the present invention is to propose a kind of robust point-to-point stream dispatching method for overcoming the deficiencies in the prior art, this method has synthesized the advantages of P2P technology, IP multicast technology and network agent technology, strives to maximize Saves network bandwidth. In this method, multi-data source technology is used to enhance the robustness of multicast network. The low correlation of multiple data sources provides favorable conditions for error recovery such as retransmission.

A robust P2P-based flow scheduling method proposed by the present invention includes a networking method and a scheduling method, wherein the networking method includes the following steps:

(1) In the live broadcast network, the scheduling server (Trace Server) finds other client nodes for the client node (Peer), and notifies the streaming server (Streaming Server) to provide media streams to the client node;

(2) The streaming media server provides a stable media stream to the client node;

(3) The client node receives the media stream from the streaming media server or the client node that provides the media stream, and buffers the media stream. While the client node is playing the media stream data, the peer-to-peer (P2P) method is used to Provide media streams to other client nodes;

(4) If the client node in step (3) provides media streams to other client nodes during the P2P transmission process, the client node is called a supplying peer of media streams, otherwise the The client node is called the underlying client node (leaf peer);

(5) If the client node in step (3) receives the media stream from the streaming media server or the client node that provides the media stream during the P2P transmission process, the client node is called the client receiving the media stream end node (receiving peer);

(6) If the client node in step (3) is located in a certain subnet and provides media streams to other client nodes, then the client node is called a multicast client node (multicasting peer);

(7) If the client node in step (3) is located inside a certain subnet, it only receives media streams from other multicast client nodes in the same subnet, and does not provide media to other clients outside the subnet. flow, the client node is called a multicast receiving client node (multicasting receiver);

(8) The client node in the step (3) can be the client node providing the media flow, the client node receiving the media flow and the multicast client node simultaneously, but as long as it is the client node providing the media flow, One of the client node receiving media stream and the multicast client node, it cannot be the multicast receiving client node;

(9) The client node in the step (3), if requesting to join the live network, then the client node is called the requesting client node (requesting peer);

(10) The client node in step (3), if it is requesting or has forcibly withdrawn from the live broadcast network, then the client node is called a quitting client node (quitting peer);

(11) the client node in the step (3), if directly obtain media stream from streaming media server, then this client node is called seed client node (seed peer);

(12) The streaming media server is located at the 0th layer (layer) of the network; the seed client node is located at the 1st layer of the network; if a certain client node is provided with media streams by several client nodes providing media streams, then Its level in the network is the largest level plus one among all client nodes that provide media streams; if a certain client node is provided by a multicast client node, its level is the multicast client node The level plus one; the level sequence number in the network is used to estimate the delay of the media stream in the network;

The scheduling method includes the following steps;

(13) When a new client node applies to join the live broadcast network, it must be connected with the scheduling server first, and the client node or multicast client node that provides the media stream is allocated by the scheduling server to provide the media stream for it (the scheduling The server cannot provide any multicast receiving client node to the client node requesting to join, so as not to cause abnormally large output traffic of the subnet);

(14) When a certain client node exits the live broadcast network, the scheduling server should select a multicast receiving client node or bottom client node to replace the exiting client node according to the current network topology (if the scheduling server chooses the bottom client node For end nodes, the one with the largest number of layers is generally selected, and the selection can also be made taking into account information such as distance and delay);

(15) The scheduling server keeps a detailed record of the topology network topology table of the network. When a client node joins or exits the network (that is, the network topology changes), the network topology table is also dynamically updated in real time;

(16) In the scheduling process of the scheduling server, the level number of the client node providing the media stream of each client node is smaller than the level number of the client node (thus ensuring that the scheduling server does not generate loops during the flow scheduling process). Shaped network structure, to ensure that each client node can directly or indirectly obtain the latest media stream data from the streaming media server);

(19) During the scheduling process of the scheduling server, assign each client node that cannot provide media streams to the bottom end of the live broadcast network, making it a bottom client node;

(20) There are multiple channel processing in the live broadcast environment, multiple scheduling servers can be run at the same time, and different ports can be opened on the same scheduling server to support it. Each scheduling server or each port maintains its own network logically .

In the above step (13), when a new client node applies to join the live broadcast network, the scheduling method of the scheduling server specifically includes the following steps:

(13.1) If there is no or only one other client node in the subnet where the client node requesting to join is located (it can be considered that the client node requesting to join is not in the subnet), then the scheduling server sends the client node requesting to join Allocate several (the number can be relatively large) client nodes or streaming media servers outside the subnet to the client nodes that request to join as the candidate client nodes (Supplying Candidates) that provide media streams, and the client nodes that request to join are compared (such as comparing the delay between them, comparing their historical information, etc.), select several client nodes as the client nodes that provide media streams, and the client nodes that request to join work in P2P mode (Peer-to -Peer Mode);

(13.2) If there are 2 or more client nodes in the subnet where the client node requesting to join, then the P2P mode (method as described in step (13.1)) can be used, or the multicast mode (MulticastingMode ) into the entire live broadcast network;

(13.3) In step (13.2), if the client node requesting to join joins the live network by multicast, then determine the new client node to join according to whether there are other multicast receiving client nodes in the original subnet scheduling method;

(13.4) In step (13.3), if there are other multicast receiving client nodes in the subnet, the scheduling server will inform all multicast clients in the subnet of the address and port number of the client node requesting to join End nodes, each multicast client node adds the information of the client node requesting to join to its own multicast list;

(13.5) In step (13.3), if there are no other multicast receiving client nodes in the subnet, the scheduling server will inform all client nodes working in P2P mode in the subnet to make them enter Multicast status, then go back to step (13.4).

In the above step (14), when a certain client node exits the live broadcast network, the scheduling method of the scheduling server specifically includes the following steps:

(14.1) If there is a multicast receiving client node inside the subnet where the exiting client node is located, and the exiting client node itself is a multicast client node, all the work of the exiting client node will be transferred to the On a multicast receiving client node in the subnet, the multicast receiving client node establishes connections with all client nodes that provide media streams of the exiting client nodes, thereby obtaining all media stream data, and accepting exiting client nodes at the same time requests from all client nodes receiving media streams of the client node;

(14.2) If there is a multicast receiving client node inside the subnet where the exiting client node is located, and the exiting client node itself is a multicast receiving client node, then the exiting client node is removed from the network delete from the topology table;

(14.3) If there is no multicast receiving client node in the subnet where the exiting client node is located (it can be considered that the client node requesting to join is not in the subnet), then assign a bottom client node to replace the exiting client End nodes (the assigned underlying client nodes generally have a large number of layers, which can keep the number of layers of the entire multicast network at a small level, which is conducive to reducing network delays, and should also take into account distance, bandwidth, etc. factor);

(14.4) If the withdrawn client node is a bottom client node, delete the withdrawn client node from the topology table of the network;

In the above-mentioned (15th) step, the method for dynamically updating the topology table in real time specifically includes the following steps:

(15.1) Each client node must periodically send an Alive signal to the scheduling server, indicating that it is still in the network and still working. If the survival signal is sent, it is considered that the client node has exited the live broadcast network, and it is deleted from the topology table, and then processed according to the scheduling method of the client node exit;

(15.2) In step (15.1), the time interval at which each client node sends the survival signal to the scheduling server changes randomly within a given range (set the time interval variation range according to cache size, delay and other information);

(15.3) When the scale of the multicast network is greater than the set scale threshold, the topology table is dynamically updated by a hierarchical monitoring method; the hierarchical monitoring method is: the seed client node is the only client node that directly sends a survival signal to the scheduling server ; All client nodes except the seed client node directly send survival signals to the client node or multicast client node providing media stream; if the client node or multicast client node providing media stream is within the time threshold If the survival signal of a certain client node is not received within the time threshold, the scheduling server will be notified directly; the scheduling server will delete the client node that has not sent the survival signal within the time threshold from the topology table, and then handle it according to the scheduling method that the client node exits .

Features and technical effects of the present invention:

The method of the invention combines the advantages of P2P technology, IP multicast technology and network proxy technology, and tries to save network bandwidth to the greatest extent. In this method, multi-data source technology is used to enhance the robustness of multicast network. The low correlation of multiple data sources provides favorable conditions for error recovery such as retransmission.

Description of drawings

Fig. 1 is the schematic diagram of the networking structure embodiment of the inventive method;

FIG. 2 is a schematic diagram of a scheduling method when a client node in a subnet exits a live broadcast network in this embodiment;

Fig. 3 is a schematic diagram of a scheduling method when a client node outside the subnet exits the live broadcast network in this embodiment.

Detailed ways

A robust point-to-point flow scheduling method proposed by the present invention is described in detail in conjunction with the accompanying drawings and embodiments as follows:

The embodiment of the networking structure of the method of the present invention is shown in Figure 1, in which 1 to 5 are all client nodes, wherein 1 is simultaneously a seed client node, a client node providing media streams and a client node receiving media streams; 2 is simultaneously a seed client node, a multicast client node, a client node that provides media streams, and a client node that receives media streams; 3 is a multicast receiving client node; 4 is simultaneously a client node that provides media streams and The client node receiving the media stream; 5 is the client node receiving the media stream and the underlying client node at the same time; 6 is the route for providing the media stream data; 7 is the dispatching server's scheduling of the media stream.

The networking method of this embodiment includes the following steps:

(1) In the network of this embodiment, the scheduling server finds other client nodes for client nodes (such as client nodes 1-5 in Figure 1), and notifies the streaming media server to provide media streams to the client nodes;

(2) The streaming media server provides a stable media stream to the client node;

(3) client node (as client node 1-5 in Fig. 1) receives the media flow from streaming media server or the client node that provides media flow, and buffers media flow, plays media flow data at this client node At the same time, provide media streams to other client nodes through P2P;

(4) If the client node in step (3) provides media streams to other client nodes during the P2P transmission process, the client node is called the client node that provides media streams (as shown in Figure 1). end nodes 1, 2, 4), otherwise the client node is called the bottom client node (as shown in client node 5 in Figure 1);

(5) If the client node in step (3) receives the media stream from the streaming media server or the client node that provides the media stream during the P2P transmission process, the client node is called the client receiving the media stream End nodes (such as client nodes 1, 2, 4, 5 in Figure 1);

(6) If the client node in step (3) is located inside a certain subnet and provides media streams to other client nodes, then the client node is called a multicast client node (as shown in Figure 1 client node end node2);

(7) If the client node in step (3) is located inside a certain subnet, it only receives media streams from other multicast client nodes in the same subnet, and does not provide media to other clients outside the subnet. stream, the client node is called a multicast receiving client node (as shown in client node 3 in Figure 1).

(8) The client node in the step (3) can be the client node providing the media flow, the client node receiving the media flow and the multicast client node simultaneously, but as long as it is the client node providing the media flow, One of the client node receiving media stream and the multicast client node, it cannot be the multicast receiving client node;

(9) The client node in step (3), if requesting to join the live broadcast network, then this client node is called the client node that requests to join (can be the client node 5 among Fig. 1);

(10) The client node in step (3), if it is requesting or has forcibly withdrawn from the live broadcast network, then the client node is called the withdrawn client node (it can be the client node 1-5 in Figure 1) ;

(11) client node in step (3), if directly obtain media flow from streaming media server, then this client node is called seed client node (as client node 1,2 among Fig. 1);

(12) The streaming media server is located at the 0th layer of the network; the seed client nodes (such as client nodes 1 and 2 in Figure 1) are located at the 1st layer of the network; if a certain client node is provided by several If the client node of the stream provides the media stream, its layer in the network is the largest layer plus one among all the client nodes providing the media stream (as shown in Figure 1, the client nodes 3 and 4 are the second layer, and the client node 5 is the 3rd layer); If a certain client node is to provide media flow by a certain multicast client node, then its level is the level of multicast client node (like client node 2 in Fig. 1) plus one. The layer sequence number in the network is used to estimate the delay of the media stream in the network;

The scheduling method of the present embodiment is described as follows in conjunction with FIGS. 1, 2, and 3:

(13) When a new client node (can be client node 3, 5 in Fig. 1) applies to join the live broadcast network, it must be connected with the scheduling server first, and the client node that provides the media stream is assigned by the scheduling server Or the multicast client node provides media streams for it (the scheduling server cannot provide any multicast receiving client node to the client node requesting to join, so as not to cause the output traffic of the subnet to be abnormally large);

(14) When a certain client node (could be client node 1-5 in Fig. 1) exits the live broadcast network, the scheduling server should select a multicast receiving client node or underlying client according to the current network topology The node replaces the exiting client node (if the scheduling server chooses the underlying client node, it generally chooses the one with the largest number of layers, and can also take into account distance, delay and other information for selection);

(15) The scheduling server keeps a detailed record of the topology network topology table of the network. When a client node joins or exits the network (that is, the network topology changes), the network topology table is also dynamically updated in real time;

(16) In the scheduling process of the scheduling server, the level number of the client node providing the media stream of each client node is smaller than the level number of the client node (thus ensuring that the scheduling server does not generate loops during the flow scheduling process). Shaped network structure, to ensure that each client node can directly or indirectly obtain the latest media stream data from the streaming media server);

(19) During the scheduling process of the scheduling server, assign each client node that cannot provide media streams to the bottom end of the live broadcast network, making it a bottom client node;

(20) There are multiple channel processing in the live broadcast environment, multiple scheduling servers can be run at the same time, and different ports can be opened on the same scheduling server to support it. Each scheduling server or each port maintains its own network logically .

In the above step (13), when a new client node applies to join the live broadcast network, the scheduling method of the scheduling server specifically includes the following steps:

(13.1) If there is no or only one other client node in the subnet where the client node requesting to join (such as client node 5 in Figure 1) is located (it can be considered that the client node requesting to join is not in the subnet) , then the scheduling server assigns several (the number can be relatively large) client nodes or streaming media servers outside the subnet to the client node that requests to join as candidate client nodes that provide media streams. The joined client nodes select several client nodes as the client nodes providing media streams by comparing (such as comparing the delay between them, comparing their historical information, etc.), and request the joining client nodes to work at this time In P2P mode;

(13.2) If there are 2 or more client nodes in the subnet where the client node (such as client nodes 3 and 5 in Figure 1) that requests to join, then the P2P mode can be used (method as in step (13.1) )), it can also be added to the entire live broadcast network in multicast mode;

(13.3) In step (13.2), if the client node requesting to join (such as client node 5 in Figure 1) joins the live broadcast network by multicast, then according to whether there are other multicast receivers in the original subnet The client node determines the scheduling method for new client nodes to join;

(13.4) In step (13.3), if there are other multicast receiving client nodes in the subnet, the scheduling server will inform all multicast clients in the subnet of the address and port number of the client node requesting to join End nodes, each multicast client node adds the information of the client node requesting to join to its own multicast list;

(13.5) In step (13.3), if there are no other multicast receiving client nodes in the subnet, the scheduling server will inform all client nodes working in P2P mode in the subnet to make them enter Multicast status, then go back to step (13.4).

In the above step (14), when a certain client node exits the live broadcast network, the scheduling method of the scheduling server specifically includes the following steps:

(14.1) If there is a multicast receiving client node inside the subnet where the exiting client node (such as client node 2 in Figure 2) is located, and the exiting client node itself is a multicast client node, then the The work of the withdrawn client node is all transferred to a multicast receiving client node in the subnet, and the multicast receiving client node establishes connections with all client nodes that provide media streams of the withdrawn client node, thereby Obtain all media stream data, and simultaneously accept requests from all client nodes receiving media streams of exiting client nodes;

(14.2) If there is a multicast receiving client node inside the subnet where the exiting client node (such as client node 3 in Figure 2) is located, and the exiting client node itself is a multicast receiving client node, then delete the exiting client node from the topology table of the network;

(14.3) If there is no multicast receiving client node inside the subnet where the exiting client node (such as client node 4 in Figure 3) is located (it can be considered that the client node requesting to join is not in the subnet), then Assign a bottom client node to replace the withdrawn client node (the distribution of bottom client nodes generally has a large number of layers, which can keep the number of layers of the entire multicast network at a small level, which is conducive to reducing Network delay, and factors such as distance and bandwidth should also be taken into account).

(14.4) If the withdrawn client node is the underlying client node (such as client node 5 in Figure 3), the withdrawn client node is deleted from the topology table of the network;

In the above-mentioned (15th) step, the method for dynamically updating the topology table in real time specifically includes the following steps:

(15.1) Each client node must periodically send a liveness signal to the scheduling server, indicating that it is still in the network and still working. If a client node does not send within a given time threshold (for example, 120 seconds) Survival signal, it is considered that the client node has withdrawn from the live broadcast network, and it is deleted from the topology table, and then processed according to the scheduling method of client node exit;

(15.2) In step (15.1), the time interval for each client node to send the survival signal to the scheduling server is randomly changed within a given range to prevent congestion, and the range is required to be within the timeout threshold set by the server ( For example, 80 to 110 seconds, set the time interval change range according to the cache size, delay and other information);

(15.3) When the scale of the multicast network is greater than the set scale threshold (currently, the hierarchical monitoring strategy is used), the topology table is dynamically updated by the hierarchical monitoring method. Generally, the timeout threshold set by the hierarchical monitoring is lower than the timeout threshold of the server Threshold is little (as 20 seconds); The concrete method of this graded monitoring is: seed client node (client node 1, 2 among Fig. 1) is the only client node that directly sends survival signal to scheduling server; Except seed client All client nodes (such as client node 3-5 among Fig. 1) except end node, directly send survival signal to the client node or the multicast client node that provides media flow (as client node 3 among Fig. 1 Send a survival signal to client node 2, client node 4 sends a survival signal to client node 2 or 3, and client node 5 sends a survival signal to client node 4); if the client node or multicast client providing media stream If the end node does not receive the survival signal of a client node within the time threshold, it will directly notify the scheduling server; the scheduling server will delete the client node that has not sent the survival signal within the time threshold from the topology table, and then press the client node Dispatch method handling for node exits.

Claims (4)

1. A robust point-to-point flow scheduling method, comprising a networking method and a scheduling method, characterized in that the networking method includes the following steps: (1) In the live broadcast network, the scheduling server finds other client nodes for the client node, and notifies the streaming media server to provide the media stream to the client node; (2) The streaming media server provides a stable media stream to the client node; (3) The client node receives the media stream from the streaming media server or the client node that provides the media stream, and buffers the media stream, and provides the media stream to other client nodes in a point-to-point manner while the client node is playing the media stream ; (4) Among the client nodes in step (3), if they provide media streams to other client nodes during point-to-point transmission, the client nodes are called client nodes that provide media streams; otherwise, the client nodes The node is called the underlying client node; (5) In the client node in step (3), if it receives the media stream from the streaming media server or the client node that provides the media stream during the point-to-point transmission process, the client node is called receiving the media stream client node; (6) Among the client nodes in step (3), if they are located in a certain subnet and provide media streams to other client nodes, then the client node is called a multicast client node; (7) Among the client nodes in step (3), if they are located inside a certain subnet, and only receive media streams from other multicast client nodes in the same subnet, they do not broadcast to other clients outside the subnet. If the media stream is provided, the client node is called a multicast receiving client node; (8) Among the client nodes in step (3), it can be the client node providing media stream, the client node receiving media stream and the multicast client node at the same time, but as long as it is the client node providing media stream node, a client node receiving media streams, and a multicast client node, it cannot be a multicast receiving client node; (9) in the client node in step (3), if requesting to join the live broadcast network, then this client node is called the client node requesting to join; (10) Among the client nodes in step (3), if they are requesting or have forcibly withdrawn from the live broadcast network, the client node is called the withdrawn client node; (11) the client node in the step (3), if directly obtain media flow from streaming media server, then this client node is called seed client node; (12) The streaming media server is located in the 0th layer of the network; the seed client node is located in the 1st layer of the network; if a certain client node is provided with media streams by several client nodes providing media streams, it is located in the The level is the largest level of all client nodes that provide media streams plus one; if a certain client node is provided by a multicast client node, its level is the level of the multicast client node plus one 1. The hierarchical sequence number in the network is used to estimate the delay of the media stream in the network; The scheduling method comprises the steps of: (13) When a new client node applies to join the live broadcast network, it must be connected to the scheduling server first, and the client node or multicast client node that provides the media stream is allocated by the scheduling server to provide the media stream; (14) When a certain client node withdraws from the live broadcast network, the scheduling server should select a multicast receiving client node or a bottom client node to replace the withdrawn client node according to the current network topology; (15) The scheduling server keeps a detailed record of the topology network topology table of the network. When a client node joins or exits the network, the network topology table is also dynamically updated in real time; (16) In the scheduling process of the scheduling server, the level number of the client node providing the media stream of each client node is smaller than the level number of the client node; (19) During the scheduling process of the scheduling server, assign each client node that cannot provide media streams to the bottom end of the live broadcast network, making it a bottom client node; (20) There are multiple channel processing in the live broadcast environment, multiple scheduling servers can be run at the same time, and different ports can be opened on the same scheduling server to support it. Each scheduling server or each port maintains its own network logically ; In the (14) step, when a certain client node withdraws from the live broadcast network, the scheduling method of the scheduling server specifically includes the following steps: (14.1) If there is a multicast receiving client node inside the subnet where the exiting client node is located; and the exiting client node itself is a multicast client node, all the work of the exiting client node will be transferred to the On a multicast receiving client node in the subnet, the multicast receiving client node establishes connections with all client nodes that provide media streams of the exiting client nodes, thereby obtaining all media stream data, and accepting exiting client nodes at the same time requests from all client nodes receiving media streams of the client node; (14.2) If there is a multicast receiving client node inside the subnet where the exiting client node is located, and the exiting client node itself is a multicast receiving client node, then the exiting client node is removed from the network delete from the topology table; (14.3) If there is no multicast receiving client node inside the subnet where the exiting client node is located, then assign a bottom client node to replace the exiting client node; (14.4) If the withdrawn client node is a bottom client node, delete the withdrawn client node from the topology table of the network. 2. The method according to claim 1, characterized in that, in the (13) step, when a new client node applies to join the live broadcast network, the scheduling method of the scheduling server specifically includes the following steps: (13.1) If there is no or only one other client node in the subnet where the client node requesting to join is located, the scheduling server assigns several client nodes or streaming media servers outside the subnet to the client node requesting to join The client node that requests to join is used as a candidate client node that provides media streams. The client node that requests to join selects several client nodes as client nodes that provide media streams through comparison. At this time, the client node that requests to join works In P2P mode; (13.2) If there are 2 or more client nodes in the subnet where the client node requesting to join, you can use P2P mode or multicast mode to join the entire live broadcast network; (13.3) In step (13.2), if the client node requesting to join joins the live network by multicast, then determine the new client node to join according to whether there are other multicast receiving client nodes in the original subnet scheduling method; (13.4) In step (13.3), if there are other multicast receiving client nodes in the subnet, the scheduling server will inform all multicast clients in the subnet of the address and port number of the client node requesting to join End nodes, each multicast client node adds the information of the client node requesting to join to its own multicast list; (13.5) In step (13.3), if there are no other multicast receiving client nodes in the subnet, the scheduling server will inform all client nodes working in P2P mode in the subnet to make them enter Multicast status, then go back to step (13.4). 3. The method according to claim 1, characterized in that, in the (15) step, the method for dynamically updating the topology table in real time, specifically comprises the following steps: (15.1) Each client node must periodically send a survival signal to the scheduling server, indicating that it is still in the network and still working. If a client node does not send a survival signal within a given time threshold, it is considered The client node has withdrawn from the live broadcast network, and is deleted from the topology table, and then processed according to the scheduling method of client node withdrawal; (15.2) In step (15.1), the time interval at which each client node sends a survival signal to the scheduling server varies randomly within a given range; (15.3) When the scale of the multicast network is greater than the set scale threshold, the topology table is dynamically updated by means of hierarchical monitoring. 4. The method according to claim 3, wherein the hierarchical monitoring method specifically comprises: the seed client node is the only client node that directly sends a survival signal to the scheduling server; all clients except the seed client node node, directly sends a survival signal to the client node or multicast client node that provides the media stream; if the client node or multicast client node that provides the media stream does not receive the survival Signal, directly notify the scheduling server; the scheduling server will delete the client node that has not sent the survival signal within the time threshold from the topology table, and then handle it according to the scheduling method that the client node exits.

Images