Content distribution method and apparatus, content distribution network, device, and medium

Abstract

Embodiments of the present application provide a content distribution method and device, a content distribution network, equipment and a medium. In the embodiments of the present application, network state data of the content distribution network is used for path planning, so as to plan a corresponding shortest pull stream path for each pull stream node to each push stream node, and then the plurality of CDN nodes are interconnected, the content distribution network presents a mesh network structure instead of a tree network structure, and to some extent, the content distribution network is planned in a decentralized mesh routing manner. Further, the communication state and communication delay between the CDN nodes, and the current residual bandwidth of each CDN node and other network state data are comprehensively selected to select the pull stream path of the pull stream node to the push stream node, which greatly improves the probability of obtaining the pull stream path with smaller communication delay, effectively controls the bandwidth of each CDN node on the pull stream path, and improves the efficiency of content distribution.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network, and particularly relates to a content distribution method and device, a content distribution network, equipment and a medium. BACKGROUND

[0002] A content delivery network (CDN) relies on CDN nodes deployed in various places to enable users to obtain required content in a nearby manner, reduce network congestion, and improve response speed and hit rate of user access. Generally, CDN nodes can be divided into scheduling nodes and edge nodes close to user sides, and the CDN adopts a tree form to cache distributed content. Referring to Figure 1 Taking a live broadcast scenario as an example, any edge node can receive a push stream request of a host as a push stream node, cache a live stream pushed by the host locally, push the live stream to a higher-level edge node to enable the higher-level edge node to cache the live stream locally, and continue to push the live stream outward by the higher-level edge node until the live stream is pushed to a scheduling node to enable the scheduling node to cache the live stream locally. Any edge node can receive a pull stream request of a viewer as a pull stream node, return a live stream cached locally to the viewer if the live stream required by the viewer is cached locally, request the live stream required by the viewer from a higher-level edge node if the live stream required by the viewer is not cached locally, continue to access a higher-level edge node until an edge node that caches the live stream required by the viewer is accessed or until the scheduling node is accessed. Any edge node or the scheduling node that caches the live stream required by the viewer returns the live stream to a lower-level edge node until the live stream is returned to the pull stream node, and the pull stream node returns the live stream to the viewer. However, the entire link for pulling the live stream is relatively long, greatly increases communication delay of the pull stream path, and causes great resource waste. SUMMARY

[0003] Aspects of the present application provide a content distribution method, device, content distribution network, equipment and medium to improve distribution efficiency of a content distribution network.

[0004] This application provides a content distribution method applied to a content distribution network (CDN), which includes multiple CDN nodes. The method includes: acquiring network status data of the CDN, including communication status and communication latency between pairs of CDN nodes in some or all of the CDN nodes, and the current remaining bandwidth of each CDN node; selecting at least one CDN node from the multiple CDN nodes in the CDN as at least one streaming node, and selecting at least one corresponding streaming node from the multiple CDN nodes in the CDN for each streaming node; performing path planning based on the network status data to obtain the shortest streaming path from each streaming node to its corresponding at least one streaming node; and distributing content according to the shortest streaming path from each streaming node to its corresponding at least one streaming node.

[0005] This application embodiment also provides a content delivery network, including: a probe node, a scheduling node, and multiple edge nodes; the probe node is used to detect the communication status and communication latency between pairs of edge nodes in some or all of the edge nodes; the scheduling node is used to obtain the communication status and communication latency between pairs of edge nodes in some or all of the edge nodes detected by the probe node, and to determine the current remaining bandwidth of each edge node in some or all of the edge nodes; at least one edge node is selected from multiple edge nodes as at least one streaming node, and at least one corresponding streaming node is selected from multiple edge nodes for each streaming node; path planning is performed based on network status data to obtain the shortest streaming path from each streaming node to its corresponding at least one streaming node; content is distributed according to the shortest streaming path from each streaming node to its corresponding at least one streaming node.

[0006] This application embodiment also provides a content distribution apparatus, comprising: an acquisition module, configured to acquire network status data of a content distribution network, the network status data including the communication status and communication latency between pairs of CDN nodes in some or all CDN nodes of the content distribution network, and the current remaining bandwidth of each CDN node in some or all CDN nodes; a selection module, configured to select at least one CDN node from a plurality of CDN nodes included in the content distribution network as at least one streaming node, and to select at least one corresponding streaming node from the plurality of CDN nodes included in the content distribution network for each streaming node; a path planning module, configured to perform path planning based on the network status data to obtain the shortest streaming path from each streaming node to its corresponding at least one streaming node; and a content distribution module, configured to distribute content according to the shortest streaming path from each streaming node to its corresponding at least one streaming node.

[0007] This application also provides an electronic device, including: a memory and a processor; the memory for storing a computer program; and the processor coupled to the memory for executing the computer program to perform steps in a content distribution method.

[0008] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the content distribution method.

[0009] In this embodiment, path planning is performed based on the network status data of the content delivery network (CDN) to plan the shortest pull path from each pull node to each push node. This enables multiple CDN nodes to be interconnected, resulting in a mesh network structure rather than a tree structure. To a certain extent, this achieves decentralized mesh routing for path planning. Furthermore, by comprehensively considering the communication status and latency between CDN nodes, as well as the current remaining bandwidth of each CDN node, the pull path from the pull node to the push node is selected. This significantly increases the probability of obtaining a pull path with lower latency, effectively controls the bandwidth of each CDN node on the pull path, greatly reduces the occurrence of excessive network traffic at CDN nodes, and improves the efficiency of content distribution. This is particularly suitable for complex point-to-point routing scenarios with a large number of nodes. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0011] Figure 1 A diagram illustrating an application scenario for content distribution using an exemplary content delivery network;

[0012] Figure 2 A diagram illustrating another application scenario for content distribution using an exemplary content delivery network;

[0013] Figure 3 A flowchart illustrating a content distribution method provided in an embodiment of this application;

[0014] Figure 4 A flowchart illustrating another content distribution method provided in this application embodiment;

[0015] Figure 5 A flowchart illustrating another content distribution method provided in this application embodiment;

[0016] Figure 6A diagram illustrating another application scenario for content distribution using an exemplary content delivery network;

[0017] Figure 7 This is a schematic diagram of the structure of a content distribution device provided in an embodiment of this application;

[0018] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the access relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone, where A and B can be singular or plural. In the textual description of this application, the character " / " generally indicates that the preceding and following associated objects have an "or" relationship. Furthermore, in the embodiments of this application, "first," "second," "third," "fourth," "fifth," and "sixth" are only used to distinguish the content of different objects and have no other special meaning.

[0021] Currently, the entire link for pulling live streams is quite lengthy, significantly increasing communication latency and resulting in substantial resource waste. To address this, this application provides a content distribution method, apparatus, content distribution network, device, and medium. In this embodiment, path planning is performed based on network status data of the content distribution network to plan the shortest possible pull path from each pull node to each push node. This interconnects multiple CDN nodes, resulting in a mesh network structure rather than a tree structure. To a certain extent, this achieves decentralized mesh routing for path planning. Furthermore, by comprehensively considering the communication status and latency between CDN nodes, as well as the remaining bandwidth of each CDN node, the pull path from the pull node to the push node is selected. This significantly increases the probability of obtaining a pull path with lower communication latency, effectively controls the bandwidth of each CDN node along the pull path, greatly reduces the occurrence of excessive network traffic at CDN nodes, and improves content distribution efficiency. This is particularly suitable for complex point-to-point routing scenarios with a large number of nodes.

[0022] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0023] Figure 2 This diagram illustrates another application scenario for content distribution using an exemplary content delivery network. For example... Figure 2As shown, a Content Delivery Network (CDN) comprises multiple CDN nodes. Some CDN nodes are located close to the user side; these can be considered edge nodes. Other nodes are located in the cloud; these can be considered cloud-side nodes. The location of each CDN node can be flexibly configured according to actual application needs. These multiple CDN nodes can include CDN nodes with identical functions or CDN nodes with different functions, and the functions of each CDN node can be flexibly configured according to actual application needs. For example, based on different functions, multiple CDN nodes can be divided into scheduling nodes, probe nodes, pull nodes, and push nodes. Scheduling nodes can be nodes with management and control functions, such as handling network traffic analysis, load balancing, content distribution, and node scheduling. They can also handle routing tasks for pull paths from pull nodes to push nodes, but are not limited to these. Probe nodes are mainly responsible for probing the network status data of the entire content delivery network, such as whether the communication status between any two CDN nodes is communicable or not, and the communication latency between any two CDN nodes, etc. Pull nodes are CDN nodes that fetch the required content data from the corresponding push nodes based on user-initiated pull requests. Pull nodes are typically edge nodes. Push nodes, on the other hand, are nodes that cache user-provided content data based on user-initiated push requests. Pull or push nodes are typically edge nodes located closer to the user.

[0024] It is worth noting that, Figure 2 The example shown is a live stream, which illustrates the content data distributed by a content delivery network. However, the content data that a content delivery network can distribute includes, but is not limited to, video data, audio data, text data, and image data.

[0025] In this embodiment, any CDN node can be, for example, a terminal device or a server. Terminal devices include, but are not limited to, tablets, desktop computers, wearable smart devices, smart home devices, etc. Servers include, but are not limited to, a single server or a distributed server cluster consisting of multiple servers. It should be understood that... Figure 2 This is merely a schematic diagram of a content delivery network provided in an embodiment of this application. This embodiment of the application does not represent... Figure 2 The number of CDN nodes included is limited, and there is no limit to the number of CDN nodes included. Figure 2 The location relationships between CDN nodes are defined.

[0026] In this embodiment, path planning is performed based on the network status data of the content delivery network (CDN) to plan the shortest pull path from each pull node to each push node. This enables multiple CDN nodes to be interconnected, resulting in a mesh network structure for the CDN rather than a tree structure. To a certain extent, this achieves decentralized mesh routing for path planning. Furthermore, by comprehensively considering the communication status and latency between CDN nodes, as well as the current remaining bandwidth of each CDN node, the pull path from the pull node to the push node is selected. This significantly increases the probability of obtaining a pull path with lower latency, effectively controls the bandwidth of each CDN node on the pull path, greatly reduces the occurrence of excessive network traffic at CDN nodes, and improves the efficiency of content distribution. This is particularly suitable for complex point-to-point routing scenarios with a large number of nodes.

[0027] Figure 3 This is a flowchart illustrating a content distribution method provided in an embodiment of this application. The method can be executed by a content distribution device, which can typically be integrated into any CDN node within a CDN. See also... Figure 3 The method may include the following steps:

[0028] 300. Obtain network status data of the content delivery network. The network status data includes the communication status and communication latency between any two CDN nodes in some or all of the CDN nodes, as well as the current remaining bandwidth of each CDN node in some or all of the CDN nodes.

[0029] 301. Select at least one CDN node from the multiple CDN nodes included in the content delivery network as at least one pull node, and select at least one corresponding push node from the multiple CDN nodes included in the content delivery network for each pull node.

[0030] 302. Perform path planning based on network status data to obtain the shortest streaming path from each streaming node to its corresponding at least one push node.

[0031] 303. Distribute content according to the shortest pull path from each pull node to at least one corresponding push node.

[0032] In this embodiment, a probe node with probing capabilities can request the communication status and latency between any two CDN nodes in a subset or all of the content delivery network's CDN nodes. It should be understood that, for every two CDN nodes in the entire content delivery network's CDN nodes, the communication status and latency between those two CDN nodes are obtained. For every two CDN nodes in a subset of the content delivery network's CDN nodes, the communication status and latency between those two CDN nodes are also obtained.

[0033] Typically, a probe node can trigger one of two CDN nodes to send a probe request to the other. Whether the other CDN node returns a response indicates whether the communication status between the two CDN nodes is communicative or not. The time from sending the probe request to receiving the response, i.e., the round trip time (RTT), is used as the communication latency between the two CDN nodes. For more information on the network status between probe nodes, please refer to relevant technical documentation.

[0034] In this embodiment, in addition to obtaining the communication status and latency between each pair of CDN nodes in some or all of the content delivery network (CDN), it is also necessary to obtain the current remaining bandwidth of each CDN node. The current remaining bandwidth of each CDN node can be determined based on its total available bandwidth and its current used bandwidth. Specifically, the current remaining bandwidth of each CDN node is obtained by subtracting its current used bandwidth from its total available bandwidth. In practical applications, any CDN node in the content delivery network can maintain the total available bandwidth of each CDN node and monitor its current used bandwidth in real time, calculating the current remaining bandwidth of each CDN node based on its total available bandwidth and the monitored current used bandwidth. Alternatively, an external system independent of the content delivery network can monitor the current used bandwidth of each CDN node in real time; for example, a log server can monitor the current used bandwidth of each CDN node in real time. In this case, the content delivery network can request the log server to send the current used bandwidth of each monitored CDN node.

[0035] In this embodiment, at least one CDN node is selected from the multiple CDN nodes included in the content delivery network as at least one streaming node, and for each streaming node, at least one corresponding streaming node is selected from the multiple CDN nodes included in the content delivery network. It is worth noting that all CDN nodes can be selected as streaming nodes from the multiple CDN nodes included in the content delivery network, or a portion of the CDN nodes can be selected as streaming nodes. For each streaming node, one or more CDN nodes are selected from the multiple CDN nodes other than the streaming node in the content delivery network as the streaming nodes for that streaming node. That is, the number of streaming nodes can be one or more, and the number of streaming nodes corresponding to each streaming node can be one or more. In this embodiment, after obtaining the network status data of the content delivery network, path planning can be performed based on the network status data to obtain the shortest streaming path from each streaming node to its corresponding at least one streaming node. In practical applications, any CDN node located at the edge can be considered a pull node, and any other CDN node at the edge (excluding the pull node) can be considered a push node. The shortest pull path from the pull node to its corresponding push node is then planned. It's important to note that the shortest pull path refers to the path with the lowest communication latency. The pull node retrieves the required content data from the corresponding push node via the shortest pull path in the shortest time. Therefore, content distribution via the shortest pull path effectively meets the requirements of low latency and low cost.

[0036] In practical applications, during path planning, the communication status between two CDN nodes ensures that adjacent CDN nodes on any planned streaming path are communicable, thus guaranteeing the effectiveness of the planned path. The communication latency between two CDN nodes effectively controls the latency of the planned streaming path, providing a foundation for shortest path planning. The current remaining bandwidth of CDN nodes effectively prevents insufficient bandwidth from appearing on the planned path, effectively limiting network traffic to each CDN node and reducing the load on each node.

[0037] As an example, when planning a streaming path, one can first select several relay nodes between the streaming node and the push node, based on the condition that communication between adjacent CDN nodes is possible. The path that sequentially passes through the streaming node, the relay nodes, and the push node is then considered the streaming path. The communication latency between adjacent CDN nodes along the streaming path is accumulated to obtain the streaming path's communication latency. Typically, multiple streaming paths can be planned for each pair of streaming nodes and push nodes. Next, the streaming paths with the lowest communication latency can be selected. Finally, streaming paths with insufficient remaining bandwidth for CDN nodes are removed from the multiple streaming paths with the lowest communication latency. At least one remaining streaming path can be considered as at least one shortest streaming path between the streaming node and the push node. Alternatively, one can first eliminate streaming paths with insufficient remaining bandwidth that contain CDN nodes, and then select at least one streaming path with the lowest communication latency from the remaining multiple streaming paths as the minimum shortest streaming path, without further restrictions. Further optionally, a filtering condition can be added that the minimum shortest streaming paths cannot have the same relay node. This allows for a further filtering of the minimum streaming path with the lowest communication latency that meets the bandwidth requirement, selecting at least one minimum shortest streaming path that satisfies the above filtering conditions. Within this minimum shortest streaming path, no two pairs of minimum shortest streaming paths can have the same relay node.

[0038] As another example, when planning the path, for each group of pull and push nodes, multiple pull paths with different hop counts can be planned from the pull node to the push node. The hop count reflects the number of relay nodes traversed from the pull node to the push node. The hop count is one more than the number of relay nodes. For example, if the number of relay nodes is 0, the hop count is 1; if the number of relay nodes is 1, the hop count is 2; and so on, with the hop count being one more than the number of relay nodes. Next, based on the communication latency corresponding to each pull path, multiple candidate shortest pull paths with the lowest communication latency are selected from the pull paths with different hop counts. Finally, using the filtering conditions that different shortest pull paths cannot have the same relay node and that the current remaining bandwidth of each CDN node on the shortest pull path is greater than a bandwidth threshold, multiple shortest pull paths from the pull node to the push node that meet the filtering conditions are selected from the multiple candidate pull paths. The bandwidth threshold can be flexibly set according to actual application requirements.

[0039] After determining the shortest pull path from each pull node to its corresponding at least one push node, content distribution can be performed according to this shortest pull path. Specifically, after any pull node receives a pull request from a user for any push node, it forwards the pull request through each CDN node along the shortest pull path until the pull request reaches the push node. The push node responds to the pull request by retrieving locally cached content data and forwarding the content data through each CDN node along the shortest pull path until the content data reaches the pull node. After retrieving the content data, the pull node pushes the content data to the user, thus completing the entire pull task.

[0040] In practical applications, the scheduling node can maintain and manage the path information of the shortest pull path from each pull node to its corresponding at least one push node. This path information includes, but is not limited to, the identification information of each CDN node on the shortest pull path, and the order of these CDN nodes on the shortest pull path. After receiving a pull request from a user for any push node, the pull node sends its own identification information and the push node's identification information to the scheduling node, allowing the scheduling node to determine the path information of the shortest pull path corresponding to the pull request. Each CDN node on the shortest pull path, upon receiving a pull request from the previous CDN node, can send its own identification information and the pull request's request identifier to the scheduling node, and receive the identification information of the next CDN node to be passed on from the scheduling node. It then passes the pull request to the next CDN node until it reaches the push node, thus completing the pull request transmission task. During the content data return to the pull node, the content data sequentially passes through each CDN node on the shortest pull path until it reaches the pull node.

[0041] In practical applications, the path information of the shortest pull path from each pull node to each push node can also be pushed to each pull node. When each CDN node on the shortest pull path transmits a pull request, it can encapsulate the path information of the shortest pull path into the pull request, so that each CDN node can accurately determine the next CDN node to receive the pull request, ensuring that the pull request is accurately sent to the push node. Similarly, when each CDN node on the shortest pull path transmits content data from the push node, it can also transmit the path information of the shortest pull path simultaneously, so that the content data is accurately returned to the pull node.

[0042] The technical solution provided in this application performs path planning based on network status data of the content delivery network (CDN). This involves planning the shortest pull path from each pull node to each push node, thereby enabling interconnection among multiple CDN nodes and presenting the CDN as a mesh network structure rather than a tree-like structure. To a certain extent, this achieves decentralized mesh routing for path planning. Furthermore, by comprehensively considering network status data such as communication status and latency between CDN nodes, as well as the current remaining bandwidth of each CDN node, the pull path from the pull node to the push node is selected. This significantly increases the probability of obtaining a pull path with lower latency, effectively controls the bandwidth of each CDN node on the pull path, greatly reduces the occurrence of excessive network traffic at CDN nodes, and improves content distribution efficiency. It is particularly suitable for complex point-to-point routing scenarios with a massive number of nodes.

[0043] In some optional embodiments, when performing path planning based on network status data, for any target streaming node among at least one streaming node and any target push node among at least one push node corresponding to the target streaming node, at least one relay CDN node whose communication status with the target push node is communicable can be selected from the CDN nodes included in the CDN, excluding the target streaming node and the target push node; based on the shortest streaming paths with multiple different hop counts from the target streaming node to each relay CDN node, and the shortest streaming path with 1 hop count from each relay CDN node to the target push node, a set of shortest streaming paths from the target streaming node to the target push node is determined; and at least one shortest streaming path from the target streaming node to the target push node with a current remaining bandwidth greater than the bandwidth threshold is selected from the set of shortest streaming paths.

[0044] In this embodiment, the target pull node is any one of at least one pull node, and the target push node is any one of multiple push nodes corresponding to the target pull node. Each CDN node among at least one CDN node whose communication status with the target push node is communicable is considered a relay CDN node. This relay CDN node serves as the last relay CDN node on the pull path from the target pull node to the target push node, i.e., the relay CDN node adjacent to the target push node. Thus, the pull path from the target pull node to the target push node can be divided into two segments: the first segment is from the target pull node to the relay CDN node, and the second segment is from the relay CDN node to the target push node. For a given relay CDN node, finding the shortest pull path from the target pull node to the relay CDN node determines a shortest pull path from the target pull node to the target push node. When multiple relay CDN nodes act as the last relay CDN node adjacent to the target push node, multiple shortest pull paths from the target pull node to the target push node can be obtained. The number of hops in these shortest pull paths may be the same or different, depending on the communication latency between CDN nodes.

[0045] For example, suppose a content delivery network includes multiple CDN nodes such as CDN node 1, CDN node 2, CDN node 3, CDN node 4, CDN node 5, and CDN node 6.

[0046] For example, suppose a content delivery network includes multiple CDN nodes: CDN node 1, CDN node 2, CDN node 3, CDN node 4, CDN node 5, and CDN node 6. When planning the shortest streaming path from CDN node 1 to CDN node 6, CDN nodes 2, 3, 4, and 5 are sequentially designated as the last relay CDN node on the streaming path from CDN node 1 to CDN node 6. Following the order of hop count from smallest to largest, the following steps are repeated: the shortest streaming path from CDN node 1 to the last relay CDN node with the smallest communication latency (one hop less than the current hop count) is concatenated with the streaming path from the last relay CDN node to node 6 with one hop count, resulting in a candidate shortest streaming path from CDN node 1 to CDN node 6. In this way, multiple candidate shortest streaming paths with different hop counts can be obtained from CDN node 1 to CDN node 6 via each last relay CDN node. Taking CDN node 2 as the last relay CDN node as an example, multiple candidate shortest streaming paths with different hop counts include: a candidate shortest streaming path with 2 hops consisting of CDN node 1-CDN node 2-CDN node 6, a candidate shortest streaming path with 3 hops consisting of CDN node 1-CDN node 3-CDN node 2-CDN node 6, a candidate shortest streaming path with 4 hops consisting of CDN node 1-CDN node 3-CDN node 4-CDN node 2-CDN node 6, and so on. With CDN node 2, CDN node 3, CDN node 4, and CDN node 5 as the last relay CDN node on the streaming path from CDN node 1 to CDN node 6, multiple candidate shortest streaming paths with different hop counts can be obtained from CDN node 1 to CDN node 6. From these multiple candidate shortest streaming paths with different hop counts, several candidate shortest streaming paths with the smallest communication latency are selected and added to the set of shortest streaming paths associated with CDN node 1 to CDN node 6.

[0047] In this embodiment, the shortest streaming path with remaining bandwidth greater than the bandwidth threshold refers to a path where the remaining bandwidth of each CDN node is greater than the bandwidth threshold, meaning each CDN node has sufficient bandwidth. The bandwidth threshold can be flexibly set according to actual application requirements. Adding bandwidth constraints when selecting the set of shortest streaming paths can significantly reduce the likelihood of CDN nodes on the shortest streaming paths experiencing excessive load during content distribution, thus ensuring the reliability of content distribution.

[0048] In practical applications, different shortest pull paths sharing the same relay node may interfere with the reliability of content distribution. For example, when the same relay node receives pull requests for different push nodes at the same time, the same relay node responding to multiple pull requests simultaneously can easily lead to significant load pressure, thus affecting normal content distribution. Therefore, to improve the reliability of content distribution, in addition to adding bandwidth constraints, a constraint that "different shortest pull paths cannot share the same relay node" can be added. Thus, selecting at least one shortest pull path from the set of shortest pull paths that connects the target pull node to the target push node with a current remaining bandwidth greater than the bandwidth threshold includes: selecting at least one shortest pull path from the set of shortest pull paths with a current remaining bandwidth greater than the bandwidth threshold; and selecting at least one shortest pull path that meets the selection condition that different shortest pull paths cannot share the same relay node.

[0049] In some optional embodiments, when planning the shortest pull path from the pull node to the push node using the shortest pull path from the pull node to the last relay node and the shortest pull path from the last relay node to the push node with a hop count of 1, a hop count limit can be added to ensure content distribution efficiency. Furthermore, path planning is performed sequentially in ascending order of hop count. Each time a hop is added, the shortest pull path for the next hop count can be accurately planned based on the shortest pull path for the previous hop count and the shortest pull path with a hop count of 1, thereby efficiently and accurately planning the shortest pull paths between nodes. Therefore, embodiments of this application also provide a content distribution method. Figure 4 A flowchart illustrating another content distribution method provided in this application embodiment. This method can be executed by a content distribution device, which can typically be integrated into any CDN node within a CDN. See also... Figure 4 The method may include the following steps:

[0050] 400. Obtain network status data of the content delivery network. The network status data includes the communication status and communication latency between any two CDN nodes in some or all of the CDN nodes, as well as the current remaining bandwidth of each CDN node in some or all of the CDN nodes.

[0051] 401. Select at least one CDN node from the multiple CDN nodes included in the content delivery network as at least one pull node, and select at least one corresponding push node from the multiple CDN nodes included in the content delivery network for each pull node.

[0052] 402. For any target streaming node among at least one streaming node, and any target push node among at least one or more push nodes corresponding to the target streaming node, select at least one relay CDN node whose communication status with the target push node is communicable from the CDN nodes included in the CDN other than the target streaming node and the target push node.

[0053] 403. Add the shortest pull path with a hop count of 1 from the target pull node to the target push node to the shortest pull path set, and set the current hop count to 2.

[0054] 404. Based on the shortest pull path from the target pull node to each relay CDN node with one less hop than the current hop count and the shortest pull path from each relay CDN node to the target push node with one hop count, determine multiple candidate shortest pull paths from the target pull node to the target push node with the current hop count, and determine the communication delay of each of the multiple candidate shortest pull paths with the current hop count.

[0055] 405. Select the candidate shortest streaming path with the minimum communication latency and the current hop count as the shortest streaming path set.

[0056] 406. Determine if the current number of hops has reached the maximum allowed number of hops. If not, proceed to step 407. If yes, proceed to step 408.

[0057] 407. Increment the current hop count by 1 and return to step 404 until the current hop count reaches the maximum allowed hop count.

[0058] 408. Select at least one shortest streaming path from the target streaming node to the target push node from the set of shortest streaming paths, where the current remaining bandwidth is greater than the bandwidth threshold.

[0059] 409. Distribute content according to the shortest pull path from each pull node to at least one corresponding push node.

[0060] For details on the specific implementation of steps 400, 401, 408 and 409 in this embodiment, please refer to the detailed description of the foregoing embodiments, which will not be repeated here.

[0061] In this embodiment, the maximum number of hops in the shortest pull path cannot exceed the maximum allowed number of hops. That is, the minimum number of hops in the shortest pull path is 1, and the maximum number is the maximum allowed number of hops. Following the order of hop count from smallest to largest, and constrained by the maximum allowed number of hops, and aided by the path planning result of the previous hop count, path planning is performed sequentially for each pull node to each push node based on the current hop count. Specifically, the current hop count starts from 1 and increases until it reaches the maximum allowed number of hops. Based on the shortest pull path from the target pull node to each relay CDN node that has one less hop than the current hop count, and the shortest pull path from each relay CDN node to the target push node with one hop count, multiple candidate shortest pull paths with the current hop count are determined from the target pull node to the target push node. In this way, the communication latency of multiple candidate shortest pull paths with the current hop count from the target pull node to the target push node can be determined based on the communication latency of the shortest pull path from the target pull node to each relay CDN node that has one less hop than the current hop count, and the communication latency of the pull path with one hop count from each relay CDN node to the target push node.

[0062] Specifically, the communication latency and communication status between pairs of CDN nodes have been detected by probe nodes with probing capabilities. For each pull stream node, at least one CDN node (excluding the pull node itself) is selected from all or some of the CDN nodes in the content delivery network as the pull stream node, and for each pull stream node, at least one other CDN node is selected as the push stream node. That is, each pull stream node can have one or more push stream nodes. For each pair of pull and push stream nodes, the other CDN nodes besides the pull and push stream nodes are each selected as a relay CDN node adjacent to the push stream node. The relay CDN node adjacent to the push stream node is also the last relay CDN node. Of course, the number of hops in the planned pull stream path will vary, resulting in different relay CDN nodes along the pull stream path.

[0063] Taking a maximum allowed hop count of 3 as an example, for each group of target pull nodes and target push nodes, starting from the minimum hop count of 1, the shortest pull path with 1 hop count from the target pull node to the target push node is added to the shortest pull path set corresponding to that group of target pull nodes and target push nodes. For example, for the group of CDN node 1 and CDN node 6, the shortest pull path with 1 hop count from CDN node 1 to CDN node 6 is added to its own shortest pull path set. For the group of CDN node 1 and CDN node 2, the shortest pull path with 1 hop count from CDN node 1 to CDN node 2 is added to its own shortest pull path set. And so on, adding the shortest pull path with 1 hop count for each group of target pull nodes and target push nodes to its own shortest pull path set.

[0064] Next, the current hop count is updated from 1 to 2, meaning the shortest pull path to be planned needs to pass through a relay node. At this point, the shortest pull path with 2 hops to be planned is divided into a shortest pull path with 1 hop from the target pull node to the relay node and a shortest pull path with 1 hop from the relay node to the target push node. Since the communication latency between any two CDN nodes is known, the communication latency of the shortest pull path with 2 hops is easily determined. Then, for each group of target pull nodes and target push nodes, several shortest pull paths with the smallest communication latency with 2 hops can be selected from the determined shortest pull paths and added to their own shortest pull path set. Thus, for each group of target pull nodes and target push nodes, the shortest pull path set contains both shortest pull paths with 1 hop and shortest pull paths with 2 hops. For example, for the group of CDN nodes 1 and 6, the shortest pull paths with 2 hops are CDN node 1-CDN node 2-CDN node 6, CDN node 1-CDN node 3-CDN node 6, and CDN node 1-CDN node 4-CDN node 6, respectively. These shortest pull paths with 2 hops are then added to the group's own shortest pull path set. Similarly, the shortest pull paths with 2 hops for each group of target pull nodes and target push nodes are added to the group's own shortest pull path set.

[0065] Next, the current hop count is updated from 2 to 3, meaning the shortest pull path to be planned needs to pass through two relay nodes. At this point, the shortest pull path with 3 hops to be planned is divided into a shortest pull path with 2 hops from the target pull node to the last relay node and a shortest pull path with 1 hop from the last relay node to the target push node. From the various sets of shortest pull paths, the shortest pull path with 2 hops can be obtained. Based on the communication latency of the shortest pull path with 2 hops and the known communication latency between each pair of CDN nodes, it is not difficult to determine the communication latency of each shortest pull path with 3 hops. Then, for each pair of target pull nodes and target push nodes, several shortest pull paths with 3 hops and the smallest communication latency can be selected from the determined shortest pull paths with 3 hops and added to its own shortest pull path set. Thus, for each group of target pull nodes and target push nodes, the set of shortest pull paths includes shortest pull paths with 1 hop, 2 hops, and 3 hops. For example, for the group of CDN nodes 1 and 6, the shortest pull paths with 3 hops are CDN node 1-CDN node 2-CDN node 3-CDN node 6, CDN node 1-CDN node 3-CDN node 4-CDN node 6, and CDN node 1-CDN node 5-CDN node 4-CDN node 6. These shortest pull paths with 3 hops are added to the group's own shortest pull path set. Similarly, the shortest pull paths with 3 hops for each group of target pull nodes and target push nodes are added to the group's own shortest pull path set.

[0066] The technical solution provided in this application performs path planning based on network status data of the content delivery network (CDN). This involves planning the shortest pull path from each pull node to each push node, thereby enabling interconnection among multiple CDN nodes and presenting the CDN as a mesh network structure rather than a tree-like structure. To a certain extent, this achieves decentralized mesh routing for path planning. Furthermore, by comprehensively considering network status data such as communication status and latency between CDN nodes, as well as the current remaining bandwidth of each CDN node, the pull path from the pull node to the push node is selected. This significantly increases the probability of obtaining a pull path with lower latency, effectively controls the bandwidth of each CDN node on the pull path, greatly reduces the occurrence of excessive network traffic at CDN nodes, and improves content distribution efficiency. It is particularly suitable for complex point-to-point routing scenarios with a massive number of nodes. Furthermore, a hop count limit is added during path planning to ensure content distribution efficiency. Additionally, path planning is performed sequentially in ascending order of hop count. When adding a hop, the shortest streaming path for the next hop count can be accurately planned based on the shortest streaming path for the previous hop count and the shortest streaming path for hop count 1, thereby efficiently and accurately planning the shortest streaming path between nodes.

[0067] In practical applications, after selecting the candidate shortest streaming paths with the minimum communication latency and the current hop count as the shortest streaming paths with the current hop count, multiple shortest streaming paths with the current hop count can be selectively added to the shortest streaming path set based on the number of shortest streaming paths already included in the set and the communication latency. This further increases the probability of obtaining streaming paths with even lower communication latency and improves the efficiency of content distribution. Based on this, embodiments of this application also provide a content distribution method for a content distribution network.

[0068] Figure 5 A flowchart illustrating another content distribution method provided in this application embodiment. This method can be executed by a content distribution device, which can typically be integrated into any CDN node within a CDN. See also... Figure 5 The method may include the following steps:

[0069] 500. Obtain network status data of the content delivery network. The network status data includes the communication status and communication latency between any two CDN nodes in some or all of the CDN nodes, as well as the current remaining bandwidth of each CDN node in some or all of the CDN nodes.

[0070] 501. Select at least one CDN node from the multiple CDN nodes included in the content delivery network as at least one pull node, and select at least one corresponding push node from the multiple CDN nodes included in the content delivery network for each pull node.

[0071] 502. For any target streaming node among at least one streaming node and any target push node among at least one push node corresponding to the target streaming node, select at least one relay CDN node whose communication status with the target push node is communicable from the CDN nodes included in the CDN other than the target streaming node and the target push node.

[0072] 503. Add the shortest pull path with a hop count of 1 from the target pull node to the target push node to the shortest pull path set, and set the current hop count to 2.

[0073] 504. Based on the shortest pull path from the target pull node to each relay CDN node with one less hop than the current hop count and the shortest pull path from each relay CDN node to the target push node with one hop count, determine multiple candidate shortest pull paths from the target pull node to the target push node with the current hop count, and determine the communication delay of each of the multiple candidate shortest pull paths with the current hop count.

[0074] 505. Determine whether the number of shortest streaming paths added to the shortest streaming path set has reached the set threshold. If the result is yes, proceed to step 506. If the result is no, proceed to step 507.

[0075] 506. Among the multiple candidate shortest streaming paths with the current hop count that have never been selected, select the candidate shortest streaming path with the smallest communication latency as the shortest streaming path to be added; add the shortest streaming path to be added to the shortest streaming path set, and return to step 505.

[0076] 507. Among the multiple candidate shortest streaming paths with the current hop count that have never been selected, select the candidate shortest streaming path with the smallest communication latency as the shortest streaming path to be added.

[0077] 508. Determine whether there is an already added shortest streaming path in the shortest streaming path set whose communication delay is greater than that of the shortest streaming path to be added. If the determination result is yes, then proceed to step 509; if the determination result is no, then proceed to step 510.

[0078] 509. Delete the already added shortest streaming path whose communication latency is greater than that of the shortest streaming path to be added, and add the shortest streaming path to be added to the shortest streaming path set, and return to step 507 until there are no already added shortest streaming paths whose communication latency is greater than that of the shortest streaming path to be added in the shortest streaming path set.

[0079] 510. Determine if the current number of hops has reached the maximum allowed number of hops. If not, proceed to step 511. If yes, proceed to step 512.

[0080] 511. Increment the current hop count by 1 and return to step 504 until the current hop count reaches the maximum allowed hop count.

[0081] 512. Select at least one shortest streaming path from the target streaming node to the target push node from the set of shortest streaming paths, where the current remaining bandwidth is greater than the bandwidth threshold.

[0082] 513. Distribute content according to the shortest pull path from each pull node to at least one corresponding push node.

[0083] The implementation methods of steps 500 to 504 and steps 510 to 513 in this embodiment can be found in the relevant content of the foregoing embodiments, and will not be repeated here.

[0084] In this embodiment, after determining multiple candidate shortest streaming paths with the current hop count from the target streaming node to the target streaming node, and the communication latency of each candidate shortest streaming path, the addition of multiple candidate shortest streaming paths with the current hop count to the shortest streaming path set is controlled based on the number of shortest streaming paths already added to the shortest streaming path set and the communication latency. Specifically, the maximum value of the number of shortest streaming paths already added to the shortest streaming path set is a set threshold, which is set according to actual application requirements. For the shortest streaming path with 1 hop count from the target streaming node to the target streaming node, the shortest streaming path with 1 hop count from the target streaming node to the target streaming node is directly added to the corresponding shortest streaming path set. As time progresses, the hop count increases, and the number of shortest streaming paths already added to the shortest streaming path set increases until the number of shortest streaming paths already added to the shortest streaming path set equals the set threshold. For each current hop count, before the number of shortest streaming paths already added to the shortest streaming path set reaches a set threshold, the candidate shortest streaming path with the lowest communication latency among multiple candidate shortest streaming paths with the current hop count is added to the shortest streaming path set as the shortest streaming path to be added. Once the number of shortest streaming paths already added to the shortest streaming path set reaches the set threshold, only shortest streaming paths with lower communication latency can replace those with higher communication latency in the shortest streaming path set, until there are no shortest streaming paths in the shortest streaming path set with a communication latency greater than the shortest streaming path to be added. At the current hop count, if there are no shortest streaming paths in the shortest streaming path set with a communication latency greater than the shortest streaming path to be added, the current hop count is updated until the current hop count reaches the maximum allowed hop count, thus effectively controlling the communication latency of the shortest streaming paths already added to the shortest streaming path set to remain at a low level.

[0085] The technical solution provided in this application performs path planning based on network status data of the content delivery network (CDN). This involves planning the shortest pull path from each pull node to each push node, thereby enabling interconnection among multiple CDN nodes and presenting the CDN as a mesh network structure rather than a tree-like structure. To a certain extent, this achieves decentralized mesh routing for path planning. Furthermore, by comprehensively considering network status data such as communication status and latency between CDN nodes, as well as the current remaining bandwidth of each CDN node, the pull path from the pull node to the push node is selected. This significantly increases the probability of obtaining a pull path with lower latency, effectively controls the bandwidth of each CDN node on the pull path, greatly reduces the occurrence of excessive network traffic at CDN nodes, and improves content distribution efficiency. It is particularly suitable for complex point-to-point routing scenarios with a massive number of nodes. Furthermore, a hop count limit is added during path planning to ensure content distribution efficiency. Additionally, path planning is performed sequentially in ascending order of hop count. With each additional hop, the shortest streaming path for the next hop count can be accurately planned based on the shortest streaming path for the previous hop count and the shortest streaming path with 1 hop count, thus efficiently and accurately planning the shortest streaming paths between nodes. Furthermore, based on the number of shortest streaming paths already included in the shortest streaming path set and communication latency, multiple shortest streaming paths with the current hop count are selectively added to the shortest streaming path set, further increasing the probability of obtaining streaming paths with lower communication latency.

[0086] In some application scenarios, based on the functional division of CDN nodes in a content delivery network, the CDN nodes can be divided into probe nodes, scheduling nodes, and multiple edge nodes. Any edge node can act as a pull stream node or a push stream node. Combined with... Figure 6 A specific scenario implementation example is introduced; see [link / reference]. Figure 6 In step ①, the probe node detects the communication status and latency between any two edge nodes, and sends the detection results to the scheduling node. If the scheduling node maintains and manages the current used bandwidth of each edge node, it can determine the current remaining bandwidth of each edge node based on the total available bandwidth and the current used bandwidth of each edge node. If the scheduling node does not maintain and manage the current used bandwidth of each edge node, see [link to relevant documentation]. Figure 6 As shown in ②, the scheduling node can obtain the current used bandwidth of each edge node from the log server. See also... Figure 6As shown in ③, the scheduling node can determine the current remaining bandwidth of each edge node based on the total available bandwidth of each edge node and the current used bandwidth of each edge node. The scheduling node obtains the communication status and communication latency between any two edge nodes in some or all of the edge nodes, and determines the current remaining bandwidth of each edge node in some or all of the edge nodes; see [link to documentation]. Figure 6 As shown in ④, the scheduling node selects the pull and push nodes. Specifically, it selects at least one edge node from multiple edge nodes as at least one pull node, and for each pull node, it selects at least one corresponding push node from multiple edge nodes; see [link to relevant documentation]. Figure 6 As shown in ⑤, the scheduling node performs path planning based on network status data to obtain the shortest streaming path from each streaming node to its corresponding at least one pushing node; see also Figure 6 As shown in ⑥, the scheduling node distributes content according to the shortest pull path from each pull node to at least one corresponding push node.

[0087] In practical applications, the scheduling node can maintain and manage the path information of the shortest pull path from each pull node to its corresponding at least one push node. This path information includes, but is not limited to, the identification information of each edge node on the shortest pull path, and the order of these edge nodes on the shortest pull path. After receiving a pull request from a user for any push node, the pull node sends its own identification information and the push node's identification information to the scheduling node, allowing the scheduling node to determine the path information of the shortest pull path corresponding to the pull request. Each edge node on the shortest pull path, upon receiving a pull request from the previous edge node, can send its own identification information and the pull request's request identifier to the scheduling node, and receive the identification information of the next edge node to be passed on from the scheduling node. It then passes the pull request to the next edge node until it reaches the push node, thus completing the pull request transmission task. In the content data return to the pull node stage, the content data sequentially passes through each edge node on the shortest pull path until it reaches the pull node.

[0088] In practical applications, the path information of the shortest pull path from each pull node to its corresponding at least one push node can also be pushed to each pull node. When each edge node on the shortest pull path transmits a pull request, it can encapsulate the path information of the shortest pull path into the pull request, so that each edge node can accurately determine the next edge node to receive the pull request, ensuring that the pull request is accurately sent to the push node. Similarly, when each edge node on the shortest pull path transmits content data from the push node, it can also transmit the path information of the shortest pull path simultaneously, so that the content data is accurately returned to the pull node.

[0089] For a specific example, each edge node can act as a push node, caching the live stream pushed by the broadcaster. Each edge node can also act as a pull node. Based on a viewer's pull request for the live stream cached on any push node, the edge nodes are accessed sequentially according to the shortest pull path until a push node is reached. The cached live stream is then pulled from the push node and returned to the pull node according to the shortest pull path. The pull node then provides the live stream to the viewer for viewing. Because any edge node can act as either a pull or push node, and any pull node can access any push node, the entire content distribution network exhibits a mesh structure. Content data cached on edge nodes can be directly pushed to other edge nodes without going through a scheduling node, significantly reducing viewing latency in live streaming scenarios. This meets the low latency and low cost requirements of both live streaming and video-on-demand scenarios, and effectively addresses the diverse and complex nature of business scenarios.

[0090] about Figure 6 For a detailed explanation of the steps involved in the content distribution network performing the content distribution method, please refer to the foregoing embodiments.

[0091] Figure 7 This is a schematic diagram of a content distribution device provided in an embodiment of this application. See also... Figure 7 The device may include:

[0092] The acquisition module 70 is used to acquire CDN network status data, which includes the communication status and communication latency between pairs of CDN nodes in some or all CDN nodes of the content delivery network, as well as the current remaining bandwidth of each CDN node in some or all CDN nodes.

[0093] Selection module 71 is used to select at least one CDN node from the multiple CDN nodes included in the content delivery network as at least one pull node, and to select at least one corresponding push node from the multiple CDN nodes included in the content delivery network for each pull node.

[0094] The path planning module 72 is used to perform path planning based on network status data to obtain the shortest streaming path from each streaming node to its corresponding at least one streaming node.

[0095] The content distribution module 73 is used to distribute content according to the shortest pull path from each pull node to its corresponding at least one push node.

[0096] Further optionally, the path planning module 72 is specifically used for: for any target streaming node among at least one streaming node and any target push node among at least one push node corresponding to the target streaming node, selecting at least one relay CDN node whose communication status with the target push node is communicable from the CDN nodes included in the CDN, excluding the target streaming node and the target push node; determining a set of shortest streaming paths from the target streaming node to the target push node based on multiple shortest streaming paths with different hop counts from the target streaming node to each relay CDN node, and the shortest streaming path with 1 hop count from each relay CDN node to the target push node; and filtering at least one shortest streaming path from the target streaming node to the target push node from the set of shortest streaming paths where the current remaining bandwidth is greater than the bandwidth threshold.

[0097] Optionally, when the path planning module 72 determines the set of shortest pull paths from the target pull node to the target push node, it specifically: adds the shortest pull path with a hop count of 1 from the target pull node to the target push node to the shortest pull path set, and sets the current hop count to 2; based on the shortest pull path from the target pull node to each relay CDN node that has 1 less hop than the current hop count and the shortest pull path from each relay CDN node to the target push node with a hop count of 1, it determines the path from the target pull node to the target push node with the current hop count... The system identifies multiple candidate shortest streaming paths and determines the communication latency of each path with the current hop count. It then selects the path with the lowest communication latency and the current hop count as the shortest streaming path and adds it to the shortest streaming path set. Finally, it checks if the current hop count has reached the maximum allowed hop count. If not, it increments the current hop count by 1 and returns to the previous steps to determine the shortest streaming paths from the target streaming node to the target push node, continuing this process until the current hop count reaches the maximum allowed hop count.

[0098] Optionally, when the path planning module 72 determines the communication delay of each of the multiple candidate shortest pull paths with the current hop count, it is specifically used to: determine the communication delay of the multiple candidate shortest pull paths with the current hop count from the target pull node to the target push node based on the communication delay of the shortest pull path from the target pull node to each relay CDN node that has one less hop than the current hop count, and the communication delay of the pull path from each relay CDN node to the target push node that has one hop count.

[0099] Optionally, when the path planning module 72 selects the candidate shortest streaming path with the minimum communication latency and the current hop count as the shortest streaming path to add to the shortest streaming path set, it specifically performs the following steps: determining whether the number of shortest streaming paths already added to the shortest streaming path set has reached a set threshold; if the determination result is yes, then selecting the candidate shortest streaming path with the minimum communication latency from the unselected candidate shortest streaming paths with the current hop count as the shortest streaming path to be added; if there is an already added shortest streaming path in the shortest streaming path set with a communication latency greater than the shortest streaming path to be added, then deleting the already added shortest streaming path with a communication latency greater than the shortest streaming path to be added; adding the shortest streaming path to be added to the shortest streaming path set, and returning to execute the step of selecting the candidate shortest streaming path with the minimum communication latency as the shortest streaming path to be added, until there is no already added shortest streaming path in the shortest streaming path set with a communication latency greater than the shortest streaming path to be added.

[0100] Optionally, the path planning module 72 is further configured to: if the judgment result is negative, select the candidate shortest streaming path with the smallest communication latency from the multiple candidate shortest streaming paths with the current hop count that have not been selected as the shortest streaming path to be added; add the shortest streaming path to be added to the set of shortest streaming paths; and return to execute the step of judging whether the number of shortest streaming paths already added to the set of shortest streaming paths has reached the set number threshold.

[0101] Optionally, when the path planning module 72 selects at least one shortest streaming path from the target streaming node to the target push node with the current remaining bandwidth greater than the bandwidth threshold from the set of shortest streaming paths, it is specifically used to: select at least one shortest streaming path with the current remaining bandwidth greater than the bandwidth threshold from the set of shortest streaming paths; and select at least one shortest streaming path that meets the selection criteria from the at least one shortest streaming path with the current remaining bandwidth greater than the bandwidth threshold, based on the condition that different shortest streaming paths cannot have the same relay node.

[0102] Optionally, when the acquisition module 70 acquires the current remaining bandwidth of each CDN node in some or all CDN nodes, it is specifically used to: for each CDN node in some or all CDN nodes, determine the current remaining bandwidth of the CDN node based on the total available bandwidth of the CDN node and the current used bandwidth of the CDN node.

[0103] Figure 7 The device shown can perform Figure 3 The implementation principle and technical effects of the method shown will not be elaborated further. Regarding the above embodiments... Figure 7The specific ways in which each module and unit of the device performs operations have been described in detail in the embodiments of the method, and will not be elaborated here.

[0104] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 300 to 303 can be device A; or the execution subject of steps 300 to 302 can be device A, and the execution subject of step 303 can be device B; and so on.

[0105] Furthermore, in some of the processes described in the above embodiments and accompanying drawings, multiple operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 301, 302, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0106] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device includes: a memory 81 and a processor 82;

[0107] Memory 81 is used to store computer programs and can be configured to store various other data to support operation on the computing platform. Examples of this data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc.

[0108] The memory 81 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0109] The processor 82, coupled to the memory 81, is used to execute a computer program in the memory 81 for: acquiring network status data of the CDN, the network status data including the communication status and communication latency between pairs of CDN nodes in some or all of the CDN nodes of the content delivery network, and the current remaining bandwidth of each CDN node in some or all of the CDN nodes; selecting at least one CDN node from the plurality of CDN nodes included in the content delivery network as at least one streaming node, and selecting at least one corresponding streaming node from the plurality of CDN nodes included in the content delivery network for each streaming node; performing path planning based on the network status data to obtain the shortest streaming path from each streaming node to its corresponding at least one streaming node; and distributing content according to the shortest streaming path from each streaming node to its corresponding at least one streaming node.

[0110] Furthermore, such as Figure 8 As shown, the electronic device also includes other components such as a communication component 83, a display 84, a power supply component 85, and an audio component 86. Figure 8 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 8 The components shown. Additionally... Figure 8 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the form factor of the electronic device. The electronic device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server-side device such as a conventional server, cloud server, or server array. If the electronic device in this embodiment is a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 8 The components within the dashed box; if the electronic device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., it may be omitted. Figure 8 The component within the dashed box.

[0111] For a detailed description of the implementation process of each action by the processor, please refer to the relevant descriptions in the foregoing method embodiments or device embodiments, which will not be repeated here.

[0112] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can perform the steps that can be executed by an electronic device in the above method embodiments.

[0113] Accordingly, this application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, enables the processor to perform the steps that can be executed by an electronic device in the above method embodiments.

[0114] The aforementioned communication components are configured to facilitate wired or wireless communication between the device containing the communication components and other devices. The device containing the communication components can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, and other mobile communication networks, or combinations thereof. In one exemplary embodiment, the communication components receive broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication components also include a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0115] The aforementioned display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0116] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0117] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0118] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0119] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0120] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0121] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0122] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0123] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0124] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0125] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0126] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A content distribution method, characterized in that, Applied to a content delivery network, the content delivery network comprising multiple content delivery network (CDN) nodes, the method includes: Obtain network status data of the content delivery network, the network status data including the communication status and communication latency between pairs of CDN nodes in some or all of the content delivery network CDN nodes, and the current remaining bandwidth of each CDN node in some or all of the CDN nodes; At least one CDN node is selected from the plurality of CDN nodes included in the content delivery network as at least one pull stream node, and at least one corresponding push stream node is selected from the plurality of CDN nodes included in the content delivery network for each pull stream node; For any target streaming node among at least one streaming node, and any target pushing node among at least one corresponding streaming node, at least one relay CDN node whose communication status with the target pushing node is communicable is selected from the CDN nodes included in the CDN, excluding the target streaming node and the target pushing node. Based on the shortest streaming paths with multiple different hop counts from the target streaming node to each relay CDN node, and the shortest streaming path with 1 hop count from each relay CDN node to the target pushing node, a set of shortest streaming paths from the target streaming node to the target pushing node is determined. From the set of shortest streaming paths, at least one shortest streaming path from the target streaming node to the target pushing node with a current remaining bandwidth greater than a bandwidth threshold is selected, thereby enabling multiple CDN nodes to interconnect and realizing a mesh network structure for the content delivery network. Content is distributed based on the shortest pull path from each pull node to at least one corresponding push node. The determination of the set of shortest streaming paths from the target streaming node to the target streaming push node includes: Add the shortest pull path with 1 hop count from the target pull node to the target push node to the shortest pull path set, and set the current hop count to 2; Based on the shortest pull path from the target pull node to each of the relay CDN nodes with one less hop than the current hop count and the shortest pull path from each of the relay CDN nodes to the target push node with one hop count, determine multiple candidate shortest pull paths from the target pull node to the target push node with the current hop count, and determine the communication latency of each of the multiple candidate shortest pull paths with the current hop count. Select the candidate shortest streaming path with the minimum communication latency and the current hop count as the shortest streaming path set and add it to the shortest streaming path set. Determine whether the current hop count has reached the maximum allowed hop count. If not, increment the current hop count by 1 and return to the step of determining multiple candidate shortest pull paths from the target pull node to the target push node with the current hop count, until the current hop count reaches the maximum allowed hop count.

2. The method according to claim 1, characterized in that, Determining the communication latency of each of the multiple candidate shortest streaming paths with the current hop count includes: Based on the communication latency of the shortest pull path from the target pull node to each of the relay CDN nodes with one less hop than the current hop count, and the communication latency of the pull path from each of the relay CDN nodes to the target push node with one hop count, the communication latency of multiple candidate shortest pull paths from the target pull node to the target push node with the current hop count is determined.

3. The method according to claim 1, characterized in that, Selecting the candidate shortest streaming paths with the minimum communication latency and the current hop count as the shortest streaming paths with the current hop count and adding them to the shortest streaming path set, including: Determine whether the number of shortest streaming paths already included in the shortest streaming path set has reached a set threshold. If the judgment result is yes, then among the multiple candidate shortest streaming paths with the current hop count that have never been selected, the candidate shortest streaming path with the smallest communication delay is selected as the shortest streaming path to be added. If there is an already added shortest streaming path in the set of shortest streaming paths with a communication delay greater than that of the shortest streaming path to be added, then delete the already added shortest streaming path with a communication delay greater than that of the shortest streaming path to be added. The shortest streaming path to be added is added to the set of shortest streaming paths, and the process returns to the step of selecting the candidate shortest streaming path with the smallest communication latency as the shortest streaming path to be added, until there is no shortest streaming path already added in the set of shortest streaming paths with a communication latency greater than the shortest streaming path to be added.

4. The method according to claim 3, characterized in that, Also includes: If the judgment result is negative, then among the multiple candidate shortest streaming paths with the current hop count that have not been selected, the candidate shortest streaming path with the smallest communication delay is selected as the shortest streaming path to be added. The process involves adding the shortest streaming path to be added to the set of shortest streaming paths, and then returning to the execution step of determining whether the number of shortest streaming paths already added to the set of shortest streaming paths has reached a set threshold.

5. The method according to any one of claims 1 to 4, characterized in that, Selecting at least one shortest streaming path from the target streaming node to the target pushing node from the set of shortest streaming paths, where the current remaining bandwidth is greater than the bandwidth threshold, includes: Select at least one shortest streaming path from the set of shortest streaming paths whose current remaining bandwidth is greater than the bandwidth threshold; Using the condition that different shortest streaming paths cannot have the same relay node as a filtering condition, at least one shortest streaming path that meets the filtering condition is selected from at least one shortest streaming path whose current remaining bandwidth is greater than the bandwidth threshold.

6. The method according to any one of claims 1 to 4, characterized in that, Obtaining the current remaining bandwidth of each CDN node in some or all CDN nodes includes: For each CDN node in some or all CDN nodes, determine the current remaining bandwidth of the CDN node based on the total available bandwidth of the CDN node and the current used bandwidth of the CDN node.

7. A content delivery network, characterized in that, include: Detection nodes, scheduling nodes, and multiple edge nodes; The detection node is used to detect the communication status and communication delay between any two edge nodes in some or all of the edge nodes. The scheduling node is used to obtain the communication status and communication latency between pairs of edge nodes among some or all of the edge nodes detected by the probe node, and to determine the current remaining bandwidth of each edge node among some or all of the edge nodes; to select at least one edge node from the plurality of edge nodes as at least one pull node, and to select at least one corresponding push node from the plurality of edge nodes for each pull node. For any target streaming node among at least one streaming node, and any target pushing node among at least one streaming node corresponding to the target streaming node, select at least one relay CDN node whose communication status with the target pushing node is communicable from the CDN nodes included in the CDN other than the target streaming node and the target pushing node. Based on the shortest pull path with multiple different hop counts from the target pull node to each of the relay CDN nodes, and the shortest pull path with 1 hop count from each of the relay CDN nodes to the target push node, determine the set of shortest pull paths from the target pull node to the target push node; From the set of shortest streaming paths, at least one shortest streaming path from the target streaming node to the target push node is selected, where the current remaining bandwidth is greater than the bandwidth threshold. This enables multiple CDN nodes to be interconnected, making the content distribution network present a mesh network structure. Content is distributed according to the shortest streaming path from each streaming node to its corresponding at least one push node. The determination of the set of shortest streaming paths from the target streaming node to the target streaming push node includes: Add the shortest pull path with 1 hop count from the target pull node to the target push node to the shortest pull path set, and set the current hop count to 2; Based on the shortest pull path from the target pull node to each of the relay CDN nodes with one less hop than the current hop count and the shortest pull path from each of the relay CDN nodes to the target push node with one hop count, determine multiple candidate shortest pull paths from the target pull node to the target push node with the current hop count, and determine the communication latency of each of the multiple candidate shortest pull paths with the current hop count. Select the candidate shortest streaming path with the minimum communication latency and the current hop count as the shortest streaming path set and add it to the shortest streaming path set. Determine whether the current hop count has reached the maximum allowed hop count. If not, increment the current hop count by 1 and return to the step of determining multiple candidate shortest pull paths from the target pull node to the target push node with the current hop count, until the current hop count reaches the maximum allowed hop count.

8. The content delivery network according to claim 7, characterized in that, When the scheduling node determines the current remaining bandwidth of each edge node in some or all of the edge nodes, it is specifically used for: For each edge node in some or all of the edge nodes, obtain the current used bandwidth of the edge node from the log server, and determine the current remaining bandwidth of the edge node based on the total available bandwidth of the edge node and the current used bandwidth of the edge node.

9. A content distribution device, characterized in that, include: The acquisition module is used to acquire network status data of the content delivery network. The network status data includes the communication status and communication latency between pairs of CDN nodes in some or all of the CDN nodes of the content delivery network, as well as the current remaining bandwidth of each CDN node in some or all of the CDN nodes. The selection module is used to select at least one CDN node from the plurality of CDN nodes included in the content distribution network as at least one pull stream node, and to select at least one corresponding push stream node from the plurality of CDN nodes included in the content distribution network for each pull stream node. The path planning module is used to select, from the CDN nodes included in the CDN other than the target streaming node and the target streaming node, at least one relay CDN node whose communication status with the target streaming node is communicable, for any target streaming node among at least one streaming node and any target streaming node among at least one streaming node corresponding to the target streaming node. Based on the shortest pull path with multiple different hop counts from the target pull node to each of the relay CDN nodes, and the shortest pull path with 1 hop count from each of the relay CDN nodes to the target push node, determine the set of shortest pull paths from the target pull node to the target push node; From the set of shortest streaming paths, at least one shortest streaming path from the target streaming node to the target push node is selected, where the current remaining bandwidth is greater than the bandwidth threshold. This enables multiple CDN nodes to be interconnected, and the content delivery network presents a mesh network structure. The content distribution module is used to distribute content according to the shortest pull path from each pull node to its corresponding at least one push node; The determination of the set of shortest streaming paths from the target streaming node to the target streaming push node includes: Add the shortest pull path with 1 hop count from the target pull node to the target push node to the shortest pull path set, and set the current hop count to 2; Based on the shortest pull path from the target pull node to each of the relay CDN nodes with one less hop than the current hop count and the shortest pull path from each of the relay CDN nodes to the target push node with one hop count, determine multiple candidate shortest pull paths from the target pull node to the target push node with the current hop count, and determine the communication latency of each of the multiple candidate shortest pull paths with the current hop count. Select the candidate shortest streaming path with the minimum communication latency and the current hop count as the shortest streaming path set and add it to the shortest streaming path set. Determine whether the current hop count has reached the maximum allowed hop count. If not, increment the current hop count by 1 and return to the step of determining multiple candidate shortest pull paths from the target pull node to the target push node with the current hop count, until the current hop count reaches the maximum allowed hop count.

10. The apparatus according to claim 9, characterized in that, The path planning module is specifically used for: For any target streaming node among at least one streaming node, and any target pushing node among at least one streaming node corresponding to the target streaming node, select at least one relay CDN node whose communication status with the target pushing node is communicable from the CDN nodes included in the CDN other than the target streaming node and the target pushing node. Based on the shortest pull path with multiple different hop counts from the target pull node to each of the relay CDN nodes, and the shortest pull path with 1 hop count from each of the relay CDN nodes to the target push node, determine the set of shortest pull paths from the target pull node to the target push node; From the set of shortest streaming paths, select at least one shortest streaming path from the target streaming node to the target push node, where the current remaining bandwidth is greater than the bandwidth threshold.

11. An electronic device, characterized in that, include: Memory and processor; The memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps of the method according to any one of claims 1-6.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 1-6.

Images