CN109348257B

CN109348257B - Pull stream control method and device and live broadcast system

Info

Publication number: CN109348257B
Application number: CN201811354455.8A
Authority: CN
Inventors: 冯修杰
Original assignee: Guangzhou Huya Information Technology Co Ltd
Current assignee: Guangzhou Huya Information Technology Co Ltd
Priority date: 2018-11-14
Filing date: 2018-11-14
Publication date: 2021-02-26
Anticipated expiration: 2038-11-14
Also published as: CN109348257A

Abstract

The application discloses a method, a device and a live broadcast system for controlling a pull stream, which are applied to a peer-to-peer network P2P server of the live broadcast system, and the method comprises the following steps: periodically updating the subscription qualification requirement of the managed CDN server to obtain the latest subscription qualification requirement; if the root pull flow node with the uplink capability not meeting the latest subscription qualification requirement exists in the root pull flow nodes pulled by the CDN server, releasing the root pull flow node with the uplink capability not meeting the latest subscription qualification requirement; determining the remaining sub-flow quota of the CDN server according to the number of the released root pull flow nodes; and sending the residual sub-flow quota and the latest subscription qualification requirement to one or more pull flow nodes so as to inform the pull flow nodes to request pull flow from the CDN server when the uplink capacity meets the latest subscription qualification requirement. The method and the device can dynamically adjust the nodes which are connected into the CDN server pull stream, and timely release the nodes with poor uplink capacity, so that the nodes with stronger uplink capacity become root nodes.

Description

Pull stream control method and device and live broadcast system

Technical Field

The application relates to the field of live broadcasting, in particular to a method and a device for controlling a pull stream and a live broadcasting system.

Background

With the development of network technology, live webcasting is more and more popular, and various social activities can be propagated by means of live webcasting.

Currently, the live broadcast system adopts the following live broadcast modes: the anchor end (terminal) unilaterally pushes the stream to the live platform, and then the stream is pulled and the stream media Content is played at the audience end (terminal) through the distribution of a transit system and a CDN (Content Delivery Network) server of the live platform. Generally, the number of audience terminals pulling streams is often huge, and how to improve the efficiency of pulling streams of the audience terminals and reduce the cost of pulling streams of the audience terminals becomes an important index for evaluating a live broadcast system.

Disclosure of Invention

In view of this, the present application provides a method and an apparatus for controlling a live streaming and a live broadcasting system.

According to a first aspect of embodiments of the present application, there is provided a method for controlling a pull stream, the method being applied to a peer-to-peer network P2P server of a live broadcast system, the method including:

periodically updating the subscription qualification requirement of the managed CDN server to obtain the latest subscription qualification requirement;

if it is determined that a root pull flow node with uplink capacity not meeting the latest subscription qualification requirement exists in root pull flow nodes pulled by the CDN server, releasing the root pull flow node with the uplink capacity not meeting the latest subscription qualification requirement;

determining the remaining sub-flow quota of the CDN server according to the number of the released root pull flow nodes;

and sending the residual sub-flow quota and the latest subscription qualification requirement to one or more pull flow nodes so as to inform the pull flow nodes to request pull flow from the CDN server when the uplink capacity meets the latest subscription qualification requirement.

According to a second aspect of the embodiments of the present application, there is provided a pull flow control apparatus, which is applied in a peer-to-peer network P2P server of a live broadcast system, the apparatus including:

a subscription qualification requirement updating module, configured to periodically update the subscription qualification requirement of the managed CDN server to obtain a latest subscription qualification requirement;

a root pull flow node releasing module, configured to release a root pull flow node whose uplink capability does not meet the latest subscription qualification requirement if it is determined that a root pull flow node whose uplink capability does not meet the latest subscription qualification requirement exists in root pull flow nodes pulled from the CDN server;

a residual sub-stream quota determining module, configured to determine a residual sub-stream quota of the CDN server according to the number of released root pull stream nodes;

and the information sending module is used for sending the residual sub-flow quota and the latest subscription qualification requirement to one or more pull flow nodes so as to inform the pull flow nodes to request pull flow from the CDN server when the uplink capacity meets the latest subscription qualification requirement.

According to a third aspect of the embodiments of the present application, a live broadcast system is provided, where the live broadcast system includes an anchor, an anchor CDN server, an anchor network server, a slice server, an audience CDN server, and an audience peer-to-peer network, where the audience peer-to-peer network includes a peer-to-peer network server and a plurality of pull nodes;

the anchor side is used for acquiring audio and video streams and pushing the streams to the CDN server of the anchor side;

the CDN server at the anchor side is used for sending the received audio and video stream sent by the anchor side to the network server at the anchor side;

the anchor side network server is used for processing the received audio and video stream and sending the processed audio and video stream to the slicing server;

the slicing server is used for slicing the received audio and video stream sent by the anchor side network server to generate a plurality of slice sub-streams and sending the slice sub-streams to the audience side CDN server;

the audience CDN server is used for distributing the received slice sub-streams to the accessed pull stream nodes; the peer-to-peer network server is used for receiving registration of the pull flow node and managing distribution conditions of the slice sub-flows of the CDN server at the audience side;

wherein the peer-to-peer network server is further configured to perform the steps of the pull control method described above;

the pull flow node is used for requesting the audience CDN server for the slice sub-flow.

According to a fourth aspect of embodiments of the present application, there is provided a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the pull flow control method described above.

According to a fifth aspect of embodiments of the present application, there is provided a computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the above-mentioned pull flow control method when executing the program.

The technical scheme provided by the embodiment of the application can have the following beneficial effects:

in this embodiment of the present application, the P2P server may periodically update the subscription qualification requirement of the managed CDN server to obtain a latest subscription qualification requirement of the CDN server, then release a node, whose uplink capability does not meet the latest subscription qualification requirement, in a root pull node of the CDN server, determine a remaining sub-flow quota of the CDN server according to the number of released nodes, and then send the remaining sub-flow quota of the CDN server and the latest subscription qualification requirement to one or more pull nodes to notify the one or more pull nodes that a pull may be requested from the CDN server when the uplink capability meets the latest subscription qualification requirement, without performing qualification checking on the node by the P2P server, so as to reduce the processing pressure of the P2P server and improve the processing efficiency. In addition, through the processing of the P2P server, the nodes which are continuously accessed to the CDN server for pulling flow can be dynamically adjusted, and the nodes with poor uplink capability can be released in time, so that the node with the stronger uplink capability becomes the root node, and the resource allocation of the CDN server is more reasonable.

Drawings

FIG. 1 is a flow chart illustrating steps of an embodiment of a method for pull flow control according to an exemplary embodiment of the present application;

fig. 2 is an architecture diagram of a live system shown in an exemplary embodiment of the present application;

FIG. 3 is a schematic diagram illustrating node subscriptions, according to an exemplary embodiment of the present application;

FIG. 4 is a ring subscription diagram shown in an exemplary embodiment of the present application;

FIG. 5 is a hardware block diagram of a server in which the apparatus of the present application resides;

FIG. 6 is a block diagram illustrating an exemplary embodiment of a pull flow control device according to the present application;

fig. 7 is a block diagram illustrating a structure of an embodiment of a live broadcast system according to an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Referring to fig. 1, a flowchart illustrating steps of an embodiment of a method for controlling a stream according to an exemplary embodiment of the present application is shown, where the embodiment of the present application may be applied to a peer-to-peer network P2P server of a live broadcast system.

The following first explains the architecture of the live broadcast system:

referring to fig. 2, an architecture diagram of a live broadcast system according to an exemplary embodiment is shown, in which a live broadcast system may include a main broadcast end, a main broadcast-side CDN network (including a plurality of CDN servers distributed in various places), a main broadcast network, a P2P (Peer-to-Peer network) source station (slice server), a viewer-side CDN network (including a plurality of CDN servers distributed in various places), a viewer-side P2P server (also referred to as a Peer-to-Peer network server), and a viewer end. It should be noted that, since the embodiments of the present application focus on the description of the audience side, the CDN network and the anchor network on the anchor side are drawn together in fig. 2, but actually, the two networks are separated.

Based on the architecture diagram of the live system of fig. 2, the general workflow of the live system is as follows: the method comprises the steps that a main broadcast end can push streams to a CDN server at the main broadcast side through RTMP (Real Time Messaging Protocol) or UDP (User Datagram Protocol), the CDN servers of all the places send received audio and video streams to the same main broadcast network server, the main broadcast network server can process the received audio and video streams, then the processed audio and video streams are forwarded to a P2P source station for slicing, the slicing approximate process is that the P2P source station cuts the received audio and video streams into data packets with the size of 1KB, each data packet is numbered and then packaged into a slice sub-stream according to a self-defined format, and the P2P source station sends the slice sub-stream to a CND network measured by audiences for distribution after slicing is completed. After the audience terminal joins the live broadcast room, the audience terminal is connected to the CDN server to pull the stream from the CDN server. Meanwhile, the access information is reported to the P2P access server to perform P2P connection with other audience terminals, and finally a P2P network (namely a peer-to-peer network) is formed.

In the above live broadcast system, the present embodiment focuses on the description of the audience side, and in the present embodiment, each audience in the P2P network is referred to as a pull stream node (node for short).

In one embodiment, the process of composing the P2P network may include the following processes: a process of node discovery and a process of establishing a connection between nodes.

The node discovery process comprises the following steps:

when a new node accesses a CDN server (hereinafter, unless specifically stated, the CDN server refers to a CDN server on the viewer side), the new node actively registers with the P2P server, and after the registration is completed, the new node may send a request for querying a node to the P2P server to request to obtain a node list composed of registered nodes from the P2P server. Then, the new node selects at least one target node from the returned node list to actively perform P2P connection according to the ability of the new node to go out (the node actively connected with another node is called out, and the other node actively connected with the node (namely, the node passively connected with the node) is called in), the uplink quality of each node to be connected in the node list, and the like.

The process of establishing connection between nodes:

after the new node selects at least one target node from the node list obtained by the P2P server, the new node sends a P2P connection request to the at least one target node, and after the target node receives the P2P connection request, the target node can determine whether to respond according to the in-degree and out-degree conditions of the target node. If so, the delegate may make a P2P connection with the new node. If the new node does not receive the response of the target node, the hole punching is not successful, at the moment, the new node tells the P2P server that the hole punching needs to be performed on the target node, the P2P server tells the target node, the target node knows that the new node requests to perform the hole punching, and the target node actively punches the hole with the new node under the condition that the access condition is met, or the P2P server resends a new node list to the new node, and the new node reselects the target node from the new node list to perform the active connection.

In practice, after a connection is established between nodes, a heartbeat packet may be sent at a certain time interval to maintain the connection, where the heartbeat packet may include a bandwidth uplink capability (e.g., a bandwidth uplink rate) of the node.

In addition, the packet loss rate of a node in a preset time period can be calculated according to the ratio of the number of bytes sent out and the number of bytes received by two communicating nodes in the time period. In a specific implementation, for a sending node sending data, it may count the number of bytes sent in an interval between two heartbeat packets, and add the number of bytes in a next heartbeat packet to transmit to a receiving node, and then for the receiving node, it may also count the number of bytes received in the interval between two received heartbeat packets, and then calculate a ratio of the number of bytes received and the number of bytes sent by the sending node in the heartbeat interval read from the heartbeat packet as a packet loss rate of the sending node. Similarly, the receiving node will add the number of bytes sent to the sending node in the heartbeat interval to the next heartbeat packet and transmit the heartbeat packet to the sending node, and the sending node calculates the packet loss rate of the receiving node according to the number of bytes received in the heartbeat interval and the number of bytes transmitted by the receiving node. For example, a sends 10 kbytes to B in the interval of two heartbeat packets (e.g., the first heartbeat packet and the second heartbeat packet). A tells B itself in the second heartbeat packet that 10 kbytes have been sent. B, the number of the data packets received by the B in the two heartbeat packet interval is calculated, for example, 9K bytes. Then the packet loss rate from a to B during this heartbeat interval is (10K-9K)/10K-10%.

Based on the above description of the live broadcast system and P2P networking, an embodiment of the method for controlling pull streaming provided in this embodiment of the present application focuses on explaining a process of dynamically adjusting a pull streaming node of pull streaming from a CDN server by a P2P server based on a P2P network, and as shown in fig. 1, this embodiment of the present application may include the following steps:

step 101, periodically updating the subscription qualification requirement of the managed CDN server to obtain the latest subscription qualification requirement;

in a specific implementation, when a pull flow node wants to pull a flow from a CDN server, a pull flow request is first sent to a P2P server, and the P2P server determines whether the pull flow node can pull a flow from the CDN server, if so, the P2P returns an allowance response to the pull flow node, and if not, the P2P returns a rejection response to the pull flow node, thereby implementing sub-flow distribution management for the CDN server.

The latest subscription qualification requirement of the CDN server refers to a minimum uplink capacity requirement that the pull flow node can pull a flow from the CDN server.

In a specific implementation, the P2P server may periodically update the subscription qualification requirement of the CDN server according to a preset update frequency, so as to obtain the latest subscription qualification requirement of the CDN server. For example, the CDN server subscription qualification requirements are updated once in 1 or 2 seconds.

In a preferred embodiment of the present application, step 101 may further include the following sub-steps:

a substep S11, receiving heartbeat packets sent by a plurality of stream pulling nodes connected to the P2P server according to a preset time interval, wherein the heartbeat packets include uplink capabilities of the stream pulling nodes;

the P2P server maintains a connection relationship with the stream pulling node connected thereto through a heartbeat packet, where the heartbeat packet may include the latest upstream capability of the stream pulling node.

As an example, the upstream capability may be a bandwidth upstream rate (i.e., number of bytes output per second) of the pull stream node.

A substep S12, periodically sequencing the pull flow nodes based on the uplink capability;

in implementation, an update period may be preset, and when the update period is reached, the P2P server may sort the pull nodes based on the uplink capabilities of all the pull nodes. Wherein the ordering may be a descending ordering.

A substep S13, acquiring the number of pulling nodes which are sequenced at the front and correspond to the sub-flow quota according to a preset sub-flow quota, and using the pulling nodes as computing nodes;

the number corresponding to the preset sub-flow quota may be obtained by calculating according to the preset sub-flow quota (i.e., how many sub-flows a flow can be divided into), the number of stream pulling nodes connected to the P2P server, and the preset sub-flow percentage. In implementation, the total number of the sub-streams needing to be pulled can be calculated according to a preset sub-stream quota and the number of the pull nodes (namely the number of the pull nodes) connected with the P2P server, and then the product of a preset CDN pull proportion and the total number of the sub-streams needing to be pulled is calculated, so as to obtain the number of the sub-streams for which the CDN server is responsible; according to the number of sub-streams for which the CDN server is responsible and the number of streams that each node can pull (i.e., the sub-stream quota), the number of root nodes that can pull streams from the CDN server, i.e., the number corresponding to the sub-stream quota, can be obtained. For example, assuming that a total of 100 nodes are connected to the P2P server, the sub-flow quota is set to 10. Then 100 nodes need to pull 1000 substreams in total. If the percentage of substreams that can be directly pulled from the CDN is 10%, then the substream quota for the CDN is 1000 x 10% — 100. After learning the upstream capabilities of all nodes, the P2P server sorts the upstream capabilities from high to low, and picks (100 (quota pulled directly from server)/10 (number of sub-streams that each node can pull)) -10 pull nodes as compute nodes.

And a substep S14, determining a latest subscription qualification requirement of the CDN server according to the uplink capacity of the computing node.

After determining the compute node, the P2P server may determine the latest subscription qualification requirements of the CDN servers in conjunction with the upstream capabilities of the compute node.

In one embodiment, the minimum upstream capacity in the compute node may be taken as the latest subscription qualification requirement for the CDN server.

Of course, the embodiment of the present application is not limited to the above-mentioned manner for determining the latest subscription qualification requirement, and those skilled in the art may determine the latest subscription qualification requirement in other manners, for example, taking the average of the upstream capabilities of the computing nodes as the latest subscription qualification requirement of the CDN server.

In this embodiment of the present application, since the uplink capabilities of the pull stream nodes may be changed, the computing nodes obtained according to the sorting of the uplink capabilities may also be changed accordingly, so that the latest subscription qualification requirement determined according to the uplink capabilities of the computing nodes may also be dynamically adjusted, and then, according to the dynamically adjusted latest subscription qualification requirement, the nodes with the adaptive uplink capabilities may be screened as root pull stream nodes.

Step 102, if it is determined that a root pull flow node with uplink capacity not meeting the latest subscription qualification requirement exists in root pull flow nodes of the pull flow of the CDN server, releasing the root pull flow node with the uplink capacity not meeting the latest subscription qualification requirement;

in a specific implementation, an initial root pull flow node of the CDN server is determined according to a first-come-first-obtained principle according to a sub-flow quota, that is, after the P2P server receives a pull flow request, if it is determined that the sub-flow quota of the CDN server is not full, an allowance response is sent to a corresponding pull flow node, so as to allow the pull flow node to pull a flow from the CDN server.

However, with the change of the upstream capability of each pull flow node, there may be a node with poor upstream capability in the initial root pull flow node, and for the root pull flow nodes with poor upstream capability, the embodiment of the present application may release the node with poor upstream capability through the P2P server, so that other nodes with strong upstream capability can pull flows from the CDN server.

For example, as shown in fig. 3, assuming that the substream quota configured for the CDN server is 3, based on the first-come-first-serve principle, all the

nodes

1, 2, and 3 starting to access may directly pull streams from the CDN server, when the node 4 joins, it first queries the P2P server to pull streams, and the P2P server rejects the node 4 due to saturation of the substream quota of the CDN server, and at this time, if the node 4 connects to the node 1 pulling streams with the best uplink quality, the uplink capability of the node 1 is strengthened (other nodes do not have uplink, and the node 1 has 1 uplink node, so the node is strengthened). If another node 5 is now coming in and it is connected to node 1 and node 2 with the best upstream quality, then the upstream capability of node 1 becomes 2, the upstream capability of node 2 becomes 1 and the upstream capability of node 3 is still 0. Then node 3 is the root pull node with poor uplink capability.

In this embodiment, the root pull flow node whose upstream capability does not meet the latest subscription qualification requirement may be used as the root pull flow node with poor upstream capability.

In an embodiment, the root pull flow node that releases the uplink capability that does not meet the latest subscription qualification requirement may specifically be: and when a subscription request sent by the root pull flow node of which the uplink capacity does not meet the latest subscription qualification requirement is received, returning a rejection response to the root pull flow node so as to reject the request of the root pull flow node for pulling the flow to the CDN server.

Step 103, determining a remaining sub-stream quota of the CDN server according to the number of released root pull flow nodes;

for example, in the example of fig. 3, when the root pull node 3 is released by the P2P server because of poor upstream capability, then the P2P server may determine that the remaining sub-flow quota of the CDN server is 1. By analogy, when two root pull flow nodes are released, the remaining sub-flow quota of the CDN server is 2, that is, the number of the released root pull flow nodes is used as the remaining sub-flow quota of the CDN server.

Step 104, sending the remaining sub-stream quota and the latest subscription qualification requirement to one or more pull flow nodes, so as to notify the pull flow nodes to request pull flow from the CDN server when the upstream capability meets the latest subscription qualification requirement.

After determining the remaining sub-flow quotas and the latest subscription qualification requirements, the P2P server may send the remaining sub-flow quotas and the latest subscription qualification requirements to one or more of the connected pull flow nodes. If the pull flow node finds that the pull flow node meets the latest subscription qualification requirement of pull flow connected with the CDN server, the pull flow node is actively connected with the CDN server to become a root pull flow node.

For example, for the example of fig. 4, when the root pull node 3 is released by the P2P server due to poor upstream capability, the P2P server informs the connected node that the remaining sub-stream quota is 1 and the latest subscription qualification requirement, and if the connected node finds itself meets the latest qualification requirement of the CDN server, the connected node actively connects with the CDN server to become the root node.

In a preferred embodiment of the present invention, the step 104 further comprises the following sub-steps:

and encapsulating the residual sub-flow quota and the latest subscription qualification requirement in a heartbeat response packet, and sending the heartbeat response packet to a corresponding pull flow node.

Specifically, the P2P server may encapsulate the remaining sub-flow quota and the latest subscription qualification requirement in the heartbeat response packet returned for the received heartbeat packet, and since the time when the P2P receives the heartbeat packets sent by each pull flow node is different, the time when the heartbeat response packet is returned to the pull flow node is also different, so that the time when the remaining sub-flow quota and the latest subscription qualification requirement are sent to the pull flow node may be missed, and the pressure of the P2P server is reduced.

In a specific implementation, after the pull flow node pulls the flow from the CDN server, the slice sub-flow may be actively sent to the pull flow node subscribing to the pull flow node. For example, as shown in fig. 3, if the node is node 1, after it obtains the slice sub-stream from the CDN server, it may actively send the slice sub-stream to

nodes

4 and 5 subscribing to it. The embodiment adopts a mode of actively pushing the stream to the subscribed nodes, and has the advantages of low time delay and suitability for low-delay scenes, such as live scenes.

For the pull flow nodes released by the P2P server (for better differentiation, referred to as request nodes hereinafter), it may select at least one pull flow node from the pull flow nodes (i.e., available nodes) in a connected state with the current node as a target pull flow node for pull flow. In a specific implementation, the requesting node may select at least one available node with stronger uplink quality as the target pull flow node. The uplink quality of the available node is determined by the packet loss rate and the sub-flow delay of the available node.

The packet loss rate of the available node may refer to the above packet loss rate calculation method, which is not described herein again.

The sub-flow delay of the available node can be determined according to the path length from the available node to the CDN server, and the longer the path length is, the larger the sub-flow delay is. For example, as shown in fig. 4, when a slice sub-stream of a CDN server reaches a

node

4, 2 hops are required, and the corresponding path length is 2; and 1 hop is needed when the slice sub-stream of the CDN server reaches the node 2, and the corresponding path length is 1, then the path length of the node 4 is greater than the path length of the node 2. The sub-stream delay corresponding to the path length can be calculated according to the preset time length required by each hop.

After the requesting node obtains the packet loss rate and the sub-flow delay of each available node, the packet loss rate and the sub-flow delay of each available node may be fused according to a preset scoring algorithm to obtain a score of the available node. And finally, selecting M available nodes with grades sorted in the front as target pull flow nodes by the node, wherein M is greater than or equal to 1.

In practice, before sending a pull request to a target pull node, a requesting node will first check whether a direct or indirect subscription relationship exists between the requesting node and the target pull node, and send a pull request to the target pull node only when no direct or indirect subscription relationship exists, so as to avoid the problem of a subscription ring (the subscription ring may cause data to be in a dead state). For example, as shown in the ring subscription diagram of fig. 4, assuming that the requesting node is node 1, and node 1 is given up by the CDN server due to insufficient uplink capacity, node 1 finds a node that can be connected to, assuming that the target pull flow node is node 7, when node 1 subscribes to node 7, since node 7 and node 1 have an indirect subscription relationship (node 2 and node 3 have a direct subscription relationship with node 1), a subscription ring is formed, and this subscription ring is an isolated P2P subscription system. Similarly, node 1 forms a subscription ring when it subscribes to any of nodes 2-6.

In one embodiment, the requesting node may obtain a subscription relationship list of the requesting node, where the subscription relationship list includes identities of all subscribed nodes subscribing to the requesting node (i.e., nodes directly subscribing to the requesting node), and identities of all nodes subscribing to the subscribed nodes (i.e., nodes indirectly subscribing to the requesting node). Subsequently, the identifier of the target pull flow node can be searched in the subscription relationship list; if the searching is successful, judging that the target pull flow node and the request node have a subscription relation; if the searching is unsuccessful, the target pull flow node and the request node are judged not to have a subscription relation.

The subscription relationship list of the requesting node may be obtained in the following two ways, but the embodiment is not limited to this:

the first method is as follows: receiving the subscription relationship reported by the subscribed node subscribed to the local node in the requesting node, and summarizing the subscription relationship between the local node and the subscribed node and the subscription relationship reported by the subscribed node to obtain a subscription relationship list. That is, in each node, a list of subscription relationships for other nodes to subscribe to the slice subflows from the node is maintained. In the subscription relationship data table, the identifier of the pull flow node directly or indirectly subscribing to the current node is recorded.

The second method comprises the following steps: all nodes can report own subscription relationship to the P2P server, and the P2P server maintains a subscription relationship list of each node, so that when a requesting node needs the subscription relationship list, the requesting node can request the subscription relationship list from the P2P server.

In another embodiment, the requesting node may further send a subscription relationship query request to the P2P server, where the subscription relationship query request includes an identifier of the target pull flow node, so as to send the identifier of the target pull flow node to the P2P server, and the requesting P2P server searches the identifier of the target pull flow node from a locally maintained subscription relationship list corresponding to the requesting node. If the search is successful and the subscription relationship between the node and the target pull flow node exists, the P2P server returns a subscription refusing response to the node to inform the requesting node to refuse to subscribe the slice sub-flow to the target pull flow node, so as to avoid the occurrence of a subscription ring; otherwise, if the search fails, indicating that the two do not have a subscription relationship, the P2P server returns a response of allowing subscription to the node.

For example, the list of subscription relationships of each node corresponding to fig. 4 is shown in table 1 below:

TABLE 1

After the requesting node determines that no subscription relationship exists with the target pull flow node, a pull flow request may be sent to the target pull flow node. For the target pull flow node, after receiving the pull flow request, it will also determine that its uplink capability is not enough to receive the pull flow request with the free bandwidth.

In one embodiment, the target pull flow node may determine whether there is free bandwidth by using the following method:

acquiring the packet loss rate of a target pull flow node within a certain time period; determining the maximum number of sub-streams which can be transmitted by the target pull stream node according to the packet loss rate; determining the number of subscribed sub-streams of the target pull stream node; if the subscribed sub-flow number is less than the maximum sub-flow number, determining that a target pull flow node has idle bandwidth; and if the subscribed sub-flow number is greater than or equal to the maximum sub-flow number, determining that the target pull flow node has no idle bandwidth.

Specifically, the target pull flow node may periodically calculate a packet loss rate of the target pull flow node, and the specific calculation manner is to calculate a ratio of the number of bytes sent to each available node by the target pull flow node to the number of bytes received by the target pull flow node in the two heartbeat packet sending intervals. For example, node 1 counts 10K bytes sent to

available nodes

2, 3, and 4 connected to this node in the two heartbeat packet sending intervals, respectively, and then the number of bytes sent by node 1 in this time period is 30K. If the number of bytes returned by the corresponding receiving node 2 is 8K, the number of bytes returned by the receiving node 3 is 6K, and the number of bytes returned by the receiving node 4 is 6K, the number of bytes received by the node 1 in the time period is 30K, and the packet loss rate of the node 1 is (30-20)/30-33%.

After the packet loss rate is obtained, the maximum number of sub-streams that can be transmitted by the target stream pulling node can be further dynamically adjusted according to the packet loss rate. One embodiment may be: if the packet loss rate is lower than a first preset packet loss rate threshold, increasing sub-streams according to a preset increment to obtain the maximum number of the sub-streams; and if the packet loss rate is higher than a second preset packet loss rate threshold, reducing the sub-streams according to a preset increment to obtain the maximum number of the sub-streams, wherein the second preset packet loss rate threshold is greater than or equal to the first preset packet loss rate threshold.

For example, if there are 3 sub-streams currently subscribed to, and the corresponding packet loss rate is relatively low (lower than the first preset packet loss rate threshold), the sub-streams may be increased according to a preset increment, for example, the increment is 1, and 1 sub-stream is increased, so that the maximum number of sub-streams is 4. Or, when the corresponding packet loss rate is relatively high (higher than a second preset packet loss rate threshold), the sub-streams may be reduced by a preset increment, for example, by 1 sub-stream, so that the maximum number of sub-streams is 2.

Meanwhile, the target pull flow node can also determine the number of the subscribed sub-flows according to the number of the subscribed nodes. If the number of subscribed sub-streams is less than the maximum number of sub-streams, it indicates that the target pull stream node has idle bandwidth, for example, according to the above example, the maximum number of sub-streams is 4, and the number of subscribed sub-streams is 3, then the target pull stream node has another idle sub-stream that can be subscribed. If the number of subscribed sub-streams is greater than or equal to the maximum number of sub-streams, it indicates that the target pull stream node has no idle bandwidth, for example, if the maximum number of sub-streams is 3 and the number of subscribed sub-streams is 3, the target pull stream node has no idle sub-streams to which it can subscribe.

If the target pull flow node has free bandwidth, the pull flow request can be accepted, and the slice sub-flow corresponding to the pull flow request is sent to the requesting node.

If there is no free bandwidth, the target pull flow node may further query the upstream capabilities of all nodes subscribing to itself (i.e., subscribed nodes). For example, node 2 subscribes from node 1 to obtain slice subflow No. 1, then node 1 is a subscribing node, and node 2 is a subscribed node of node 1.

The uplink capacity of the subscribed node may be a bandwidth uplink rate of the subscribed node. The bandwidth uplink rate of each subscribed node can be obtained from the heartbeat packet of the maintained connection between the nodes.

Subsequently, the minimum uplink capacity in all subscribed nodes may be compared with the uplink capacity of the node sending the pull request (i.e., the requesting node), where the uplink capacity is carried in the pull request, that is, the minimum bandwidth uplink rate in the subscribed nodes is compared with the bandwidth uplink rate of the requesting node.

If the minimum uplink capacity is smaller than the uplink capacity of the requesting node, it indicates that the uplink capacity of the requesting node is stronger than the uplink capacity of the subscribed node corresponding to the minimum uplink capacity, and at this time, the target pull flow node may release the subscription of the subscribed node corresponding to the minimum uplink capacity and receive the subscription of the requesting node.

The step of releasing the subscription of the subscribed node corresponding to the minimum uplink capability may be implemented by sending a unsubscribe message to the subscribed node corresponding to the minimum uplink capability to notify the subscribed node that the subscribed node does not need to pull a flow from the node.

When the target pull flow node receives the subscription of the request node, the target pull flow node can send an agreement message to the request node and can directly send the slice sub-flow corresponding to the subscription request to the request node.

In practice, before the target pull flow node accepts the subscription of the request node, it may also be determined whether a subscription relationship exists between the target pull flow node and the request node, and if the subscription relationship does not exist between the target pull flow node and the request node, the target pull flow node sends an agreement message to the request node, otherwise, the target pull flow node rejects the subscription of the request node. The manner of determining whether the subscription relationship exists between the target pull flow node and the request node may refer to the determination of the subscription relationship on the request node side.

It should be noted that, in the embodiment of the present application, the subscription relationship may be determined on the target pull flow node side that receives the subscription request, the subscription relationship may also be determined on the requesting node side, or the subscription relationship may be determined on both sides, which is not limited in the embodiment of the present application.

In a preferred embodiment of the present application, when the requesting node receives an agreement to subscribe message sent by the target pull stream node or receives a slice sub-stream sent by the target pull stream node, the requesting node may report the subscription relationship between the requesting node and the target pull stream node to the P2P server, so that the P2P server maintains a subscription relationship list.

In addition, for the target stream pulling node, if the packet loss rate is relatively high, it indicates that the capability of the node is reduced, at this time, the maximum number of sub-streams may be reduced, for example, the maximum number of sub-streams is reduced to 2, and the number of subscribed sub-streams is 3, the worst sub-stream may be eliminated. Specifically, the subscribed node with the worst uplink capability of the subscribed node may be released, so as to improve the uplink capability of the target pull flow node.

On the other hand, if the minimum bandwidth uplink rate in the subscribed nodes is greater than the bandwidth uplink rate of the requesting node, which indicates that the uplink capability of the requesting node is weaker than the uplink capability of the subscribed node corresponding to the minimum bandwidth uplink rate, the target pull stream node may send a subscription failure response to the requesting node to reject the subscription of the requesting node. Then it is necessary for the requesting node to select other nodes from the nodes connected to it to send subscription requests.

In accordance with embodiments of the foregoing method, embodiments of a pull flow control device are also provided.

The device embodiment of the present application can be applied to a P2P server. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading corresponding computer program instructions in the nonvolatile memory into the memory for operation through the processor of the server where the device is located. From a hardware aspect, as shown in fig. 5, the hardware structure diagram of the server where the apparatus of the present application is located is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 5, the server where the apparatus is located in the embodiment may also include other hardware according to the actual function of the apparatus, which is not described again.

Referring to fig. 6, a block diagram of an embodiment of a pull control apparatus according to an exemplary embodiment of the present application is shown, where the apparatus is applied to a peer-to-peer network P2P server of a live broadcast system, and the apparatus includes the following modules:

a subscription qualification requirement updating module 601, configured to periodically update the subscription qualification requirement of the managed CDN server to obtain a latest subscription qualification requirement;

a root pull flow node releasing module 602, configured to release a root pull flow node whose uplink capability does not meet the latest subscription qualification requirement if it is determined that a root pull flow node whose uplink capability does not meet the latest subscription qualification requirement exists in root pull flow nodes pulled from the CDN server;

a remaining sub-stream quota determining module 603, configured to determine a remaining sub-stream quota of the CDN server according to the number of released root pull stream nodes;

an information sending module 604, configured to send the remaining sub-flow quota and the latest subscription qualification requirement to one or more pull flow nodes, so as to notify the pull flow nodes to request a pull flow from the CDN server when an uplink capability meets the latest subscription qualification requirement.

In a preferred embodiment of the present application, the subscription qualification requirement updating module 601 may specifically include the following sub-modules:

the heartbeat packet receiving submodule is used for receiving heartbeat packets sent by a plurality of stream pulling nodes connected with the P2P server according to a preset time interval, wherein the heartbeat packets comprise the uplink capacity of the stream pulling nodes;

the sequencing submodule is used for sequencing the pull flow nodes periodically on the basis of the uplink capacity;

the computing node determining submodule is used for acquiring the number of pull flow nodes which are sequenced in the front and correspond to the sub flow quota according to the preset sub flow quota, and the pull flow nodes are used as computing nodes;

and the latest subscription qualification requirement determining submodule is used for determining the latest subscription qualification requirement of the CDN server according to the uplink capacity of the computing node.

In a preferred embodiment of the present application, the latest subscription qualification requirement determining submodule is specifically configured to:

and taking the minimum uplink capacity in the computing nodes as the latest subscription qualification requirement of the CDN server.

In a preferred embodiment of the present application, the compute node determining submodule is specifically configured to:

determining the number of the pull flow nodes connected with the P2P server, and recording the number as the number of the pull flow nodes;

calculating the total number of the sub-streams according to the number of the pull stream nodes and the preset sub-stream quota;

determining the number of the sub-streams responsible for the CDN server according to the total number of the sub-streams and a preset CDN stream pulling proportion;

determining the number of nodes capable of pulling the stream from the CDN server according to the number of the sub-streams responsible for the CDN server and the sub-stream quota;

and acquiring the pull flow nodes which are sequenced at the front and correspond to the number of the nodes capable of pulling flow from the CDN server as computing nodes.

In a preferred embodiment of the present application, the information sending module 604 is specifically configured to:

In a preferred embodiment of the present application, the root pull node releasing module 602 is specifically configured to:

and when a pull flow request sent by the root pull flow node of which the uplink capacity does not meet the latest subscription qualification requirement is received, returning a rejection response to the root pull flow node so as to reject the request of the root pull flow node for pulling the flow to the CDN server.

In a preferred embodiment of the embodiments of the present application, the apparatus further comprises:

a subscription relationship query request receiving module, configured to receive a subscription relationship query request sent by a request node, where the request node is a pull flow node that is rejected by a P2P server from pulling from a CDN server, the query request includes an identifier of a target pull flow node, and the target pull flow node is a node with the strongest uplink quality, which is selected by the request node from pull flow nodes connected to the request node;

a subscription relationship list obtaining module, configured to obtain a subscription relationship list corresponding to the request node according to the subscription relationship query request, where the subscription relationship list is a list generated after receiving a subscription relationship reported by a node that directly or indirectly subscribes to the request node;

a subscription relation query module, configured to search the identifier of the target pull flow node from a subscription relation list corresponding to the request node; if the search is successful, sending a subscription refusing response to the request node to inform the request node of refusing to subscribe the slicing sub-flow to the target pull flow node, so as to avoid the occurrence of a subscription ring; and if the search fails, sending a subscription permission response to the request node to inform the request node of subscribing the slice sub-streams to the target pull stream node.

Corresponding to the embodiment of the method, the application also provides an embodiment of a live broadcast system.

Referring to fig. 7, a block diagram of a live broadcast system according to an exemplary embodiment of the present disclosure is shown, where the live broadcast system includes an anchor 701, an anchor CDN server 702, an anchor network server 703, a slice server 704, a viewer CDN server 705, and a viewer peer-to-peer network, where the viewer peer-to-peer network includes a peer-to-peer network server 706 and a plurality of pull nodes 707;

the anchor terminal 701 is configured to acquire an audio/video stream and push the stream to the CDN server on the anchor side;

the anchor CDN server 702 is configured to send the received audio/video stream sent by the anchor to the anchor network server;

the anchor side network server 703 is configured to process the received audio/video stream and send the processed audio/video stream to a slice server;

the slicing server 704 is configured to perform slicing processing on the received audio and video stream sent by the anchor side network server to generate a plurality of slice sub-streams, and send the slice sub-streams to the audience side CDN server;

the audience-side CDN server 705 is configured to distribute the received slice sub-streams to the pull stream nodes that are accessed;

the peer-to-peer network server 706 is configured to receive registration of a pull stream node and manage a slice sub-stream distribution situation of the CDN server on the viewer side;

wherein the peer-to-peer network server 706 is further operable to perform the steps of the pull flow control method of the embodiment of fig. 1;

the pull flow node 707 is configured to receive a slice sub-flow sent by a CDN server on the viewer side.

For the device and live broadcast system embodiments, since they basically correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points.

The above-described apparatus embodiments and live broadcast system embodiments are merely illustrative, where the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.

The present application also provides a computer-readable storage medium having stored thereon a computer program which, when being executed by a processor, carries out the steps of the above-mentioned method embodiments.

The present application further provides a computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned method embodiments when executing the program.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in: digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or a combination of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a tangible, non-transitory program carrier for execution by, or to control the operation of, data processing apparatus. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode and transmit information to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform corresponding functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Computers suitable for executing computer programs include, for example, general and/or special purpose microprocessors, or any other type of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory and/or a random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer does not necessarily have such a device. Further, the computer may be embedded in another device, e.g., a vehicle-mounted terminal, a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.

Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., an internal hard disk or a removable disk), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. In other instances, features described in connection with one embodiment may be implemented as discrete components or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. Further, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing may be advantageous.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A method for controlling a pull stream is applied to a peer-to-peer network P2P server of a live broadcast system, and the method comprises the following steps:

2. The method of claim 1, wherein periodically updating the subscription qualification requirements of the CDN servers to obtain a latest subscription qualification requirement comprises:

receiving heartbeat packets sent by a plurality of stream pulling nodes connected with the P2P server according to a preset time interval, wherein the heartbeat packets comprise the uplink capacity of the stream pulling nodes;

periodically sequencing the pull flow nodes based on the uplink capacity;

according to a preset sub-flow quota, acquiring the number of pull flow nodes which are sequenced at the front and correspond to the sub-flow quota, and using the pull flow nodes as computing nodes;

and determining the latest subscription qualification requirement of the CDN server according to the uplink capacity of the computing node.

3. The method of claim 2, wherein determining the most recent subscription eligibility requirement for the CDN server based on the upstream capabilities of the compute node comprises:

4. The method according to claim 2 or 3, wherein the obtaining, according to a preset sub-flow quota, a number of pull nodes that are sorted at the top and correspond to the sub-flow quota as a computing node includes:

5. The method according to claim 2 or 3, wherein the sending the remaining sub-flow quota and the latest subscription qualification requirement to one or more pull flow nodes comprises:

6. The method according to any of claims 1-3, wherein said releasing the root pull node whose upstream capability does not meet the latest subscription qualification requirement comprises:

7. The method of claim 6, further comprising:

receiving a subscription relationship query request sent by a request node, wherein the request node is a pull flow node which is refused to pull flow from a CDN server by a P2P server, the query request comprises an identifier of a target pull flow node, and the target pull flow node is a node with the strongest uplink quality selected by the request node from the pull flow nodes connected with the request node;

acquiring a subscription relationship list corresponding to the request node according to the subscription relationship query request, wherein the subscription relationship list is generated after receiving a subscription relationship reported by a node which directly or indirectly subscribes the request node;

searching the identifier of the target pull flow node from a subscription relation list corresponding to the request node;

if the search is successful, sending a subscription refusing response to the request node to inform the request node of refusing to subscribe the slicing sub-flow to the target pull flow node, so as to avoid the occurrence of a subscription ring;

and if the search fails, sending a subscription permission response to the request node to inform the request node of subscribing the slice sub-streams to the target pull stream node.

8. A pull flow control device, which is applied in a peer-to-peer network P2P server of a live system, the device comprising:

9. A live broadcast system is characterized by comprising an anchor end, an anchor side CDN server, an anchor side network server, a slicing server, an audience side CDN server and an audience side peer-to-peer network, wherein the audience side peer-to-peer network comprises a peer-to-peer network server and a plurality of pull stream nodes;

the audience CDN server is used for distributing the received slice sub-streams to the accessed pull stream nodes;

the peer-to-peer network server is used for receiving registration of pull flow nodes and managing distribution conditions of slice sub-flows of the CDN server at the audience side;

wherein the peer-to-peer network server is further configured to perform the steps of the pull control method of any of claims 1-7;

10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 7.

11. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the method according to any of claims 1-7 are implemented when the program is executed by the processor.