Communication methods, communication systems and computer program products

Abstract

A communication method, communication system, and computer program product are disclosed, which can at least reduce communication latency and the workload of a central server. The communication method includes: an application step, in which a first client requests a token from a central server; a generation step, in which the central server generates a token based on the first client's request; a request step, in which the central server requests a forwarding link address from a relay server; a provision step, in which the relay server provides a forwarding link address to the central server in response to the central server's request; a binding step, in which the central server binds the token; a return step, in which the central server returns the bound token to the first client; a sharing step, in which either the first client or the central server shares the token with a second client; a claim step, in which the second client requests the forwarding link address from the central server based on the token; and a data exchange step, in which the first client and the second client exchange data based on the forwarding link address.

Description

Technical Field

[0001] This invention relates to the field of data communication. Specifically, this application relates to a communication method, a communication system, and a computer program product. Background Technology

[0002] It is known that existing communication systems between terminal devices often rely on third-party servers or intermediary services for link address exchange and data transmission. In this system, terminal devices (e.g., clients) obtain communication link addresses from servers to achieve mutual communication. However, the aforementioned existing communication methods and systems have some problems.

[0003] Inefficient communication

[0004] Since terminal devices often rely on third-party servers for data forwarding and link management, this can increase communication latency and system workload.

[0005] Inflexible link selection

[0006] The existing communication systems mentioned above are usually unable to dynamically optimize the communication links based on the actual network conditions, which can easily lead to high transmission latency and poor stability.

[0007] underutilization of resources

[0008] Communication between terminal devices using the existing communication methods described above suffers from an unreasonable allocation of communication link resources. As a result, the multiple links provided by the system cannot be used flexibly, leading to a waste of link resources. Summary of the Invention

[0009] The technical problem that the invention aims to solve

[0010] This invention was developed in consideration of the above-mentioned circumstances, and its purpose is to provide a communication method that can at least reduce communication latency and the workload of the central server. Based on this, the invention further provides a communication system and a computer program product.

[0011] Technical solutions adopted to solve technical problems

[0012] One technical solution of the present invention provides a communication method, characterized in that,

[0013] The communication method is used in a communication system comprising a first client, a second client, a central server, and a relay server connected via a network, the communication method comprising:

[0014] In the application process, the first client that initiated the network service requests an application token from the central server.

[0015] In the generation step, the central server generates the token according to the request of the first client;

[0016] In the request step, the central server requests the relay server to provide a forwarding link address, which includes a forwarding link address dedicated to the first client and a forwarding link address available for use by the second client.

[0017] The provisioning step involves the relay server providing the forwarding link address to the central server in response to a request from the central server.

[0018] In the binding step, the central server binds the token together with the logical link address of the first client and the forwarding link address.

[0019] In the return step, the central server returns the completed binding token and the forwarding link address dedicated to the first client to the first client.

[0020] In the sharing step, the first client or the central server shares the token with the second client;

[0021] In the requisition step, the second client requests a forwarding link address from the central server based on the token; and

[0022] In the data exchange step, the first client and the second client exchange data based on the forwarding link address dedicated to the first client and the forwarding link address acquired by the second client.

[0023] According to the communication method described in this technical solution, an automatic exchange and binding of communication link addresses between the first client and the second client (i.e., between terminal devices) is achieved through a token mechanism, eliminating the need to rely on a traditional third-party long-connection server (i.e., a central server). This significantly improves the management efficiency of the communication link. Furthermore, since communication between the first client and the second client does not always require traversing the central server, the workload of the central server is also reduced. Moreover, because the server has already obtained the forwarding link address before the first client and the second client establish a connection or initiate communication, each client can quickly obtain the forwarding link address to establish a connection or conduct communication, reducing communication establishment delays.

[0024] Optionally, based on the communication method described in one of the above technical solutions, the number of forwarding link addresses available for the second client to claim is multiple. In the claiming step, the second client claims multiple forwarding link addresses available for its use. The communication method further includes a link selection step prior to the data exchange step. In the link selection step, based on the communication status of each forwarding link address claimed by the first client and the second client, a link corresponding to a forwarding link address that meets preset conditions is selected as the communication link between the first client and the second client.

[0025] According to the communication method described in this technical solution, by enabling each second client to send connection requests to the first client using multiple links, the communication status of each link can be obtained in real time. Therefore, the system can select the optimal link based on the actual network conditions, thereby ensuring low latency and high stability of data transmission. At the same time, it avoids wasting link resources and improves the overall communication efficiency of the system.

[0026] Optionally, based on the communication method described in one of the above technical solutions, if the first client has installed or integrated a real-time communication SDK provided by a third party that works in response to the network service, the communication method further includes a first initialization step triggered when the network service starts. In the first initialization step, the first client initializes the real-time communication SDK to obtain the third-party service link address provided by the third party. In the binding step, the central server also binds the token to the third-party service link address. In the claiming step, the second client also obtains the third-party service link address from the central server. After the claiming step, the communication method further includes: an SDK acquisition step, in which the second client obtains the real-time communication SDK based on the obtained third-party service link address; and in the real-time communication establishment step, the second client initializes the obtained real-time communication SDK to establish real-time communication with the first client.

[0027] According to the communication method described in this technical solution, the token mechanism can also transmit the information of the third-party real-time communication service triggered when the first client starts the network service to the second client. The second client can conveniently and securely obtain the specific information of the third-party real-time communication service, thereby establishing real-time communication with the first client based on the third party.

[0028] Furthermore, another technical solution of the present invention provides a communication system comprising a first client, a second client, a central server, and a relay server connected via a network. The relay server is configured to provide a forwarding link address to the central server in response to a request from the central server. The forwarding link address includes a forwarding link address dedicated to the first client and a forwarding link address available for use by the second client. The first client is configured to initiate a network service and request a token from the central server based on its own logical link address. The central server is configured to receive the request from the first client, generate the token, bind the token to the logical link address and the forwarding link address provided by the relay server, and return the token and the forwarding link address dedicated to the first client to the first client. The second client is configured to receive the token and request the central server to use the forwarding link address available for use by the second client. The first client and the second client communicate based on the forwarding link address dedicated to the first client and the forwarding link address used by the second client.

[0029] Invention Effects

[0030] The communication method and system provided by this invention can reduce communication latency and the workload of the central server. Furthermore, it allows for the selection of an optimal communication link based on actual network conditions, thereby improving communication efficiency between terminal devices. In addition, it enables the flexible use of multiple links provided by the system, thus avoiding waste of link resources. Attached Figure Description

[0031] Figure 1 This is a schematic diagram illustrating a communication system that applies a communication method according to an embodiment of this application and its variations.

[0032] Figure 2 This is a system architecture diagram of a communication system that illustrates a communication method applicable to an embodiment of this application and its variations.

[0033] Figure 3 This is a schematic diagram illustrating the application step and the return step in the communication method of one embodiment of this application.

[0034] Figure 4 This is a schematic diagram illustrating the sharing step in a communication method according to an embodiment of this application.

[0035] Figure 5 This is a schematic diagram illustrating the requisition step in a communication method according to an embodiment of this application.

[0036] Figure 6This is a schematic diagram illustrating the data exchange steps in a communication method according to an embodiment of this application.

[0037] Figure 7 This is a system architecture diagram illustrating another example of a communication system to which the communication method of an embodiment of this application and its variations is applied. Detailed Implementation

[0038] Terminology Explanation

[0039] Before describing the specific implementation methods and variations, some technical terms used in this application will be explained for ease of understanding.

[0040] In this application, "socket" refers to a concept in the computer field, particularly in the field of computer networks, which is a mechanism used by application processes to interact with the operating system in order to obtain network services.

[0041] In this application, "link" refers to a logical link. Specifically, the "link" mentioned in this application refers to a data link that controls data transmission on top of a physical link through some necessary communication protocols. In particular, in this application, "link" refers to a logical link based on the IPv4 or IPv6 protocol.

[0042] In this application, "forwarding link addresses" are virtual addresses (or logical addresses), which are pre-assigned combinations of IP addresses and port numbers, provided by different relay servers (e.g., TURN servers). In other words, the forwarding link addresses reside on the relay servers. Furthermore, in this application, these forwarding link addresses are not publicly routable link addresses.

[0043] In this application, a "token" is a data credential whose data structure is a string, and which can use different character ranges in different transmission methods. For example, a token can be a combination of readable letters and numbers, and can be transmitted via instant messaging tools or connections.

[0044] Hereinafter, with reference to the accompanying drawings, a communication method according to an embodiment of the present application and its modifications, as well as a communication system to which the communication method is applied, will be described.

[0045] Hardware configuration of a communication system

[0046] Figure 1 A schematic diagram of a communication system CS applying a communication method according to an embodiment of this application and its modifications is shown. For example... Figure 1As shown, the communication system CS mainly includes a central server S interconnected via the Internet NT, a first client A as an active terminal, multiple second clients B as online objects, a first relay server SA configured corresponding to the first client A, and multiple second relay servers SB configured corresponding to the multiple second clients B respectively. It should be noted that in this embodiment, the example is given with multiple second clients B, but it is not limited to this. The number of second clients B can also be only one. Furthermore, in... Figure 1 Although only one first client A is shown, the number of first clients A is not limited to one; there can be multiple first clients A.

[0047] The central server S is the core component of the communication system CS, responsible for coordinating the communication process of the entire communication system CS. Specifically, in this application, the central server S has functions such as token generation and management, forwarding link address acquisition and management, and link selection and optimization. These functions will be described in detail later in conjunction with a communication method of an embodiment and its variations of this application.

[0048] The first client A is the active terminal. Here, an active terminal refers to a client that can initiate connections, provide services, control and coordinate activities, and manage and allocate resources during network communication. In other words, the first client A is the party that initiates communication. Further details regarding the first client A will be provided later in the text in conjunction with the communication method flow of an embodiment of this application and its variations.

[0049] The second client B is a responding terminal. Here, a responding terminal refers to a client that receives an invitation or instruction and takes action based on this information to establish a connection with the initiating terminal. Further details regarding the second client B will be provided later in the text in conjunction with the communication method flow of an embodiment of this application and its variations.

[0050] The first relay server SA provides a dedicated forwarding link address (addrA) for the first client A (described later) to ensure that the first client A can communicate with other clients (e.g., the second client B). Furthermore, the first relay server SA can help handle network challenges such as NAT traversal and firewall issues.

[0051] The second relay server SB provides the forwarding link addresses for each of the second clients B (described later) to ensure that the second clients B can communicate with the first client A. Furthermore, similar to the first relay server SA, the second relay server SB can also help handle network challenges such as NAT traversal and firewall issues.

[0052] The communication system CS described in this application has been introduced from the perspective of hardware configuration.

[0053] System Composition of Communication Systems

[0054] On the other hand, in order to understand the communication system CS more clearly, the communication system CS will be introduced from the perspective of system composition.

[0055] Figure 2 A system architecture diagram of a communication system CS according to a communication method applicable to an embodiment of this application and its variations is shown. Figure 2 As shown, the communication system CS mainly includes a link address acquisition subsystem CS1 and a link address switching subsystem CS2. Both CS1 and CS2 are configured on the central server S. CS1 is mainly used to obtain forwarding link addresses provided by different relay servers. CS2 is mainly used to, after receiving a message containing a token from the second client B, send various information bound to the token to the second client B based on the token's information. Further details regarding CS1 and CS2 will be described in detail later in conjunction with the communication method flow of an embodiment and its variations of this application.

[0056] One implementation of the communication method

[0057] The communication system CS described in this application has been explained above from both hardware and system configuration perspectives. The following will refer to... Figures 3-6 The main flow of the communication method according to one embodiment of this application will be described.

[0058] First, the application process of the first client A starts a network service and creates a socket. Then, the first client A binds the socket with its own IP address and a specific port number to form the first client A's direct link address, addr1. That is, the direct link address addr1 includes at least the first client A's own IP address and the specific port number, allowing other devices to establish connections and communicate with the first client A through this direct link address addr1.

[0059] Specifically, when the application process of the first client A (e.g., a game) starts a network service—in other words, when the application process of the first client A needs to communicate over the network—it issues a `socket` system call, requesting the operating system to create a socket for it. The actual effect of this call is to request the operating system to allocate some system resources (e.g., memory space, CPU time, and network bandwidth) required for network communication to the application process. The operating system represents the sum of these resources using a number called a socket descriptor and returns this socket descriptor to the application process. Thereafter, all network operations performed by the application process must use this socket descriptor. When processing system calls, the operating system can identify which resources should be used to complete the service requested by the application through the socket descriptor. After communication is complete, the application notifies the operating system to reclaim all resources associated with that socket descriptor through a `close` system call.

[0060] When a new socket is created, it is not yet connected to the application process. Therefore, a binding operation is required. Specifically, after a socket is created, its port number and IP address are empty. The application process calls the `bind` instruction to specify the socket's local address (i.e., the IP address of the first client A and a specific port number), filling the created socket with the IP address and specific port number of the first client A. This forms the direct connection address `addr1` of the first client A. Here, "direct connection address `addr1` refers to the socket address composed of the IP address of the first client A and the specific port number. However, even when using the TCP protocol, for the first client A and other clients (e.g., the second client B described later), the binding instruction may not be called; instead, the operating system kernel will automatically allocate a dynamic port number (which is reclaimed by the system after communication ends). This can also form the aforementioned socket address. On the other hand, when using the TCP protocol, the first client A sets the socket to passive mode by calling the `listen` instruction, so that it can receive service requests from other clients at any time. In contrast, when using the UDP protocol, since only a connectionless service is provided, listening system calls are not used.

[0061] Similarly, the central server S also creates a socket and binds it to its IP address and a specific port number by calling a binding command. Furthermore, in the case of TCP, the central server S sets the socket to passive mode by calling the listen command, so as to receive service requests from the first client A and other clients at any time. In contrast, in the case of UDP, since only connectionless service is provided, the listen system call is not used.

[0062] After completing the above steps, proceed to step ① (corresponding to the application step).

[0063] In step ①, the first client A sends a message containing at least the direct link address addr1 and the pre-set quota m to the central server S to request a token from the central server S.

[0064] The following section will take the case using the TCP protocol as an example for a detailed explanation.

[0065] Specifically, after both the first client A and the central server S have completed the creation and binding of sockets, when using the TCP protocol, the application process of the first client A calls the establish connection or connect function to send a connection establishment request to the central server S. This triggers the TCP three-way handshake process to establish a reliable connection between the first client A and the server S.

[0066] After a reliable connection is established, the first client uses the `send` command to send a request for a token to the central server S. Specifically, the first client A sends a message containing information such as the direct link address `addr1` and the pre-defined quota `m` to the central server S, requesting a token from the central server S.

[0067] After receiving a message containing the above information, the central server S generates a token (corresponding to the generation step) and binds it to the direct link address addr1. At the same time, the central server S obtains m+1 forwarding link addresses from m+1 different relay servers through the link address acquisition subsystem SC1 (corresponding to the provision step), and also binds these forwarding link addresses to the aforementioned token (corresponding to the binding step).

[0068] Specifically, after receiving the request for a token, the central server S generates a token. Simultaneously, the link address acquisition subsystem CS1, configured on the central server S, obtains m+1 forwarding link addresses from m+1 different relay servers based on the quota m provided in the message. These m+1 forwarding link addresses include one dedicated forwarding link address (addrA) for the first client A and m forwarding link addresses for the second client B. The quota m can be set based on the number of second clients B that may communicate with the first client A, or based on other factors, or a combination of the number of second clients B and other factors.

[0069] Regarding the m+1 forwarding link addresses, specifically, these forwarding link addresses are provided by different relay servers, not by the central server S. More specifically, the "forwarding link addresses" mentioned here are a series of link addresses, including IP addresses and specific port numbers, pre-obtained by the central server S. These forwarding link addresses are virtual addresses, pre-assigned combinations of IP addresses and port numbers, and are provided by different relay servers (e.g., TURN servers). In other words, these forwarding link addresses reside on the relay servers. These forwarding link addresses are not publicly routable addresses. Specifically, the dedicated forwarding link address addrA for the first client A is provided by the first relay server SA, and the remaining m forwarding link addresses are provided by m different second relay servers SB.

[0070] Furthermore, after receiving the aforementioned information from the first client A, the central server S forwards this information to the aforementioned relay servers. Specifically, the first relay server SA associates the first client A's dedicated forwarding link address (addrA) with the first client A's direct link address and stores this association in a pre-configured forwarding table. Each second relay server SB associates its own provided forwarding link address with the first client A's dedicated forwarding link address and stores this association in a pre-configured forwarding table. Thus, when a second relay server SB receives a packet destined for the first client A's direct link address, it forwards the packet to the first relay server SA according to the mapping relationship stored in the forwarding table. Then, the first relay server SA forwards the packet to the first client A according to the mapping relationship stored in the forwarding table.

[0071] Next, in step ② (corresponding to the return step), after completing the binding of the token with the above information, server S returns the token bound with the above information and the dedicated forwarding link address addrA of first client A to first client A. First client A then claims the dedicated forwarding link address addrA.

[0072] Then, in step ③ (corresponding to the sharing step), after receiving the token returned from the central server S, the first client A shares the token with the second client B. Specific sharing methods include, but are not limited to, manual input, QR code scanning, and file transfer.

[0073] When using the manual input method, client A can display the token as text to user B on client B, or copy the token and send it to client B via email, instant messaging, or other communication channels. The manual input method is suitable for situations where users have direct communication channels, such as through chat applications or email.

[0074] When using QR code scanning, the first client A can encode the token into a QR code and display it to other users through a graphical interface. The user of the second client B can then scan, read, and parse the QR code using a QR code scanning application on their mobile device to automatically obtain the token information.

[0075] When using file transfer, client A can save the token as a file in a specific format (e.g., TXT or JSON) and send it to client B via a file transfer protocol (e.g., FTP, SFTP) or cloud storage service (e.g., Google Drive, Dropbox). File transfer is suitable for scenarios requiring secure transfer or bulk distribution of tokens.

[0076] Furthermore, after successfully obtaining the token from server S, the first client A can choose to store the token in an accessible storage location and generate a corresponding and unique connection. This accessible storage location could be, for example, cloud storage, a web server, or a dedicated API endpoint. If cloud storage is used, the first client A uploads the token to a cloud storage service (e.g., AWS S3, Azure Blob Storage) and generates a public or private access link after the upload is complete. If a web server is used, the first client A deploys the token to a web server and configures the server to return the token in response to HTTP / HTTPS requests. If a dedicated API endpoint is used, a dedicated API endpoint is set up to accept token retrieval requests from other devices and returns the token based on the verification result.

[0077] On the other hand, a unique URL is constructed based on the selected storage location, which directly points to the token's storage location. Furthermore, the URL should include necessary parameters (such as the authentication token, expiration time, etc.) to ensure security and timeliness.

[0078] After completing step ③, proceed to step ④ (corresponding to the requisition step).

[0079] In step ④, the second client B sends a message containing a token to the central server S to request the first client A's dedicated forwarding link address addrA and to request to claim at least a portion of the forwarding link addresses from the pre-generated m forwarding link addresses.

[0080] For ease of description, the following description will be based on the perspective of one of the multiple second clients B, namely second client B1. The same applies to the other second clients B that need to establish a connection and communicate with the first client A.

[0081] Specifically, after obtaining the token, the second client B1 sends a message including the obtained token to the central server S, requesting the central server S to obtain the dedicated forwarding link address addrA of the first client A bound to the token and requesting to claim at least one forwarding link address from m forwarding link addresses. The number of forwarding link addresses claimed can be one or more. It should be noted that if link selection is required, the second client B1 needs to claim at least two forwarding link addresses. Preferably, the second client B1 claims all m forwarding link addresses. Link selection will be described in detail in the variations below.

[0082] After completing step ④, proceed to step ⑤.

[0083] In step ⑤, after receiving the request message from the second client B1, the link address switching subsystem CS2 configured on the central server S parses the token and determines the specific information bound to the token. Specifically, it determines the dedicated forwarding link address addrA of the first client A and m forwarding link addresses bound to the token. After completing the parsing, it returns at least one of the dedicated forwarding link address addrA of the first client A and the m forwarding link addresses bound to the token to the second client B1. Optionally, the direct link address of the first client A may also be returned to the second client B1, depending on the specific system architecture design.

[0084] After completing step ⑤, proceed to step ⑥.

[0085] The following explanation uses the TCP protocol as an example. It's important to note that with TCP, the initial communication between client A and client B is for establishing a connection. After the connection is established, messages are transmitted between client A and client B in the same manner as the messages used to establish the connection. If UDP is used, since UDP is a connectionless protocol, the actual communication between client A and client B takes place directly in the following manner.

[0086] Furthermore, in this embodiment, it is assumed that the second client B1 has only acquired one forwarding link address.

[0087] In step ⑥, the second client B1 sends a request message containing a token to the second relay server SB that provided the forwarding link address, based on the forwarding link address it has acquired.

[0088] After completing step ⑥, proceed to step ⑦.

[0089] In step ⑦, after receiving the connection request message from the second client B1, the second relay server SB parses the token contained in the connection request message to extract the dedicated forwarding link address addrA of the first client A. Then, the second relay server SB forwards the connection request of the second client B1 to the first relay server SA according to the pre-stored forwarding table.

[0090] After completing step ⑦, proceed to step ⑧.

[0091] In step ⑧, after receiving the connection request message forwarded from the second relay server SB, the first relay server SA parses the token contained in the connection request message to extract the direct link address of the first client A. Then, according to the pre-stored forwarding table, the first relay server SA further forwards the connection request of the second client B1 to the first client A.

[0092] After completing step ⑧, proceed to step ⑨.

[0093] In step 9, the first client A sends a response message to the second client B1 via the first relay server SA and the second intermediate server SB in sequence.

[0094] After receiving the response message, the second client B1 sends an acknowledgment message to the first client A. Thus, through a three-way handshake, the connection between the first client A and the second client B1 is established.

[0095] After the connection is established, the first client A and the second client B1 communicate in the manner described in steps ⑥ to ⑨ above (corresponding to the data exchange steps).

[0096] According to the communication method described in this embodiment, the automatic exchange and binding of communication link addresses between clients is achieved through a token mechanism, eliminating the need to rely on traditional long-connection servers as in existing technologies, thus significantly improving link management efficiency. Furthermore, by pre-generating forwarding link addresses before clients establish connections or communicate with each other, each client can quickly claim these forwarding link addresses, thereby reducing communication establishment delays.

[0097] Variations in the implementation of the communication method

[0098] In the above embodiment, the example given is that the second client B1 uses only one forwarding link address. However, as mentioned above, it is preferable that the second client B1 uses two or more forwarding link addresses. In this variation, the explanation will be based on the second client B1 using two or more forwarding link addresses. The following explanation will still use the TCP protocol as an example.

[0099] The difference from the above implementation is that, in this variation, when the first client A receives a connection request from the second client B1 sent from multiple links, the first client A performs a latency test for each link to obtain the latency test result.

[0100] Specifically, since the second client B1 has acquired more than two forwarding link addresses, it can establish a connection with the first client A based on each forwarding link address. However, in actual interaction, the second client B1 can only communicate with the first client A based on one link. Generally, to improve user experience, it is desirable to reduce communication latency between clients.

[0101] Therefore, in this variant, the second client B1 sends a connection request (SYN packet) to the first client A based on each of the multiple forwarding link addresses it has acquired. Upon receiving a connection request from each link, the first client A records the timestamp of each request. Next, the first client A sends a response message (SYN+ACK packet) to the second client B1 based on each link, and records the timestamp of sending the response message. After receiving the response message from each link, the second client B1 sends an acknowledgment message (ACK packet) to the first client A based on each link. Upon receiving the acknowledgment message from each link, the first client A records the timestamp of each acknowledgment message.

[0102] Therefore, based on the timestamp of each recorded connection request or response message and the timestamp of its corresponding acknowledgment message, the first client A can calculate the round-trip time (RTT) for each link as the test result for latency testing of each link. This function can be implemented by a link communication testing system configured on the first client A. In addition to testing latency, the link communication testing system can also test the communication stability of the link.

[0103] Then, the first client A sends the test result to the central server S. Figure 7 A system configuration diagram of another example of a central server S applying the communication method of this variation is shown. For example... Figure 7 As shown, the central server S includes a link address acquisition subsystem CS1 and a link address switching subsystem CS2, as well as a link quality assessment subsystem CS3 and a link selection subsystem CS4. The link quality assessment subsystem CS3 evaluates the communication quality (e.g., communication latency, communication stability) of the communication link between two clients. The link selection subsystem CS4 selects a communication link between the first client A and the second client B1 based on the evaluation results of the link quality assessment subsystem CS3. For example, the link selection subsystem CS4 selects the link with the lowest communication latency based on the test results of the communication latency of each link. Furthermore, the link selection subsystem CS4 can also select a communication link that meets preset conditions based on recent historical data and / or operational strategies such as cost, as well as the evaluation results of the link quality assessment subsystem CS3. More specifically, the link selection subsystem CS4 selects the communication link with the lowest communication latency from multiple communication links as the official communication link between the first client A and the second client B1.

[0104] The above explanation uses the example of the second client B1 sending only one connection request to the first client A along each link, but it is not limited to this. Alternatively, the second client B1 can send multiple connection requests to the first client A along each link. The first client A records the timestamps of all connection requests and corresponding acknowledgment requests on each link. This allows for multiple latency test results on each link. In this case, the link communication side system configured on the first client A determines test data such as the minimum communication latency, maximum communication latency, average communication latency, median communication latency, and standard deviation of communication latency on each link. The link quality assessment subsystem CS3 of the central server S can evaluate the communication quality of each link based on information including this test data. Then, the link selection subsystem CS4 of the central server S selects a communication link from multiple communication links that meets preset conditions as the formal communication link between the first client A and the second client B1. As a preset condition, it includes at least one of the following: whether it is the forwarding link address with the smallest minimum communication delay time among the multiple forwarding link addresses used by the second client B1; whether it is the forwarding link address with the smallest average communication delay time among the multiple forwarding link addresses used by the second client B1; whether it is the forwarding link address with the smallest bit value of communication delay time among the multiple forwarding link addresses used by the second client B1; whether it is the forwarding link address with the smallest standard deviation of communication delay time among the multiple forwarding link addresses used by the second client B1; and whether it is the forwarding link address with the highest communication stability among the multiple forwarding link addresses used by the second client B1.

[0105] According to the communication method described in this variation, by having each second client B send connection requests to the first client A using multiple links, the communication status of each link can be obtained in real time. Therefore, the system can select a link that meets preset conditions based on the actual network situation, thereby ensuring low latency and high stability of data transmission. At the same time, it avoids wasting link resources and improves the overall communication efficiency of the system.

[0106] Additionally, it should be noted that this variation is illustrated by the example of each second client B acquiring more than two forwarding link addresses. Preferably, each second client B acquires all m forwarding link addresses. This allows for the acquisition of as much network connection information as possible, thus aiding in the selection of the optimal link.

[0107] Supplementary Explanation

[0108] Sometimes, to provide high-quality voice or video chat services, the first client A may install or integrate a third-party real-time communication software development kit (SDK, such as Agora or WebRTC). In this case, when the first client A starts the corresponding network service, the installed or integrated SDK is initialized. After the SDK initialization is complete, a unique identifier (Channel ID) for real-time communication is generated or assigned. In addition, the third-party service provider offering this SDK service will provide a third-party service link address, addr2.

[0109] When requesting a token, the first client A sends the aforementioned third-party service link address addr2, direct link address addr1, and pre-set quota m to the central server S. The central server S generates a token and binds the token to the direct link address addr1, the third-party service link address addr2, and the acquired m+1 forwarding link addresses.

[0110] Subsequently, when the second client B1 sends a request message containing the token and other information to the central server S, the central server S returns information including the third-party service link address addr2 to the second client B1. After obtaining the third-party service link address addr2, the second client B1 looks up the corresponding SDK and initializes it. Thus, real-time communication (e.g., real-time voice or video chat) is established between the first client A and the second client B1 through the third-party provided SDK.

[0111] Furthermore, it should be noted that the communication methods of the above-described embodiments and their variations in this application can also be implemented as computer software programs. For example, one embodiment and its variations in this application include a computer program product, which includes a computer program carried on a computer-readable medium of each communication subject, the computer program containing program code for executing the communication methods described in the above-described embodiments and their variations.

[0112] The foregoing description has already given many features and advantages, including various alternative implementations, as well as details of the structure and function of the apparatus and methods. This document is intended to be exemplary and is not exhaustive or limiting.

[0113] It will be apparent to those skilled in the art that various modifications can be made within the full scope indicated by the broad superordinate meaning of the terms expressed in the appended claims, particularly in terms of the hardware configuration or system configuration of the communication system, including combinations of these aspects within the scope of the principles described herein. Such various modifications are intended to be included herein, provided they do not depart from the spirit and scope of the appended claims.

Claims

1. A communication method, characterized in that, The communication method is used in a communication system comprising a first client, a second client, a central server, and a relay server connected via a network, the communication method comprising: In the application process, the first client that initiated the network service requests an application token from the central server. In the generation step, the central server generates the token according to the request of the first client; In the request step, the central server requests the relay server to provide a forwarding link address, which includes a forwarding link address dedicated to the first client and a forwarding link address available for use by the second client. The provisioning step involves the relay server providing the forwarding link address to the central server in response to a request from the central server. In the binding step, the central server binds the token together with the logical link address of the first client and the forwarding link address. In the return step, the central server returns the completed binding token and the forwarding link address dedicated to the first client to the first client. In the sharing step, the first client or the central server shares the token with the second client; In the requisition step, the second client requests a forwarding link address from the central server based on the token; and In the data exchange step, the first client and the second client exchange data based on the forwarding link address dedicated to the first client and the forwarding link address acquired by the second client. If the first client has a third-party real-time communication SDK installed or integrated that works in response to the network service. The communication method further includes a first initialization step triggered when the network service starts. In the first initialization step, the first client initializes the real-time communication SDK to obtain the third-party service link address provided by the third party. In the binding step, the central server also binds the token to the third-party service link address. In the requisition step, the second client also obtains the third-party service link address from the central server. Following the requisition step, the communication method further includes: In the SDK acquisition step, the second client obtains the real-time communication SDK based on the obtained third-party service link address; and In the real-time communication establishment step, the second client initializes the acquired real-time communication SDK to establish real-time communication with the first client.

2. The communication method as described in claim 1, characterized in that, The number of forwarding link addresses available for the second client to use is multiple. In the requisition step, the second client requisitions multiple forwarding link addresses available for its use. The communication method further includes a link selection step prior to the data exchange step. In the link selection step, based on the communication status of each forwarding link address used by the first client and the second client, a link corresponding to a forwarding link address that meets preset conditions is selected as the communication link between the first client and the second client.

3. The communication method as described in claim 2, characterized in that, The link selection step includes: The first client sends a response message to the second client based on each forwarding link address claimed by the second client, and records the time of sending the response message. The response message is a message that responds to the communication request sent from the second client. After receiving the response message, the second client sends an acknowledgment message to the first client based on each forwarding link address it has acquired; The first client receives the acknowledgment message and records the time of the acknowledgment message received based on each forwarding link address; The first client determines the latency test result of the communication link based on each forwarding link address used by the second client, based on the recorded times of the response messages sent based on each forwarding link address and the times of the acknowledgment messages sent based on each forwarding link address; and The central server selects a link corresponding to a forwarding link address that meets preset conditions based on the latency test results, and uses it as the communication link between the first client and the second client.

4. The communication method as described in claim 3, characterized in that, In the link selection step, The first client sends multiple response messages to the first client based on each forwarding link address it has acquired, and records the time of sending each response message. The first client records the time of each of the multiple acknowledgment messages corresponding to the multiple response messages received based on each forwarding link address, and As a result of the latency test, the first client determines at least one of the following in the communication link based on each forwarding link address claimed by the second client: minimum communication latency, average communication latency, median communication latency, and standard deviation of communication latency.

5. The communication method as described in claim 4, characterized in that, The preset conditions include any of the following: Is it the forwarding link address with the smallest minimum communication delay among the multiple forwarding link addresses used by the second client? Is it the forwarding link address with the smallest average communication delay among the multiple forwarding link addresses used by the second client? Is it the forwarding link address with the smallest communication delay value among the multiple forwarding link addresses used by the second client? Is it the forwarding link address with the smallest standard deviation of communication delay among the multiple forwarding link addresses used by the second client? Is it the forwarding link address with the highest communication stability among the multiple forwarding link addresses used by the second client? 6. A communication system, characterized in that, The communication system includes a first client, a second client, a central server, and a relay server connected via a network. The relay server is configured to provide a forwarding link address to the central server in response to a request from the central server. The forwarding link address includes a forwarding link address dedicated to the first client and a forwarding link address available for use by the second client. The first client is configured to initiate a network service and requests a token from the central server based on its own logical link address. The central server is configured to receive a request from the first client to generate the token, bind the token to the logical link address and the forwarding link address provided by the relay server, and return the token and the forwarding link address specific to the first client to the first client. The second client is configured to receive the token and, based on the token, request the central server to grant it a forwarding link address. The first client and the second client communicate based on the forwarding link address dedicated to the first client and the forwarding link address acquired by the second client. The first client has installed or integrated a third-party real-time communication SDK that works in response to the network service. The first client is further configured to initialize the real-time communication SDK when the network service starts, in order to obtain the link address of the third-party service provided by the third party. The central server is further configured to bind the token to the third-party service link address. The second client is further configured as follows: Obtain the third-party service link address from the central server; After obtaining the forwarding link address for the second client, the real-time communication SDK is obtained based on the obtained third-party service link address; as well as The obtained real-time communication SDK is initialized and configured to establish real-time communication with the first client.

7. A computer program product, said computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

Images