Cross-platform long connection communication method and device

Abstract

This application provides a cross-platform long-connection communication method, apparatus, computer device, computer-readable storage medium, and computer program product, belonging to the field of communication technology. The cross-platform long-connection communication method is applied to a client SDK and includes: obtaining the operating system type and / or version information of the current operating environment through a cross-platform abstraction layer; selecting a target I / O multiplexing adapter from multiple I / O multiplexing adapters based on the operating system type and / or version information; loading and initializing the target I / O multiplexing adapter; creating a Socket through the initialized target I / O multiplexing adapter to initiate a connection to the node used to establish the long connection; and, if the Socket connection is successful, determining the successfully connected Socket as the target Socket for performing read / write processing. The technical solution of this application can reduce development, testing, and maintenance costs, and the connection success rate, speed, and stability performance are basically consistent across platforms.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a cross-platform long-connection communication method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Technology

[0002] In multi-terminal, multi-operating system environments, clients often establish and maintain long-lived connections with servers to achieve real-time data interaction. Related communication capabilities are typically provided as client SDKs and integrated into applications. Because different operating systems differ in their network I / O event handling mechanisms and interfaces, each platform (Windows / Linux / HarmonyOS) requires the independent development and maintenance of a long-lived connection library. This results in low code reusability, asynchronous feature iterations, increased development, testing, and maintenance costs, and inconsistent connection success rates, speeds, and stability across platforms.

[0003] It should be noted that the above content is not necessarily prior art, nor is it intended to limit the scope of patent protection of this application. Summary of the Invention

[0004] This application provides a cross-platform long-connection communication method, apparatus, computer device, computer-readable storage medium, and computer program product to solve or alleviate one or more of the technical problems mentioned above.

[0005] One aspect of this application provides a cross-platform long-connection communication method applied to a client SDK, the method comprising:

[0006] Obtain the operating system type and / or version information of the current running environment through the cross-platform abstraction layer; Based on the operating system type and / or version information, select the target I / O multiplexing adapter from multiple I / O multiplexing adapters; Load the target I / O multiplexer adapter and initialize it; A socket is created using the initial target I / O multiplexing adapter to initiate a connection to the node used to establish a long-lived connection; and If the socket connection is successful, the successfully connected socket is identified as the target socket for reading and writing operations.

[0007] Optionally, selecting the target I / O multiplexing adapter from a plurality of I / O multiplexing adapters includes: If the operating system is a Linux-like system, select an adapter based on epoll and / or poll; If the operating system is Windows, select an IOCP-based adapter; If the operating system is a BSD-like system, choose the kqueue-based adapter; When the operating system is HarmonyOS, select an adapter based on poll and / or epoll equivalent mechanisms.

[0008] Optionally, loading and initializing the target I / O multiplexing adapter includes: Initialize the event monitoring resources of the target I / O multiplexing adapter to provide unified event notification semantics.

[0009] Optionally, a socket is created through the initial target I / O multiplexing adapter, including: Get the list of nodes used to establish long connections; and Based on the node list, non-blocking Sockets are created for each node to obtain multiple Sockets; In this process, multiple Sockets initiate connections to multiple nodes in parallel.

[0010] Optionally, if the socket connection is successful, the successfully connected socket is identified as the target socket, including: If multiple sockets are successfully connected, the socket that connects first is identified as the target socket.

[0011] Optionally, it also includes: If the first socket to successfully connect is determined to be the target socket, then terminate the connection attempts of the remaining sockets among the multiple sockets.

[0012] Optionally, the multiple sockets initiating connections to the multiple nodes in parallel includes: Perform probes on multiple nodes to obtain node latency information; and A subset of priority nodes is selected based on the node latency information, and connections are initiated in parallel to the subset of priority nodes.

[0013] Optionally, the detection includes parallel ping testing of node latency.

[0014] Optionally, a socket is created through the initial target I / O multiplexing adapter, including: The multiple Sockets are created through the cross-platform abstraction layer; and Register the multiple sockets to the target I / O multiplexing adapter to monitor connection-related events.

[0015] Optionally, the method further includes: Monitor the readable events of the target Socket through the target I / O multiplexing adapter; Responding to readable events, the received data is read and output to the business layer; and The data to be sent is written to the target Socket through the Socket interface of the cross-platform abstraction layer and then sent.

[0016] Optionally, reading received data and outputting it to the business layer in response to a readable event includes: performing protocol decoding on the received data; and decompressing the decoded data using a target compression protocol before outputting it to the business layer. The process of writing and sending data to be sent to the target Socket via the Socket interface of the cross-platform abstraction layer includes: performing protocol encoding on the data to be sent; and compressing the encoded data using the target compression protocol before sending.

[0017] Optionally, it also includes: During the handshake phase of establishing a long connection, a list of supported compression algorithms is exchanged; and Select a commonly supported compression algorithm from the list of supported algorithms.

[0018] Optionally, it also includes: Heartbeats are triggered via a timer interface in the cross-platform abstraction layer; and In the event of a heartbeat timeout or an I / O error event, determine the connection failure and reacquire the node list to re-establish the long connection; The newly acquired node list is the latest node list.

[0019] Optionally, the re-establishment of the long connection includes: Based on the re-acquired list of nodes, multiple sockets are created again and connections are initiated in parallel; The socket that first successfully connected is designated as the new target socket; and Switch the business communication flow to the new target Socket.

[0020] Optionally, it also includes at least one of the following features: On the Windows platform, the asynchronous characteristics of IOCP are used to optimize data transmission and reception. On the HarmonyOS platform, power consumption for maintaining long connections is reduced by adapting the soft bus and / or low-power wake-up mechanism; and On Linux and / or HarmonyOS platforms, configure the TCP Fast Acknowledgment socket option parameters to reduce transmission latency.

[0021] Another aspect of this application provides a cross-platform long-connection communication device, the device comprising: The acquisition module is configured to obtain the operating system type and / or version information of the current runtime environment through the cross-platform abstraction layer; The selection module is configured to select a target I / O multiplexing adapter from multiple I / O multiplexing adapters based on the operating system type and / or version information; The initialization module is configured to load the target I / O multiplexer adapter and initialize it. The module is created and configured to create a Socket via the initial target I / O multiplexing adapter to initiate a connection to the node used to establish a long-lived connection; and The determination module is configured to identify the successfully connected Socket as the target Socket for performing read and write operations when the Socket connection is successful.

[0022] Another aspect of this application provides a computer device, including: At least one processor; and A memory that is communicatively connected to the at least one processor; Wherein: the memory stores instructions that can be executed by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method as described above.

[0023] Another aspect of this application provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the method described above.

[0024] Another aspect of this application provides a computer program product including a computer program that, when executed by a processor, implements the method described above.

[0025] The embodiments of this application employing the above technical solution may include the following advantages: By obtaining the operating system type and / or version information of the current operating environment through a cross-platform abstraction layer, and selecting a target I / O multiplexing adapter from multiple I / O multiplexing adapters based on the information and loading and initializing it, the subsequent creation of a Socket for establishing a long connection and the initiation of the connection can be completed under an I / O event handling mechanism that matches the operating system. Furthermore, when a Socket connection is successful, the successfully connected Socket is determined as the target Socket and used for read / write processing, thereby enabling the client SDK to complete long connection establishment and read / write processing using a consistent process on different operating system platforms. This avoids upper-layer services from adapting to different I / O mechanisms and interfaces on different operating systems, achieving unified operation and consistent communication behavior across platforms. Moreover, since the selected target I / O multiplexing adapter matches the I / O event handling mechanism of the corresponding operating system, the need for differentiated modifications to upper-layer logic in cross-platform implementation is reduced, and the stability and maintainability of long-connection communication are improved. It can be seen that this cross-platform solution has a high code reuse rate and facilitates function iteration and synchronization. It can effectively reduce development, testing and operation and maintenance costs, and the connection success rate, speed and stability of each platform are basically the same. Attached Figure Description

[0026] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0027] Figure 1 The diagram illustrates the operating environment of the cross-platform long-connection communication method according to Embodiment 1 of this application. Figure 2 A flowchart illustrating a cross-platform long-connection communication method according to Embodiment 1 of this application is shown schematically. Figure 3 Schematic illustration Figure 2 Flowchart of the sub-steps in step S206; Figure 4 Schematic illustration Figure 2 Flowchart of another sub-step in step S206; Figure 5 The diagram illustrates a new addition to the cross-platform long-connection communication method according to Embodiment 1 of this application; Figure 6 This schematically illustrates another additional flowchart of a cross-platform long-connection communication method according to Embodiment 1 of this application; Figure 7This schematically illustrates another additional flowchart of the cross-platform long-connection communication method according to Embodiment 1 of this application; Figure 8 This schematically illustrates another additional flowchart of the cross-platform long-connection communication method according to Embodiment 1 of this application; Figure 9 Schematic illustration Figure 8 Flowchart of the sub-steps in step S802; Figure 10 This diagram schematically illustrates a system architecture of a cross-platform long-connection communication method according to Embodiment 1 of this application. Figure 11 An exemplary application flowchart of a cross-platform long-connection communication method according to Embodiment 1 of this application is illustrated. Figure 12 A block diagram schematically illustrates a cross-platform long-connection communication device according to Embodiment 2 of this application; and Figure 13 A schematic diagram of the hardware architecture of a computer device according to Embodiment 3 of this application is shown. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0029] It should be noted that the descriptions involving "first," "second," etc., in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0030] It should be noted that, in any stage of this application involving the collection, storage, use, transmission, and processing of data, each stage strictly adheres to the laws, regulations, industry standards, and regulatory requirements of the data source, usage location, and relevant countries and regions to ensure the legality and compliance of data activities. In the collection stage, the purpose, method, and scope of collection are clearly communicated to the data subject in a prominent manner. Collection is conducted only after obtaining the data subject's legal authorization, ensuring that the collection process follows the "minimum necessary" principle and does not exceed the scope of data collection. In the storage stage, storage periods are limited, and data is promptly deleted or anonymized / encrypted after the storage purpose is achieved. In the usage stage, a strict data security protection mechanism is implemented, using field-level desensitization technology and processing the original data according to preset desensitization rules. For different types of data, multiple desensitization strategies, such as data generalization, data anonymization, and data encryption, are employed to effectively mitigate the risk of sensitive information leakage and ensure that all data used is securely processed and desensitized, comprehensively protecting the rights and interests of data subjects and data security. In the transmission and processing stages, the confidentiality and security of data are ensured during transmission and processing.

[0031] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order of the steps, but are only used to facilitate the description of this application and to distinguish each step, and therefore should not be construed as a limitation of this application.

[0032] First, a definition of the terminology used in this application is provided: Client SDK (Software Development Kit): refers to the communication components integrated into a client application.

[0033] Cross-platform: refers to the ability of a client SDK to be compiled, run, and maintain basic functionality on multiple operating systems (such as HarmonyOS, Windows, Linux, macOS, etc.) without modification or with only minor adaptation.

[0034] Cross-platform abstraction layer: In software architecture, it refers to encapsulating specific functions that depend on the operating system or hardware (such as I / O multiplexing, threads, and memory management) into a unified interface, thereby decoupling the upper-layer core logic from the lower-layer platform.

[0035] Operating system type and / or version information: A collection of information that characterizes the system category and version number of the current operating environment, such as Linux-like systems, Windows systems, BSD-like systems, HarmonyOS (Hongmeng operating system) and their corresponding version numbers, kernel versions, system capability identifiers, etc.

[0036] BSD-like systems (Berkeley Software Distribution): A type of operating system derived from Unix, employing a single kernel architecture and using kernel interfaces such as kqueue to handle system-level events.

[0037] I / O multiplexing (I / O multiplexing) is a mechanism that allows a single thread to monitor the input / output status of multiple file descriptors (such as network sockets). When any descriptor becomes ready, the program is notified and can process it. `poll`, `epoll`, `kqueue`, and `IOCP` are specific implementations on different platforms.

[0038] Poll: A system call interface that can receive an array of pollfd structures, each containing a specific file descriptor and the type of event to be monitored.

[0039] Epoll: An I / O multiplexing mechanism in the Linux operating system, which initializes event monitoring resources and generates epoll instance file descriptors by calling specific interfaces.

[0040] Kqueue: A kernel event notification mechanism that uses the kqueue descriptor in the kernel as an event monitoring resource, providing a unified interface to the upper layer to complete the process of registering, monitoring and obtaining events for kernel objects such as file descriptors, signals, timers or asynchronous I / O.

[0041] IOCP (I / O Completion Port): An asynchronous I / O mechanism that decouples the submission of I / O requests from the processing of results, allowing applications to create a kernel object to manage completion notifications for multiple handles.

[0042] WSAEventSelect: An API function used to associate a socket with a Win32 event object.

[0043] I / O multiplexing adapter: refers to a component that encapsulates the I / O multiplexing mechanism of a specific operating system. It is used to provide a unified "register event - wait for event - dispatch event" semantics to the upper level, and to call the corresponding operating system's epoll / poll / kqueue / IOCP and other interfaces to complete operations such as event monitoring resource initialization, event registration and event acquisition.

[0044] Event monitoring resources: I / O multiplexing adapters use underlying resource objects for waiting for and acquiring events. For example, under the epoll mechanism, this can be an epoll instance file descriptor; under the kqueue mechanism, it can be a kqueue descriptor; under the IOCP mechanism, it can be a completion port handle; and under the poll mechanism, it can be an array of polllfd structures or their equivalents.

[0045] TCP Quick Acknowledge (TCP_QUICKACK): A socket option that allows the protocol stack to immediately send back an acknowledgment response after receiving a data packet.

[0046] Node: refers to the address entity used to establish a long-term connection between communication peers.

[0047] Node list: A collection of one or more nodes used by the client SDK to initiate connections.

[0048] Socket: Refers to a network communication endpoint created according to a preset transmission protocol, used in this embodiment to establish a long-lived connection with a node. Socket can be configured in non-blocking mode to cooperate with I / O multiplexing adapters for event-driven processing.

[0049] Business layer: refers to the upper-layer application logic module that calls the client SDK. It submits data to be sent and receives the received data output by the SDK through the interface provided by the SDK.

[0050] Protocol encoding / decoding: The process of converting service layer data into network transmission format (encoding) and restoring network received format back to service layer data (decoding).

[0051] Compression protocol: An algorithm or protocol for compressing / decompressing data to be sent or received.

[0052] Heartbeat: refers to probe data or control frames that are periodically sent to maintain the survival of long-lived connections and detect connection availability.

[0053] Brotli: A general-purpose lossless data compression algorithm that uses a variant of the LZ77 algorithm, Huffman coding, and second-order context modeling.

[0054] Soft bus: refers to the distributed communication capability component provided by HarmonyOS, which can be used for scenarios such as device discovery, channel establishment and data transmission.

[0055] Low-power wake-up mechanism: a standby communication technology that keeps the link active when the device is in a sleep or low-power state through the network interface controller (NIC) and continuously matches preset specific data packet characteristics (such as Magic Packet or specific protocol header patterns).

[0056] Authentication Token: An encrypted string or credential in a specific format that contains metadata such as user identifier, issuance time, and expiration time, and is accompanied by a digital signature during transmission to verify its legitimacy.

[0057] Secondly, to facilitate understanding of the technical solutions provided in the embodiments of this application by those skilled in the art, the relevant technologies are described below: The inventors have learned that long connection technology is commonly used in mobile and desktop applications to achieve real-time communication. Most solutions are implemented for specific platforms (such as Android / iOS) or using general but inefficient network libraries, and the following common patterns exist: (1) Platform-bound SDK: A long connection library is independently developed and maintained for each target platform (Windows / Linux / HarmonyOS), resulting in low code reuse, asynchronous function iteration, and difficulty in ensuring consistency of behavior and optimal performance across platforms. (2) General but rudimentary cross-platform library: Cross-platform implementation is achieved using select or simple blocking I / O combined with multithreading. Select is inefficient when handling a large number of connections, and the multithreading model is complex and resource-intensive. (3) Fixed single-point connection strategy: Clients usually connect to a preset domain name or IP address, which is slow to switch when the network fluctuates or the server fails, resulting in a poor user experience. (4) Traditional compression method: Most still use GZIP compression, which has no advantage over newer algorithms in the mobile Internet era.

[0058] Each of the above solutions has its shortcomings, such as: (1) High platform adaptation costs and inconsistent experience: Multiple independent implementations lead to a significant increase in development, testing, and maintenance costs, and the connection success rate, speed, and stability of each platform may vary. (2) Insufficient connection efficiency and stability: There is a lack of intelligent multi-node selection and fast failover mechanisms, the connection speed is greatly affected by DNS and the status of the first node, and the recovery time after disconnection is long. (3) Inefficient use of system resources: Cross-platform solutions often adopt the lowest common denominator and poor performance I / O model (such as select), or introduce a heavy runtime environment, failing to make full use of the native high-performance network interfaces of each operating system. (4) Data transmission efficiency needs to be improved: When transmitting a large number of real-time messages (such as bullet comments and chat), traffic is wasted and latency is increased.

[0059] To address this, this application provides a high-performance, highly reliable, truly unified, and adaptive cross-platform long-connection communication technology solution. This solution achieves one-time development and consistent, efficient operation across multiple platforms: by designing a cross-platform abstraction layer, core communication logic (node ​​management, racing, compression) is separated from underlying system calls, significantly reducing development and maintenance costs while ensuring native performance on each platform. It optimizes the connection lifecycle: integrating multi-node parallel racing connection establishment with dynamic hot switching based on real-time network evaluation ensures the connection maintains the optimal path from establishment to maintenance, significantly improving connection success rate and continuous stability. It intelligently selects the optimal I / O model: the abstraction layer automatically detects and adapts to the optimal I / O multiplexing mechanism of the target platform (such as Linux poll, epoll, Windows IOCP, BSD kqueue, and HarmonyOS-like poll or epoll mechanisms), achieving network performance comparable to native development under cross-platform conditions. It improves data transmission economy, significantly reduces network traffic, saves user costs, and improves transmission efficiency in weak network conditions. Details are provided below.

[0060] Finally, for ease of understanding, an exemplary operating environment is provided below.

[0061] like Figure 1 As shown in the diagram, the operating environment includes: service platform 2, one or more clients 4, and network 6.

[0062] Service platform 2 and one or more clients 4 can be coupled through network 6 to achieve information transmission and interaction.

[0063] The following sections will elaborate on service platform 2, client 4, and network 6.

[0064] Service platform 2 may consist of multiple computing devices (nodes). These computing devices may include virtualized computing instances. Virtualized computing instances may include virtual machines, such as simulations of computer systems, operating systems, servers, etc. The computing devices may load virtual machines based on virtual images and / or other data defining specific software (e.g., operating systems, dedicated applications, servers) used for the simulation. As the demand for different types of processing services changes, different virtual machines may be loaded and / or terminated on one or more computing devices. A hypervisor may be implemented to manage the use of different virtual machines on the same computing device. Service platform 2 may run one or more services or software applications that enable the execution of the methods described in this application. Service platform 2 may also provide other services or software applications, which may include non-virtual environments and virtual environments. In some embodiments, these services may be provided as web-based services or cloud services, such as to users of client 4 under a Software as a Service (SaaS) model.

[0065] Service platform 2 may include one or more components that implement the functions performed by service platform 2. These components may include software components, hardware components, or combinations thereof that can be executed by one or more processors. In some embodiments, service platform 2 may provide... Store, read, write, query, delete Services such as providing services to clients content Services. In other embodiments, a user operating client 4 can sequentially use one or more client applications to interact with service platform 2 to utilize the services provided by these components.

[0066] Client 4 can include various types of computer devices, such as portable handheld devices, general-purpose computers (such as personal computers and laptops), workstation computers, wearable devices, smart screen devices, self-service terminal devices, service robots, gaming systems, thin clients, various messaging devices, sensors, or other electronic devices. These computer devices can run various types and versions of software applications and operating systems, such as Microsoft Windows, Apple iOS, UNIX-like operating systems, Linux or Linux-like operating systems (such as Google ChromeOS); or include various mobile operating systems, such as Microsoft Windows, Mobile OS, iOS, Windows Phone, and Android. Portable handheld devices can include cellular phones, smartphones, tablets, personal digital assistants, etc. Wearable devices can include head-mounted displays (such as smart glasses). Gaming systems can include various handheld gaming devices, internet-enabled gaming devices, etc. Client devices can execute various applications, such as various internet-related applications, communication applications (such as email applications), short message service (SMS) applications, and can use various communication protocols.

[0067] Based on the operating system described above, client 4 can also install one or more applications.

[0068] Client 4 may include an input / output interface. The input interface may include a touchpad, touchscreen, mouse, keyboard, or other sensing elements. The input interface can be configured to receive user commands that enable client 4 to perform various operations, such as... Access the specified website Output interfaces are used to output information to the user, such as displaying information.

[0069] Service platform 2 and client 4 can use network 6 as a transmission intermediary. Network 6 includes various network devices such as routers, switches, multiplexers, hubs, modems, bridges, repeaters, firewalls, proxy devices, and / or similar devices. The network can include physical links, such as coaxial cable links, twisted pair cable links, fiber optic links, and combinations thereof, or wireless links, such as cellular links, satellite links, and Wi-Fi links.

[0070] It should be noted that the above-mentioned equipment is exemplary, and the number and type of equipment can be adjusted in different scenarios or according to different needs.

[0071] The technical solution of this application will be described below using client 4 as the execution subject through multiple embodiments. It should be understood that these embodiments can be implemented in many different forms and should not be construed as being limited to the embodiments described herein.

[0072] Example 1 Figure 2 A flowchart illustrating a cross-platform long-connection communication method according to Embodiment 1 of this application is shown.

[0073] This cross-platform long-connection communication method is applied to the client SDK, such as... Figure 2 As shown, the method may include steps S200~S208, wherein: Step S200: Obtain the operating system type and / or version information of the current running environment through the cross-platform abstraction layer; Step S202: Based on the operating system type and / or version information, select a target I / O multiplexing adapter from multiple I / O multiplexing adapters; Step S204: Load the target I / O multiplexing adapter and initialize it; Step S206: Create a Socket using the initialized target I / O multiplexing adapter to initiate a connection to the node used to establish a long connection; and Step S208: If the Socket connection is successful, determine the successfully connected Socket as the target Socket for reading and writing processing.

[0074] By obtaining the operating system type and / or version information of the current runtime environment through a cross-platform abstraction layer, and selecting a target I / O multiplexing adapter from multiple I / O multiplexing adapters based on this information, and loading and initializing it, the subsequent Socket creation and connection initiation for establishing long connections can be completed under the I / O event handling mechanism that matches the operating system. Furthermore, when a Socket connection is successful, the successfully connected Socket is identified as the target Socket and used for read and write processing. This allows the client SDK to complete long connection establishment and read / write processing using a consistent process across different operating system platforms, avoiding the need for upper-layer business logic to adapt to different I / O mechanisms and interfaces on different operating systems. This achieves unified operation and consistent communication behavior across platforms. Moreover, because the selected target I / O multiplexing adapter matches the corresponding operating system's I / O event handling mechanism, it reduces the need for differentiated modifications to upper-layer logic in cross-platform implementation and improves the stability and maintainability of long-connection communication. It can be seen that this cross-platform solution results in high code reusability, facilitates feature iteration and synchronization, effectively reduces development, testing, and maintenance costs, and maintains consistent connection success rate, speed, and stability across platforms.

[0075] The following combination Figure 2 The steps in steps S200 to S208, as well as other optional steps, are described in detail.

[0076] Step S200 It obtains the operating system type and / or version information of the current running environment through the cross-platform abstraction layer.

[0077] In some embodiments, when initializing or preparing to establish a long-lived connection, the client SDK calls the system information interface of the cross-platform abstraction layer to obtain OSInfo (operating system information). OSInfo may include os_type (operating system type). In some embodiments, it may also obtain os_version (system version) or capability identifiers, etc.

[0078] If the cross-platform abstraction layer cannot obtain version information, it will only return os_type and use the default mapping strategy when selecting an adapter in the future.

[0079] Step S202 Based on the operating system type and / or version information, a target I / O multiplexing adapter is selected from multiple I / O multiplexing adapters.

[0080] Multiple I / O multiplexing adapters are pre-packaged, with at least one I / O multiplexing adapter corresponding to each type of operating system. These multiple I / O multiplexing adapters can include adapters based on epoll, poll, IOCP (I / O Completion Port), kqueue, or equivalent mechanisms.

[0081] During compilation or runtime, the cross-platform abstraction layer automatically identifies the current operating system through the system information interface and intelligently selects the most efficient I / O model (such as epoll for Linux and IOCP / WSAEventSelect for Windows).

[0082] In an optional embodiment, step S202 may include: If the operating system is a Linux-like system, select an adapter based on epoll and / or poll; If the operating system is Windows, select an IOCP-based adapter; If the operating system is a BSD-like system, choose the kqueue-based adapter; When the operating system is HarmonyOS, select an adapter based on poll and / or epoll equivalent mechanisms.

[0083] The above selection can be achieved through mapping tables or conditional branching. For example, maintaining the correspondence between operating system types and adapter sets, and outputting the target adapter identifier based on the correspondence. When multiple adapters exist under the same operating system type (e.g., "epoll and / or poll"), the specific priorities and fallback conditions can be determined according to preset rules.

[0084] In this optional embodiment, the client SDK can select an I / O multiplexing adapter that matches the underlying mechanism based on the operating system type and / or version information determined at runtime (or compile time) in a multi-operating system environment, and perform subsequent long-connection operations while maintaining consistency in the upper-layer processing flow. This reduces the development, testing, and maintenance costs associated with maintaining long-connection libraries separately on multiple platforms, and achieves consistent subsequent connection establishment and event handling across different platforms, improving system stability and maintenance efficiency. Furthermore, through this intelligent selection, network performance comparable to native development can be achieved under cross-platform conditions. In other words, by intelligently selecting different adapters, the drawbacks of being forced to use inefficient general-purpose models for cross-platform compatibility are overcome, allowing each platform (Windows, HarmonyOS, etc.) to leverage its network capabilities, achieve optimal performance, and improve connection management efficiency.

[0085] Step S204Load the target I / O multiplexer adapter and initialize it.

[0086] After selecting the target I / O multiplexing adapter, the process of loading and initializing the target I / O multiplexing adapter is executed. Loading can involve instantiating the target I / O multiplexing adapter, such as implementing it as a callable adapter instance. The adapter instance can be an adapter pre-statically linked to the client SDK, or an adapter provided as a dynamic library and loaded at runtime. The different loading methods described above correspond to the adapter implementation paths.

[0087] Furthermore, after loading is complete, the target I / O multiplexing adapter is initialized. This initialization includes at least: creating event monitoring resources for event waiting and event acquisition, and associating these resources with an instance of the target I / O multiplexing adapter for storage, so that event waiting and acquisition can be performed subsequently using a unified interface. The specific form of the event monitoring resource corresponds to the operating system platform; for example, it can be an epoll instance resource, a kqueue descriptor resource, an IOCP completion port resource, or a poll collection resource. Regardless of the underlying resource form, the target I / O multiplexing adapter shields it from the outside world and provides services to the upper layers in a unified manner, thereby reducing the awareness of differences in the underlying platform among upper-layer modules.

[0088] In an optional embodiment, step S204 may further include: initializing the event monitoring resources of the target I / O multiplexing adapter to provide unified event notification semantics. By providing unified event notification semantics (e.g., poll semantics), the upper layer can configure cross-platform logic with unified event objects and error expressions, reducing the proportion of platform branch code and lowering the development, testing, and maintenance costs associated with maintaining I / O event processing logic separately on multiple platforms.

[0089] Step S206 A socket is created through the initial target I / O multiplexing adapter to initiate a connection to the node used to establish a long connection.

[0090] The process of creating a Socket can be implemented by a unified creation interface provided by the target I / O multiplexing adapter. This interface returns a Socket handle or a Socket context object containing the handle, and puts the Socket in an initial state where it can be used to initiate a connection. All Sockets are registered with the target I / O multiplexing adapter for monitoring. Internally, the adapter can use the most efficient mechanisms of the current platform (such as epoll_wait, GetQueuedCompletionStatus) to wait for events. Further, in some embodiments, the node is input as a connection target parameter to the target I / O multiplexing adapter. The node includes address identifiers and port information. After receiving the node parameters, the target I / O multiplexing adapter calls the encapsulated connection initiation interface to initiate a connection request to the node. The return result of the connection initiation interface indicates whether the connection initiation was successful, failed, or is in a connection attempt state, and can output corresponding error reason information.

[0091] By implementing the Socket creation and connection initiation actions through the target I / O multiplexing adapter in the above manner, the connection initiation path on different operating system platforms is represented by a consistent calling format and consistent parameter organization at the upper layer, reducing the difference in code in cross-platform implementation and improving system maintainability and cross-platform consistency.

[0092] In optional embodiments, such as Figure 3 As shown, step S206, "Creating a Socket via the initialized target I / O multiplexing adapter," may include: S300, obtain the list of nodes used to establish long connections.

[0093] S302, based on the node list, create non-blocking Sockets for multiple nodes respectively, to obtain multiple Sockets. The multiple Sockets initiate connections to the multiple nodes in parallel.

[0094] The node list is used to represent multiple selectable connection target nodes, and the nodes include at least address identifiers and port information; the node list can be read by the client SDK from a preset configuration, or obtained through a configuration acquisition interface.

[0095] After obtaining the node list, the client SDK creates non-blocking sockets for multiple nodes based on the node list, resulting in multiple sockets. Specifically, the client SDK creates sockets for at least two nodes in the node list through the unified creation interface provided by the target I / O multiplexing adapter, and sets the sockets to non-blocking mode. This ensures that subsequent connection initiations will not block the current execution path for an extended period, thereby enabling connection attempts to be made to multiple nodes within the same time window.

[0096] In some embodiments, multiple sockets initiate connections to the multiple nodes in parallel. Parallel connection initiation at least means: submitting connection initiation requests to multiple nodes within the same time window, so that multiple connection attempts are in progress simultaneously. Parallel implementation can be achieved by sequentially initiating connection requests to multiple non-blocking sockets under a single thread, or by using task scheduling to submit connection requests concurrently. The client SDK can record the connection attempt status and return information of each socket during the connection initiation phase for use in subsequent processes.

[0097] Through the above implementation method, the client SDK is not limited by the reachability and network quality of a single node during the long connection establishment phase. Instead, it initiates connection attempts to multiple nodes simultaneously based on the node list, thereby reducing the impact of single point failure or node jitter on the connection establishment success rate and connection establishment time, and improving the robustness of the connection establishment phase.

[0098] In optional embodiments, such as Figure 4 As shown, step S206, "Creating a Socket via the initial target I / O multiplexing adapter," may further include: S400, creating the multiple Sockets through the cross-platform abstraction layer; and S402, the plurality of Sockets are registered to the target I / O multiplexing adapter to monitor connection-related events.

[0099] Specifically, the client SDK calls the Socket creation interface of the cross-platform abstraction layer for each of the multiple connection targets to obtain multiple Sockets. The cross-platform abstraction layer is used to shield the differences in Socket creation across different operating systems, ensuring that the creation process of multiple Sockets maintains a consistent calling format and return semantics in cross-platform scenarios. Further, after creating the multiple Sockets, they are registered with the target I / O multiplexing adapter to monitor connection-related events. Specifically, the client SDK determines the set of connection-related events to be monitored and, through the registration interface of the target I / O multiplexing adapter, associates the multiple Sockets with the set of connection-related events and registers them with the target I / O multiplexing adapter. This enables the target I / O multiplexing adapter to monitor the connection phase events of the multiple Sockets and provides a basis for subsequently outputting connection-related events with unified event notification semantics.

[0100] Through the above solution, the client SDK can create sockets in batches in a unified manner in a cross-platform environment and register them uniformly with the target I / O multiplexing adapter to monitor connection-related events. This reduces the branch implementation caused by platform differences, improves system maintainability and consistency, and makes the event entry point during the connection phase controllable and testable.

[0101] Step S208 If the socket connection is successful, the successfully connected socket is identified as the target socket for reading and writing operations.

[0102] The client SDK determines the Socket connection result generated during the connection establishment phase. When it determines that a Socket is in a successful connection state, it identifies the successfully connected Socket as the target Socket and uses the target Socket for subsequent communication.

[0103] It should be noted that there can be one or more Sockets. When multiple Sockets connect successfully, the client SDK can randomly select one Socket as the target Socket, or it can select it according to preset rules, such as the following scheme: In an optional embodiment, step S208 may include: If multiple sockets are successfully connected, the socket that connects first is identified as the target socket.

[0104] After creating non-blocking sockets for multiple nodes based on the node list and initiating connections in parallel, when a socket connection is successful, the client SDK determines the successfully connected socket as the target socket. Specifically, the client SDK judges the connection attempt results of multiple sockets, identifies the set of successfully connected sockets, and uses the sockets in this set as a candidate target socket set. Further, the client SDK can record the connection success time or the arrival order of the connection success event for the corresponding socket when a connection is successful, and when multiple successfully connected sockets exist, it compares the recorded time or order and selects the socket with the earliest connection success time or the earliest event arrival order as the target socket.

[0105] In some embodiments, when the success times of multiple successfully connected sockets cannot be distinguished, a preset secondary rule can be used to determine the target socket. This allows for a clear and consistent determination of the target socket in parallel connection scenarios.

[0106] In this optional embodiment, selecting the target Socket and establishing a connection through parallel racing can effectively improve network connection speed.

[0107] In an optional embodiment, the cross-platform long-connection communication method may further include: If the first socket to successfully connect is determined to be the target socket, then terminate the connection attempts of the remaining sockets among the multiple sockets.

[0108] After initiating connections to multiple nodes in parallel and successfully establishing connections with multiple sockets, the client SDK determines the socket that first successfully connects as the target socket. Specifically, after determining the target socket, the client SDK identifies the remaining sockets from the multiple sockets and performs a termination operation on each of these remaining sockets, preventing them from continuing connection attempts. This allows the parallel connection establishment phase to converge to a single valid connection. Further, in some embodiments, the termination operation can be implemented through a unified socket close interface, a connection cancellation request interface provided by the adapter, or by performing a termination operation on the socket. After the termination operation is completed, the client SDK can mark the remaining sockets as terminated, release related resources, and reduce network and system overhead caused by redundant connection attempts.

[0109] With the above solution, in parallel connection scenarios, once the target Socket has been determined, connection attempts of other Sockets can be terminated in a timely manner and resources can be reclaimed, thereby reducing resource waste and system overhead caused by invalid connections.

[0110] In optional embodiments, such as Figure 5 As shown, the multiple sockets initiating connections to the multiple nodes in parallel includes: The S500 performs probes on multiple nodes to obtain node latency information.

[0111] S502, a subset of priority nodes is obtained based on the node latency information, and connections are initiated in parallel to the subset of priority nodes.

[0112] The process of multiple sockets initiating connections to multiple nodes in parallel includes: performing probing on multiple nodes to obtain node latency information. Specifically, after obtaining multiple nodes for establishing long-term connections, the client SDK performs probing operations on these nodes in parallel to obtain latency information corresponding to each node. This latency information is used to characterize the link latency features between the client and the corresponding node, and is associated with the corresponding node for storage. Further, after obtaining the node latency information, the client SDK filters to obtain a subset of priority nodes based on this information. This filtering can be implemented by sorting nodes by latency and selecting nodes with lower latency as the subset of priority nodes, or by filtering nodes based on a preset latency threshold to form the subset of priority nodes. Thus, by selecting a set of nodes with better link latency from multiple nodes in such a way as described above, the proportion of invalid attempts for subsequent parallel connections is reduced, and resource overhead is controlled.

[0113] It can be seen that after obtaining the priority node subset, connections are initiated in parallel on the priority node subset. Parallel connection initiation includes: simultaneously attempting to connect to multiple nodes in the priority node subset within the same time window. This maintains the speed advantage of parallel connection establishment while reducing system resource consumption and network interaction overhead by shrinking the target set of parallel connections, reducing the impact on server ports, and improving the robustness to node quality fluctuations during the connection establishment phase.

[0114] In an optional embodiment, the probing includes parallel ping testing of node latency.

[0115] Specifically, the client SDK can construct Ping test requests for multiple nodes and initiate Ping tests to these nodes in parallel. This allows latency measurements of multiple nodes to be performed concurrently within the same time window, thereby reducing the overall time consumption of the probing phase and improving the simultaneity and comparability of latency measurement results for each node. Further, in some embodiments, after executing the Ping tests in parallel, the client SDK collects the Ping response results of each node and parses the corresponding node latency information. This node latency information is then associated with and stored with the corresponding node to form a node latency information set. The node latency information can be represented and output in a unified unit for subsequent node filtering or strategy decisions based on the node latency information.

[0116] In the above scheme, the client SDK can generate a failure flag or reason for failure for nodes that time out or fail during the Ping test. It should be noted that other network quality detection methods can also be used besides Ping testing.

[0117] By using the parallel Ping test to measure node latency, the overall time of the probing phase can be shortened when there are a large number of nodes, and the consistency of latency measurement results in the time dimension can be improved. This reduces the impact of the probing phase on the upfront overhead of the long connection establishment process and provides a more reliable basis for subsequent node selection based on node latency information.

[0118] The following describes the stages after the connection is established.

[0119] In alternative embodiments, such as Figure 6 As shown, the cross-platform long-connection communication method may further include: S600, monitor the readable events of the target Socket through the target I / O multiplexing adapter.

[0120] S602 responds to readable events by reading received data and outputting it to the business layer.

[0121] S604: Write the data to be sent into the target Socket through the Socket interface of the cross-platform abstraction layer and send it.

[0122] The target I / O multiplexing adapter is used to shield the differences in I / O event notification mechanisms between different operating systems and convert events generated at the lower level into a unified event notification semantic, thereby enabling the monitoring of readable events of the target Socket to be provided to the upper layer in a consistent manner. In step S602, in response to the readable event, the client SDK reads received data from the target Socket and outputs the received data to the business layer. The received data can be carried and output in a preset data structure, which at least includes data content; the client SDK can also output failure status and failure reason information when reading fails or an exception occurs, so that the business layer can process or record it. In step S604, the client SDK receives the data to be sent from the business layer, writes the data to be sent to the target Socket through the Socket interface of the cross-platform abstraction layer, and sends it. The cross-platform abstraction layer is used to shield the differences between different operating systems in Socket sending interfaces, error code expressions, etc., so that the sending action maintains a consistent calling form and return semantic in cross-platform scenarios. After the sending is completed, the client SDK can output the sending result status and return information related to the sending result.

[0123] Through steps S600 to S604 above, the client SDK can uniformly monitor readable events with the target I / O multiplexing adapter after the target Socket is determined, and uniformly execute the read and send interfaces with the cross-platform abstraction layer, thereby reducing the differences in cross-platform read and write processing and improving the consistency, maintainability and stability of the system.

[0124] In a further embodiment, step S602 may include: performing protocol decoding on the received data, and decompressing the decoded data using a target compression protocol before outputting it to the service layer; step S604 may include: performing protocol encoding on the data to be sent, and compressing the encoded data using a target compression protocol before sending it.

[0125] Specifically, after the client SDK reads the received data from the target Socket, it uses the received data as input for protocol decoding and parses the received data according to a preset communication protocol to obtain the decoded data unit. Subsequently, it uses the target compression protocol to decompress the compressed data payload in the decoded data unit to obtain the decompressed original data, and outputs the original data to the service layer according to a preset data structure.

[0126] After receiving the data to be sent submitted by the business layer, the client SDK encodes the data according to a preset communication protocol to obtain encoded data units. Subsequently, the client SDK compresses the encoded data units using a target compression protocol to obtain compressed data for transmission. The compressed data is then written to the target socket and sent through the Socket interface of the cross-platform abstraction layer.

[0127] By integrating protocol encoding / decoding and compression / decompression processing into the SDK's transmission and reception chain in cross-platform long-connection scenarios, as described above, message expression and data transmission formats across different platforms can be unified, reducing differences in business layer implementation. This also reduces network transmission overhead while ensuring interoperability, improving system consistency and maintainability. It should be noted that in the exemplary application, Brotli is used as the default or preferred compression codec, and its implementation is also encapsulated in the cross-platform core library. Adaptive compression negotiation is also possible; during connection establishment, the client and server exchange a list of supported compression algorithms (such as Brotli, Zstd, GZIP) and jointly select the optimal one. As follows: In optional embodiments, such as Figure 7 As shown, the cross-platform long-connection communication method may further include: In the S700, during the handshake phase of establishing a long connection, a list of supported compression algorithms is exchanged.

[0128] S702, Select a commonly supported compression algorithm from the supported list.

[0129] During the handshake phase, the client SDK generates a list of supported compression algorithms and sends this list as a field in the handshake message to the peer. Simultaneously, it receives a list of supported compression algorithms returned or sent by the peer, ensuring both parties have access to the set of compression algorithms supported by the other. Further, after obtaining the support lists from both sides, the client SDK matches its own support list with the peer's support list to obtain a set of commonly supported compression algorithms, and selects one from this set as the target compression algorithm. This target compression algorithm characterizes the compression algorithm commonly used by both parties in this long-connection session.

[0130] In some implementations, when neither party's support list contains a commonly supported compression algorithm, the client SDK can output a negotiation failure status or a negotiation result indicating that compression is not enabled, and record the result in the session context.

[0131] By negotiating and selecting the compression algorithm during the handshake phase, the communication parties can ensure consistency in the compression algorithm during subsequent data transmission and reception. This improves cross-platform interoperability and compatibility, minimizes the amount of data transmitted in messages, saves overall bandwidth costs, and enhances the user experience, especially on mobile networks.

[0132] In optional embodiments, such as Figure 8 As shown, the cross-platform long-connection communication method may further include: The S800 triggers the sending of heartbeats through the timer interface of the cross-platform abstraction layer.

[0133] S802, in the event of a heartbeat timeout or the detection of an I / O error event, determines a connection failure and reacquires the node list to re-establish the long-lived connection. The reacquired node list is the latest node list.

[0134] The client SDK can call the timer interface of the cross-platform abstraction layer to register a heartbeat timer task, causing the timer to trigger according to a preset heartbeat period. When the timer triggers, the client SDK sends a heartbeat message to periodically probe the availability of the long connection. Further, in some implementations, the client SDK determines a connection failure upon heartbeat timeout or detection of an I / O error event. Heartbeat timeout refers to the failure to meet a preset timeout threshold after sending a heartbeat; the I / O error event refers to an error event related to I / O anomalies output by the target I / O multiplexing adapter or the cross-platform abstraction layer. When either heartbeat timeout or I / O error event condition is met, the client SDK outputs a connection failure status and can output corresponding fault cause information for recording and tracing.

[0135] After a connection failure is confirmed, the client SDK retrieves the node list again to re-establish the long connection. This re-retrieved node list is the latest node list. Specifically, the client SDK calls the node list retrieval interface to retrieve the node list from the node configuration source and outputs or saves the retrieved node list as the latest node list for subsequent long connection re-establishment. In some embodiments, the client SDK can also collect node quality data such as connection time and error codes and report it to the cloud server. The scheduling center on the cloud server analyzes this data and recommends alternative nodes, then issues the most suitable preferred node list when the client triggers a reconnection. By re-retrieving the latest node list when a connection failure occurs, the risk of reconnection failure due to node topology changes or node offline is reduced, improving the stability and availability of the long connection recovery phase. The intelligent strategies of continuous connection quality evaluation in the cross-platform abstraction layer, proactively pulling new nodes and re-switching after failure, etc., are implemented on all platforms through the cross-platform abstraction layer within a unified core logic. Whether users are using HarmonyOS phones, Windows PCs, or Linux devices, they can enjoy high-quality network connections with fast connection establishment, stable maintenance, and seamless switching.

[0136] In optional embodiments, such as Figure 9 As shown, the re-establishment of the long connection includes: The S900 recreates multiple sockets and initiates connections in parallel based on the reacquired node list.

[0137] S902, determine the first successfully connected Socket as the new target Socket.

[0138] S904, switch the service communication flow to the new target Socket.

[0139] In this optional embodiment, the client SDK uses the newly acquired list of nodes as the input for connection targets. It creates sockets and initiates connections for multiple nodes in the latest node list, allowing multiple connections to attempt to proceed in parallel within the same time window, thereby reducing the dependence of the recovery phase on the reachability of a single node and network quality. Upon successful connection, the order or time of connection success for each socket is recorded. If multiple sockets have successfully connected, the socket with the earliest connection success order or the earliest time is selected as the new target socket, and this new target socket is saved in the session context as the connection bearer object after recovery. After determining the new target socket, the client SDK switches the service communication flow to the new target socket. This switching includes at least updating the connection bearer reference used for service communication from the old target socket to the new target socket, so that subsequent service communication uses the new target socket as the bearer object when sending and receiving, thereby completing the recovery switch from a failed connection to an available connection.

[0140] By using the above methods, new available connections can be quickly established based on the latest node list after a connection failure, and the business communication flow can be seamlessly migrated, improving the recovery efficiency of long connections and achieving seamless hot switching across platforms.

[0141] In an optional embodiment, the cross-platform long-connection communication method further includes at least one of the following features: On the Windows platform, the asynchronous characteristics of IOCP are used to optimize data transmission and reception. On the HarmonyOS platform, power consumption for maintaining long connections is reduced by adapting the soft bus and / or low-power wake-up mechanism; and On Linux and / or HarmonyOS platforms, configure the TCP Fast Acknowledgment socket option parameters to reduce transmission latency.

[0142] This optional embodiment can further optimize the throughput, power consumption, or latency performance of long-connection communication on different platforms.

[0143] On the Windows platform, once the client SDK determines that the running platform is Windows, it can enable an asynchronous send / receive mechanism based on IOCP to optimize the processing of large amounts of data. Specifically, the client SDK selects an IOCP-based adapter or send / receive engine, enabling socket send and receive to be executed asynchronously with submission and completion notifications. The result information in the completion notification is converted into a unified send / receive result structure or a unified event semantic output, thereby reducing thread blocking and context switching pressure in high-concurrency or large-scale data transmission scenarios, and improving transmit / receive throughput and stability.

[0144] On the HarmonyOS platform, after determining that the running platform is HarmonyOS, the client SDK can reduce the power consumption of long-term connection maintenance by adapting the soft bus and / or low-power network wake-up mechanism. Specifically, the client SDK enables the soft bus adaptation module to adapt to the cross-device connection and transmission capabilities on the HarmonyOS side, and calls the relevant interfaces of low-power network wake-up through the cross-platform abstraction layer or platform adaptation layer during the long-term connection maintenance phase, so that heartbeat triggering or necessary communication is executed on the low-power path or wake-up path allowed by the system; at the same time, the platform-side link status or wake-up result is mapped to a unified connection status output to maintain a consistent fault detection and recovery triggering standard across platforms.

[0145] On Linux and / or HarmonyOS platforms, after creating a socket or identifying a target socket, the client SDK can set socket option parameters related to TCP quick acknowledgment (TCP_QUICKACK) to reduce transmission latency. Specifically, the client SDK calls the socket option setting interface to set preset TCP quick acknowledgment parameters for the target socket and records or outputs the setting result, thereby reducing the extra waiting time for interactive data under the TCP acknowledgment mechanism, improving the timeliness of small packet interactions, and reducing end-to-end transmission latency.

[0146] By utilizing at least one of the above optional features, while maintaining consistency in the main process of cross-platform long-connection communication, it is possible to leverage the system capabilities and protocol stack options of Windows, HarmonyOS, and Linux / HarmonyOS platforms to achieve differentiated optimizations for throughput, energy consumption, and latency targets, thereby improving the cross-platform availability of long-connection communication systems.

[0147] To make this application easier to understand, the following is combined with... Figure 10 and Figure 11 An example application is provided. Wherein: 1. After a user enters the live room (LiveRoom), the client SDK initiates the connection process, initiating a connection request from the live room to the live socket manager (LiveSocketManager).

[0148] 2. The LiveSocketManager, as part of the unified core logic layer, sends a request to the BusinessServer to obtain the bullet screen configuration (getDanmuConfig).

[0149] 3. The Business Server returns a response to the Manager containing key information such as the authentication token and the hostlist of node servers.

[0150] 4. After obtaining the configuration, the LiveSocketManager instructs the SocketClient to prepare to execute the specific connection establishment action.

[0151] 5. The LiveSocketManager enables message deduplication logic for specific business identifiers (add addDuplicate(tid)), and uses mechanisms such as gift serial numbers to prepare for subsequent broadcast deduplication.

[0152] 6. The connection scheduler of the long-chain client (SocketClient) identifies the client's operating system through the cross-platform abstraction layer and initiates parallel race connections to the long-chain server (SocketServer) node.

[0153] 7. After the underlying network link is successfully established, the long-chain server (SocketServer) sends a ready status message to the long-chain client (SocketClient).

[0154] 8. The long-chain client (SocketClient) initializes the business message data to be processed (Message1).

[0155] 9. The long-chain client (SocketClient) uses the pre-acquired token to send an encrypted message (auth msg(token)) containing authentication information to the long-chain server (SocketServer).

[0156] 10. The long-chain server (SocketServer) sends the authentication result back to the client; if authentication fails, it triggers an exception handling process that re-requests the bullet screen configuration and attempts to re-establish the connection.

[0157] 11. During the connection maintenance period, the long-chain client (SocketClient) receives heartbeat data (heart msg) sent by the long-chain server (SocketServer), which integrates real-time evaluation data such as the popularity value of the live room.

[0158] 12. The long-chain client (SocketClient) continuously receives broadcast messages from the server through an established stable long chain.

[0159] 13. The long-chain client (SocketClient) returns a corresponding acknowledgment response (ack msg) to the business server (BusinessServer) for specific business instruction messages.

[0160] 14. The unified core logic layer protocol codec performs message decompression (decompressmsg) on ​​the received data packets. Here, the Brotli compression algorithm (Brotli, zlib decompress) is preferred to reduce network traffic loss.

[0161] 15. The long-chain client (SocketClient) performs a sequence number duplicate check based on the sequence number (header.sequenceId) carried in the message header.

[0162] 16. The long-chain client (SocketClient) sends an acknowledgment packet (ack) to the long-chain server (SocketServer) and can execute fast long-chain callback logic based on a specific ACK flag value (p_is_ack value).

[0163] 17. The long-chain client (SocketClient) further performs message ID-level deduplication (msgId remove duplicate) on business messages to ensure idempotency.

[0164] 18. Processed valid bullet comments or interactive data are reported as received messages (rece msg) to the Live SocketManager.

[0165] 19. The LiveSocketManager performs secondary verification of messages and performs cleanup actions to remove redundant deduplication markers (addDuplicate).

[0166] 20. The LiveSocketManager dispatches the final confirmation message (dispatchmsg) to the front-end interface of the LiveRoom for rendering.

[0167] 21. When a user exits the live stream (leave room), the closing logic is triggered.

[0168] 22. The LiveRoom notifies the SDK layer to perform a resource destruction action.

[0169] 23. The LiveSocketManager sends a formal disconnect command to the SocketClient.

[0170] 24. The long-chain client (SocketClient) releases the socket handle of the underlying system through the cross-platform abstraction layer, completely disconnecting from the long-chain server (SocketServer).

[0171] Example 2 Figure 12 The diagram schematically illustrates a cross-platform long-connection communication device according to Embodiment 2 of this application. This device can be divided into one or more program modules. One or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiments of this application. The program module referred to in the embodiments of this application refers to a series of computer program instruction segments capable of performing a specific function. The following description will specifically introduce the function of each program module in this embodiment. For example... Figure 12 As shown, the device 1000 may include: an acquisition module 1100, a selection module 1200, an initialization module 1300, a creation module 1400, and a determination module 1500, wherein: The acquisition module 1100 is configured to obtain the operating system type and / or version information of the current running environment through the cross-platform abstraction layer; Selection module 1200 is configured to select a target I / O multiplexing adapter from a plurality of I / O multiplexing adapters based on the operating system type and / or version information; Initialization module 1300 is configured to load and initialize the target I / O multiplexer adapter. Module 1400 is created and configured to create a Socket via the initial target I / O multiplexing adapter to initiate a connection to the node used to establish a long-lived connection; and The determination module 1500 is configured to identify the successfully connected socket as the target socket when the socket connection is successful, so as to perform read and write processing.

[0172] As an optional embodiment, the selection module 1200 is also configured to: If the operating system is a Linux-like system, select an adapter based on epoll and / or poll; If the operating system is Windows, select an IOCP-based adapter; If the operating system is a BSD-like system, choose the kqueue-based adapter; When the operating system is HarmonyOS, select an adapter based on poll and / or epoll equivalent mechanisms.

[0173] As an optional embodiment, the initialization module 1300 is also configured to: Initialize the event monitoring resources of the target I / O multiplexing adapter to provide unified event notification semantics.

[0174] As an optional embodiment, the creation module 1400 is also configured to: Get the list of nodes used to establish long connections; and Based on the node list, non-blocking Sockets are created for each node to obtain multiple Sockets; In this process, multiple Sockets initiate connections to multiple nodes in parallel.

[0175] As an optional embodiment, the determining module 1500 is further configured to: If multiple sockets are successfully connected, the socket that connects first is identified as the target socket.

[0176] As an optional embodiment, the device 1000 is further used for: If the first socket to successfully connect is determined to be the target socket, then terminate the connection attempts of the remaining sockets among the multiple sockets.

[0177] As an optional embodiment, the device 1000 is further used for: Perform probes on multiple nodes to obtain node latency information; and A subset of priority nodes is selected based on the node latency information, and connections are initiated in parallel to the subset of priority nodes.

[0178] As an optional embodiment, the probing includes parallel ping testing of node latency.

[0179] As an optional embodiment, the creation module 1400 is also configured to: The multiple Sockets are created through the cross-platform abstraction layer; and Register the multiple sockets to the target I / O multiplexing adapter to monitor connection-related events.

[0180] As an optional embodiment, the device 1000 is further used for: Monitor the readable events of the target Socket through the target I / O multiplexing adapter; Responding to readable events, the received data is read and output to the business layer; and The data to be sent is written to the target Socket through the Socket interface of the cross-platform abstraction layer and then sent.

[0181] As an optional embodiment, the device 1000 is further used for: The received data is decoded according to the protocol; and the decoded data is decompressed using the target compression protocol and then output to the service layer. The data to be sent is encoded using a protocol; and the encoded data is compressed using the target compression protocol before being sent.

[0182] As an optional embodiment, the device 1000 is further used for: During the handshake phase of establishing a long connection, a list of supported compression algorithms is exchanged; and Select a commonly supported compression algorithm from the list of supported algorithms.

[0183] As an optional embodiment, the device 1000 is further used for: Heartbeats are triggered via a timer interface in the cross-platform abstraction layer; and In the event of a heartbeat timeout or an I / O error event, determine the connection failure and reacquire the node list to re-establish the long connection; The newly acquired node list is the latest node list.

[0184] As an optional embodiment, the device 1000 is further used for: Based on the re-acquired list of nodes, multiple sockets are created again and connections are initiated in parallel; The socket that first successfully connected is designated as the new target socket; and Switch the business communication flow to the new target Socket.

[0185] As an optional embodiment, the device 1000 is also used for at least one of the following: On the Windows platform, the asynchronous characteristics of IOCP are used to optimize data transmission and reception. On the HarmonyOS platform, power consumption for maintaining long connections is reduced by adapting the soft bus and / or low-power wake-up mechanism; and On Linux and / or HarmonyOS platforms, configure the TCP Fast Acknowledgment socket option parameters to reduce transmission latency.

[0186] Example 3 Figure 13This illustration schematically depicts the hardware architecture of a computer device 10000 suitable for implementing a cross-platform long-connection communication method according to Embodiment 3 of this application. In some embodiments, the computer device 10000 may be a terminal device such as a smartphone, wearable device, tablet computer, personal computer, in-vehicle terminal, game console, virtual device, workbench, digital assistant, set-top box, robot, etc. In other embodiments, the computer device 10000 may be a rack server, blade server, tower server, or cabinet server (including independent servers or server clusters composed of multiple servers), etc. Figure 13 As shown, the computer device 10000 includes, but is not limited to: a memory 10010, a processor 10020, and a network interface 10030 that can communicate and be linked with each other via a system bus. Wherein: The memory 10010 includes at least one type of computer-readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 10010 may be an internal storage module of a computer device 10000, such as the hard disk or memory of the computer device 10000. In other embodiments, the memory 10010 may also be an external storage device of the computer device 10000, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 10000. Of course, the memory 10010 may also include both the internal storage module and the external storage device of the computer device 10000. In this embodiment, the memory 10010 is typically used to store the operating system and various application software installed on the computer device 10000, such as program code for cross-platform long-connection communication methods. In addition, the memory 10010 can also be used to temporarily store various types of data that have been output or will be output.

[0187] In some embodiments, processor 10020 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other chip. Processor 10020 is typically used to control the overall operation of computer device 10000, such as performing control and processing related to data interaction or communication with computer device 10000. In this embodiment, processor 10020 is used to run program code stored in memory 10010 or process data.

[0188] Network interface 10030 may include a wireless network interface or a wired network interface, which is typically used to establish a communication link between computer device 10000 and other computer devices. For example, network interface 10030 is used to connect computer device 10000 to an external terminal via a network, establishing a data transmission channel and communication link between computer device 10000 and the external terminal. The network may be an intranet, the Internet, Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, or other wireless or wired networks.

[0189] It should be pointed out that, Figure 13 Only computer devices with components 10010-10030 are shown; however, it should be understood that it is not required to implement all of the shown components, and more or fewer components may be implemented instead.

[0190] In this embodiment, the cross-platform long-connection communication method stored in memory 10010 can also be divided into one or more program modules and executed by one or more processors (such as processor 10020) to complete the embodiments of this application.

[0191] Example 4 This application also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the cross-platform long-connection communication method in the embodiments.

[0192] In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the computer-readable storage medium can be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device. Of course, the computer-readable storage medium can also include both the internal storage unit and the external storage device of the computer device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the computer device, such as the program code of the cross-platform long-connection communication method in the embodiment. In addition, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.

[0193] Example 5 This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0194] Obviously, those skilled in the art should understand that the modules or steps of the embodiments of this application described above can be implemented using general-purpose computer devices. They can be centralized on a single computer device or distributed across a network of multiple computer devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computer device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of this application are not limited to any particular combination of hardware and software.

[0195] It should be noted that the above are merely preferred embodiments of this application and do not limit the scope of patent protection of this application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

Claims

1. A cross-platform long-connection communication method, characterized in that, Applied to a client SDK, the method includes: Obtain the operating system type and / or version information of the current running environment through the cross-platform abstraction layer; Based on the operating system type and / or version information, select the target I / O multiplexing adapter from multiple I / O multiplexing adapters; Load the target I / O multiplexer adapter and initialize it; A socket is created using the initial target I / O multiplexing adapter to initiate a connection to the node used to establish a long-lived connection; and If the socket connection is successful, the successfully connected socket is identified as the target socket for reading and writing operations.

2. The method according to claim 1, characterized in that, The step of selecting a target I / O multiplexing adapter from multiple I / O multiplexing adapters includes: If the operating system is a Linux-like system, select an adapter based on epoll and / or poll; If the operating system is Windows, select an IOCP-based adapter; If the operating system is a BSD-like system, choose the kqueue-based adapter; When the operating system is HarmonyOS, select an adapter based on poll and / or epoll equivalent mechanisms.

3. The method according to claim 1, characterized in that, The loading and initialization of the target I / O multiplexing adapter includes: Initialize the event monitoring resources of the target I / O multiplexing adapter to provide unified event notification semantics.

4. The method according to claim 1, characterized in that, Creating a socket using the initial target I / O multiplexing adapter includes: Get the list of nodes used to establish long connections; and Based on the node list, non-blocking Sockets are created for each node to obtain multiple Sockets; In this process, multiple Sockets initiate connections to multiple nodes in parallel.

5. The method according to claim 4, characterized in that, If a socket connection is successful, the socket that successfully connected is identified as the target socket, including: If multiple sockets are successfully connected, the socket that connects first is identified as the target socket.

6. The method according to claim 5, characterized in that, Also includes: If the first socket to successfully connect is determined to be the target socket, then terminate the connection attempts of the remaining sockets among the multiple sockets.

7. The method according to claim 4, characterized in that, Multiple sockets initiating connections to the multiple nodes in parallel includes: Perform probes on multiple nodes to obtain node latency information; and A subset of priority nodes is selected based on the node latency information, and connections are initiated in parallel to the subset of priority nodes.

8. The method according to claim 7, characterized in that, The detection includes parallel Ping testing of node latency.

9. The method according to claim 1, characterized in that, Creating a socket using the initial target I / O multiplexing adapter includes: The multiple Sockets are created through the cross-platform abstraction layer; and Register the multiple sockets to the target I / O multiplexing adapter to monitor connection-related events.

10. The method according to claim 1, characterized in that, The method further includes: Monitor the readable events of the target Socket through the target I / O multiplexing adapter; Responding to readable events, the received data is read and output to the business layer; and The data to be sent is written to the target Socket through the Socket interface of the cross-platform abstraction layer and then sent.

11. The method according to claim 10, characterized in that, Responding to a readable event, the system reads received data and outputs it to the business layer, including: performing protocol decoding on the received data; and decompressing the decoded data using the target compression protocol before outputting it to the business layer. The process of writing and sending data to be sent to the target Socket via the Socket interface of the cross-platform abstraction layer includes: performing protocol encoding on the data to be sent; and compressing the encoded data using the target compression protocol before sending.

12. The method according to claim 11, characterized in that, Also includes: During the handshake phase of establishing a long connection, a list of supported compression algorithms is exchanged. as well as Select a commonly supported compression algorithm from the list of supported algorithms.

13. The method according to claim 1, characterized in that, Also includes: Heartbeats are triggered via the timer interface of the cross-platform abstraction layer; as well as In the event of a heartbeat timeout or an I / O error event, determine the connection failure and reacquire the node list to re-establish the long connection; The newly acquired node list is the latest node list.

14. The method according to claim 13, characterized in that, The re-establishment of the long connection includes: Based on the re-acquired list of nodes, multiple sockets are created again and connections are initiated in parallel; The socket that first successfully connected is designated as the new target socket; and Switch the business communication flow to the new target Socket.

15. The method according to any one of claims 1 to 14, characterized in that, It also includes at least one of the following features: On the Windows platform, the asynchronous characteristics of IOCP are used to optimize data transmission and reception. On the HarmonyOS platform, power consumption for maintaining long connections is reduced by adapting to the soft bus and / or low-power wake-up mechanism. as well as On Linux and / or HarmonyOS platforms, configure the TCP Fast Acknowledgment socket option parameters to reduce transmission latency.

16. A cross-platform long-connection communication device, characterized in that, The device includes: The acquisition module is configured to obtain the operating system type and / or version information of the current runtime environment through the cross-platform abstraction layer; The selection module is configured to select a target I / O multiplexing adapter from multiple I / O multiplexing adapters based on the operating system type and / or version information; The initialization module is configured to load the target I / O multiplexer adapter and initialize it. The module is created and configured to create a Socket via the initial target I / O multiplexing adapter to initiate a connection to the node used to establish a long-lived connection; and The determination module is configured to identify the successfully connected Socket as the target Socket for performing read and write operations when the Socket connection is successful.

17. A computer device, characterized in that, include: At least one processor; and A memory communicatively connected to the at least one processor; wherein: The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 15.

19. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 15.

Images