WO2023129183A1

WO2023129183A1 - System, method and computer-readable medium for streaming data accessing

Info

Publication number: WO2023129183A1
Application number: PCT/US2021/073184
Authority: WO
Inventors: Yuchuan Chang; Kun Ze Li; Che-Wei Liu
Original assignee: 17Live Japan Inc.; 17Live (Usa) Corp.
Priority date: 2021-12-30
Filing date: 2021-12-30
Publication date: 2023-07-06
Also published as: JP2024504885A; JP7466881B2

Abstract

The present disclosure relates to a system, a method and a computer-readable medium for streaming data accessing. The method includes transmitting a TCP request for streaming data, obtaining a TCP response containing an identification key, transmitting a UDP request for the streaming data to a space addressable by the identification key, and obtaining the streaming data. The present disclosure can ensure successful data accessing when mixed protocols are implemented.

Description

SYSTEM. METHOD AND COMPUTER-READABLE MEDIUM FOR STREAMING DATA ACCESSING

Field of the Invention

[0001] The present disclosure relates to data accessing on an Internet and, more particularly, to streaming data accessing on the Internet.

Description of the Prior Art

[0002] In real time data accessing on the internet, such as live streaming data accessing, latency needs to be kept as low as possible. With sub-500 milliseconds of real time latency, web real-time communication (WebRTC) is one of the fastest protocols on the market. WebRTC was essentially built with bidirectional and real-time communication. Unlike HTTP Live Streaming (HLS), which is built with Transmission Control Protocol (TCP), WebRTC is mainly based on User Datagram Protocol (UDP).

Summary of the Invention

[0003] A method according to one embodiment of the present disclosure is a method for streaming data accessing being executed by one or a plurality of computers, and includes: transmitting a TCP request for streaming data, obtaining a TCP response containing an identification key, transmitting a UDP request for the streaming data to a space addressable by the identification key, and obtaining the streaming data.

[0004] A system according to one embodiment of the present disclosure is a system for streaming data accessing that includes one or a plurality of processors, and the one or plurality of computer processors execute a machine-readable instruction to perform: transmitting a TCP request for streaming data, obtaining a TCP response containing an identification key, transmitting a UDP request for the streaming data to a space addressable by the identification key, and obtaining the streaming data.

[0005] A computer-readable medium according to one embodiment of the present disclosure is a non-transitory computer-readable medium including a program for streaming data accessing, and the program causes one or a plurality of computers to execute: transmitting a TCP request for streaming data, obtaining a TCP response containing an identification key, transmiting a UDP request for the streaming data to a space addressable by the identification key, and obtaining the streaming data.

[0006] A method according to one embodiment of the present disclosure is a method for streaming data accessing being executed by one or a plurality of computers, and includes: obtaining a TCP request for streaming data, replying a TCP response containing an identification key, obtaining, at a space addressable by the identification key, a UDP request for the streaming data, and transmiting the streaming data.

Brief description of the drawings

[0007] FIG. 1 shows an exemplary sequence chart illustrating an operation of data accessing with mixed protocols.

[0008] FIG. 2 shows an exemplary sequence chart illustrating an operation of data accessing with mixed protocols.

[0009] FIG. 3 shows an exemplary sequence chart illustrating an operation of data accessing with mixed protocols in accordance with some embodiments of the present disclosure.

[0010] FIG. 4 shows a schematic configuration of a communication system in accordance with some embodiments of the present disclosure.

Detailed Description

[0011] TCP and UDP are protocols in the transport layer used for sending bits of data, or packets, over the Internet. Both protocols use the IP protocol, which means that a packet sent by either TCP or UDP will be sent to an IP address.

[0012] TCP is a connection oriented protocol which features built-in error recovery and retransmission. However, all the back-and-forth communication reordering packets and ensuring complete delivery of the packets introduces latency.

[0013] UDP delivers a faster stream of information by eliminating error checking. Packets are sent directly to the recipient without having to properly order or retransmit them. Rather than waiting for confirmation of a successful transmission, the sender keeps transmiting packets, therefore the communication can be performed with a lower latency. It is desirable to utilize UDP in real time data accessing, such as live streaming data accessing. [0014] In some embodiments, a deployment of mixed protocols may be utilized, wherein TCP is first used to establish the connection between a client and a server, and UDP is subsequently used for data transmission.

[0015] FIG. 1 shows an exemplary sequence chart illustrating an operation of data accessing with mixed protocols. The user terminal 10 (or the client) is a device of a user, who could be a viewer or a streamer. The load balancer 50 is configured to distribute or direct a request from a user terminal to a destination, which could be a server or a space in a server on the Internet. The pod 60 is a space or a virtual machine of a server (such as a pull edge server) in a cluster, which could be a Kubemetes cluster, for example. The origin server 70 is a server configured to store data to be accessed.

[0016] In step S100, the user terminal 10 transmits a TCP request for streaming data to the load balancer 50.

[0017] In step SI 02, the load balancer 50 distributes or directs the TCP request to the pod 60.

[0018] In step S 104, the pod 60 requests the streaming data from the origin server 70 wherein the streaming data is stored.

[0019] In step S106, the origin server 70 ingests the streaming data to the pod 60.

[0020] In step SI 08, the pod 60 transmits a TCP response to the user terminal 10. The

TCP response may include a session description protocol (SDP) related to the streaming data. [0021] In step SI 10, the user terminal 10 transmits a UDP request for the streaming data to the load balancer 50.

[0022] In step S 112, the load balancer 50 distributes or directs the UDP request to the pod 60.

[0023] In step S 114, the pod 60 transmits the streaming data, which was ingested from the origin server 70, to the user terminal 10.

[0024] Note that there is only one pod (pod 60) in the deployment of FIG. 1, therefore, in step 112, the load balancer 50 can transmit the UDP request to the correct destination (which is pod 60) wherein the streaming data is ingested. However, when there are more than one pod in the deployment and a mixed-protocol (such as TCP + UDP) strategy is utilized, there would be a risk of sending the UDP request to the wrong destination by a load balancer. [0025] FIG. 2 shows another exemplary sequence chart illustrating an operation of data accessing with mixed protocols. There are two pods, pod 62 and pod 64, in the deployment of FIG. 2. [0026] In step S200, the user terminal 10 transmits a TCP request for streaming data to the load balancer 50.

[0027] In step S202, the load balancer 50 distributes or directs the TCP request to the pod 62. The distribution may be done by a criterion predetermined for the load balancer 50 to determine which pod to assign a request to.

[0028] In step S204, the pod 62 requests the streaming data from the origin server 70 wherein the streaming data is stored.

[0029] In step S206, the origin server 70 ingests the streaming data to the pod 62.

[0030] In step S208, the pod 62 transmits a TCP response to the user terminal 10. The

TCP response may include a session description protocol (SDP) related to the streaming data. [0031] In step S210, the user terminal 10 transmits a UDP request for the streaming data to the load balancer 50.

[0032] In step S212, the load balancer 50 is supposed to direct the UDP request to the pod 62 wherein the requested streaming data is ingested. However, because the load balancer 50 cannot correctly match or synchronize the former TCP request and the current UDP request, a session affinity may not be established successfully. Therefore, there is a risk of sending the UDP request to the wrong pod wherein the requested streaming data does not exist, as illustrated in FIG. 2. Therefore, the data accessing cannot be completed successfully. The failure rate may increase as more pods are implemented in the deployment. This issue of sending a UDP request to the wrong destination may happen in various cluster systems, such as a Kubemetes cluster system, when mixed protocols are incorporated. In some embodiments, the load balancer 50, the pod 62, the pod 64, and the origin server 70 are implemented in a Kubemetes cluster system.

[0033] Conventionally, there is also no way for a user terminal to directly access a pod within a cluster, because there is no information about a location or address of the pod that is known to the user terminal. Conventionally, due to concerns such as safety issues, there is no address information of a pod that is publicly known or known to an entity outside of a cluster wherein the pod resides.

[0034] FIG. 3 shows an exemplary sequence chart illustrating an operation of data accessing with mixed protocols in accordance with some embodiments of the present disclosure.

[0035] In step S300, the user terminal 10 transmits a TCP request for streaming data to the load balancer 50. [0036] In step S302, the load balancer 50 distributes or directs the TCP request to the pod 62. The distribution may be done by a criterion predetermined for the load balancer 50 to determine which pod to assign a request to. The pod 62 obtains the TCP request.

[0037] In step S304, the pod 62 requests the streaming data from the origin server 70 wherein the streaming data is stored.

[0038] In step S306, the origin server 70 ingests the streaming data to the pod 62.

[0039] In step S308, the pod 62 transmits or replys a TCP response to the user terminal 10. The user terminal 10 obtains the TCP response. The TCP response contains an identification key of the pod 62 or generated for the pod 62. The identification key is configured to let an entity outside the cluster, wherein the pod 62 resides, to access the pod 62. The pod 62 is addressable by the identification key. The identification key may include or correspond to IP information, node information, pod information or port information of the pod 62. The identification key may be included in an SDP.

[0040] In step S310, the user terminal 10 transmits a UDP request for the streaming data directly to the pod 62 by the identification key.

[0041] In step S312, the pod 62 transmits the streaming data to the user terminal 10. Therefore, the user terminal 10 obtains the streaming data successfully.

[0042] In this embodiment, an identification key is created for a pod within a cluster. The identification key is transmitted to a user terminal outside the cluster in a TCP response. Subsequently, the user terminal utilizes the identification key to bypass a load balancer and to send a UDP request directly to the correct pod to access the streaming data. The exemplary embodiment shown in FIG. 3 can effectively solve the issue of sending a UDP request to a wrong destination in a mixed-protocol deployment. In some embodiments, the identification key may be created by including a corresponding IP information, node information, pod information or port information in an Interactive Connectivity Establishment (ICE) information, such as a WebRTC ICE. The ICE information may be included in a TCP response.

[0043] Conventionally, if the accessed data is not streaming data or live video data, it may not cause an error if a TCP request and a subsequent UDP are sent to different destinations. Therefore, if the accessed data is not streaming data or live video data, there may not be a need to create an identification key for a space (such as a pod in a Kubemetes cluster) even if mixed protocols are implemented.

[0044] In some embodiments, an additional server, such as a CDN server or a catch server, may be implemented between a user terminal and a load balancer. In some embodiments, an additional server, such as a CDN server or a catch server, may be implemented between a user terminal and a pod.

[0045] In some embodiments, a user terminal can be viewed as a system comprising one or a plurality of processors, wherein the one or plurality of processors execute a machine- readable instruction to perform processes, such as the data accessing processes described above.

[0046] In some embodiments, a pod, an origin server, and/or a load balancer belong to a system providing a streaming service. In some embodiments, a pod is implemented on a streaming server. In some embodiments, an origin server serves as a streaming server. In some embodiments, the streaming service can be accessed by an application operating on a user terminal such as a smartphone or a tablet.

[0047] Referring to FIG. 3, in some embodiments, the streaming data may not be ingested from the origin server 70 to the pod 62 in step S306. Instead, the origin server 70 may first transfer metadata to the pod 62 in step S306, and later ingest the streaming data to the pod 62 after a UDP request is received at the pod 62 (for example, after step S310). [0048] FIG. 4 shows a schematic configuration of a communication system according to some embodiments of the present disclosure.

[0049] The communication system 1 may provide a live streaming service with interaction via a content. Here, the term “content” refers to a digital content that can be played on a computer device. In other words, the communication system 1 enables a user to participate in real-time interaction with other users on-line. The communication system 1 includes a plurality of user terminals 10, a backend server 30, and a streaming server 40. The user terminals 10, the backend server 30 and the streaming server 40 are connected via a network 90, which may be the Internet, for example. The backend server 30 may be a server for synchronizing interaction between the user terminals and/ or the streaming server 40. In some embodiments, the backend server 30 may be referred to as the server of an application (APP) provider. The streaming server 40 is a server for handling or providing streaming data or video data. In some embodiments, the backend server 30 and the streaming server 40 may be independent servers. In some embodiments, the backend server 30 and the streaming server 40 may be integrated into one server. In some embodiments, the user terminals 10 are client devices for the live streaming. In some embodiments, the user terminal 10 may be referred to as viewer, streamer, anchor, podcaster, audience, listener or the like. Each of the user terminal 10, the backend server 30, and the streaming server 40 is an example of an information-processing device. In some embodiments, the streaming may be live streaming or video replay. In some embodiments, the streaming may be audio streaming and/or video streaming. In some embodiments, the streaming may include contents such as online shopping, talk shows, talent shows, entertainment events, sports events, music videos, movies, comedy, concerts or the like.

[0050] The processing and procedures described in the present disclosure may be realized by software, hardware, or any combination of these in addition to what was explicitly described. For example, the processing and procedures described in the specification may be realized by implementing a logic corresponding to the processing and procedures in a medium such as an integrated circuit, a volatile memory, a non-volatile memory, a non-transitory computer-readable medium and a magnetic disk. Further, the processing and procedures described in the specification can be implemented as a computer program corresponding to the processing and procedures, and can be executed by various kinds of computers.

[0051] Furthermore, the system or method described in the above embodiments may be integrated into programs stored in a computer-readable non-transitory medium such as a solid state memory device, an optical disk storage device, or a magnetic disk storage device. Alternatively, the programs may be downloaded from a server via the Internet and be executed by processors.

[0052] Although technical content and features of the present invention are described above, a person having common knowledge in the technical field of the present invention may still make many variations and modifications without disobeying the teaching and disclosure of the present invention. Therefore, the scope of the present invention is not limited to the embodiments that are already disclosed, but includes another variation and modification that do not disobey the present invention, and is the scope covered by the patent application scope.

Description of reference numerals

1 Communication system

10 User terminal

30 Backend server

40 Streaming server

50 Load balancer

60 Pod

62 Pod

64 Pod

70 Origin server 90 Network

S100, S102, S104, S106, S108, S110, S112, SI 14 Step

S200, S202, S204, S206, S208, S210, S212 Step

S300, S302, S304, S306, S308, S310, S312 Step

Claims

We Claim:

1. A method for streaming data accessing, comprising: transmitting a TCP request for streaming data; obtaining a TCP response containing an identification key; transmitting a UDP request for the streaming data to a space addressable by the identification key; and obtaining the streaming data.

2. The method according to claim 1, wherein the TCP request is transmitted to a load balancer.

3. The method according to claim 2, further comprising directing the TCP request, by the load balancer, to the space addressable by the identification key.

4. The method according to claim 1 , wherein the UDP request is transmitted directly to the space addressable by the identification key.

5. The method according to claim 1, wherein the space corresponds to a pod in a Kubenetes cluster.

6. The method according to claim 5, further comprising creating the identification key for the space, wherein the identification key is configured to be utilized by a user terminal outside the Kubemetes cluster to access the space.

7. The method according to claim 1, wherein the identification key includes IP information, node information, pod information or port information.

8. A system for streaming data accessing, comprising one or a plurality of processors, wherein the one or plurality of processors execute a machine-readable instruction to perform: transmitting a TCP request for streaming data; obtaining a TCP response containing an identification key; transmitting a UDP request for the streaming data to a space addressable by the identification key; and obtaining the streaming data.

9

9. A non-transitory computer-readable medium including a program for streaming data accessing, wherein the program causes one or a plurality of computers to execute: transmitting a TCP request for streaming data; obtaining a TCP response containing an identification key; transmitting a UDP request for the streaming data to a space addressable by the identification key; and obtaining the streaming data.

10. A method for streaming data accessing, comprising: obtaining a TCP request for streaming data; replying a TCP response containing an identification key; obtaining, at a space addressable by the identification key, a UDP request for the streaming data; and transmitting the streaming data.

11. The method according to claim 10, further comprising creating the identification key for the space, wherein the space corresponds to a pod in a Kubenetes cluster, and the identification key is configured to be utilized by a user terminal outside the Kubemetes cluster to access the space.