Communication system, communication method, storage medium, and computer device
By introducing a connection table, reconnection state machine, and request coordinator into the open-source HarmonyOS system, the problems of easy disconnection and message redundancy in WebSocket connections are solved, achieving stable and reliable communication in complex network environments and ensuring accurate matching of requests and responses and consistency of data logic.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- PCI TECH GRP CO LTD
- Filing Date
- 2025-12-15
- Publication Date
- 2026-05-01
AI Technical Summary
Existing native WebSocket communication solutions based on the open-source HarmonyOS system are susceptible to network fluctuations in complex network environments, leading to frequent connection drops, lack of automatic reconnection and state management, and the need for each business module to receive all push messages in global listening mode, resulting in redundant irrelevant messages and difficulty in ensuring consistency between requests and responses.
A communication system is provided, including a front-end management module and a server-side module. Multiple independent WebSocket connections are isolated through a connection table, and automatic reconnection is achieved using a reconnection state machine. A request coordinator generates a unique identifier for each request and manages the mapping relationship. The session management layer temporarily stores the response when the connection is broken and returns it when the connection is restored, ensuring the complete transmission of the response.
It achieves communication reliability and business continuity in complex network environments, avoids reconnection storms and data loss, reduces development and maintenance costs, ensures accurate matching of requests and responses and consistency of data logic, and improves the stability and reliability of WebSocket communication.
Smart Images

Figure CN121967390A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Internet communication technology, and in particular to a communication system, communication method, storage medium and computer equipment. Background Technology
[0002] WebSocket, a network protocol that supports persistent connections and full-duplex communication between clients and servers, has been widely used in real-time business scenarios. In the northbound development of the open-source HarmonyOS system, the native WebSocket communication mechanism provides developers with basic capabilities for connection establishment, message sending, and receiving. Developers can create WebSocket instances and define global listener callback functions to achieve asynchronous message interaction between clients and servers, meeting the needs of real-time data transmission.
[0003] However, existing native WebSocket communication solutions based on the open-source HarmonyOS system still have significant limitations: First, persistent connections are easily affected by network fluctuations and may be passively disconnected, lacking automatic reconnection and state management mechanisms; second, in global listening mode, each business module needs to receive all push messages, which can easily lead to redundant irrelevant messages; third, due to the asynchronous communication characteristics, the front-end cannot accurately match the corresponding response message after sending a request, resulting in chaotic data logic and making it difficult to ensure the consistency of requests and responses in real-time business. These problems severely restrict the reliability and stability of WebSocket in complex network environments and make it difficult to adapt to the distributed scenarios of the open-source HarmonyOS system. Summary of the Invention
[0004] This application mainly provides a communication system, communication method, storage medium, and computer device, aiming to solve the technical problem of poor reliability of native WebSocket communication in the northbound development of the open-source HarmonyOS system.
[0005] To solve the above technical problems, the technical solution adopted in this application is: to provide a communication system. This communication system includes a front-end management module and a server-side module; the front-end management module and the server-side module establish a connection based on the WebSocket protocol; the front-end management module is used to send requests and receive responses, and the server-side module is used to perform business processing based on the requests and return responses; the front-end management module includes: a connection table, used to isolate and manage multiple independent WebSocket connections according to the business type of the request; a reconnection state machine, used to initiate reconnection according to preset reconnection rules when a WebSocket connection is broken; and a request coordinator, used to generate a unique identifier for each request and manage the mapping relationship between the unique identifier and the request; the server-side module includes: a business processing layer, used to perform business processing based on the received requests and generate a response carrying the unique identifier corresponding to the request; and a session management layer, used to temporarily store responses when a WebSocket connection is broken and return responses when a normal connection is established.
[0006] In some embodiments, the connection table adopts a key-value pair structure, where the key of the key-value pair structure is a business type identifier, and the value of the key-value pair structure is WebSocket object information; the WebSocket object information includes at least one of the connection status, reconnection count, and connection resource locator of the corresponding WebSocket connection.
[0007] In some embodiments, the reconnection state machine includes: a reconnection processing unit, configured to initiate a reconnection of the corresponding WebSocket connection when a connection is detected to be disconnected or a reconnection command is received; a reconnection counting unit, configured to accumulate the number of reconnections when a reconnection fails, and to clear the number of reconnections when a reconnection succeeds; a delay timing unit, configured to initiate a delay timing; and an upper limit threshold unit, configured to determine whether the number of reconnections exceeds a preset upper limit threshold after the delay timing reaches a preset delay duration. If the number of reconnections exceeds the preset upper limit threshold, a reconnection failure message is reported; if the number of reconnections does not exceed the preset upper limit threshold, a reconnection command is sent to the reconnection processing unit.
[0008] In some embodiments, the request coordinator includes: an identifier generation unit for generating a unique identifier for each request; a mapping management unit for establishing and storing a mapping relationship between the unique identifier and the corresponding request; a response matching unit for matching the request corresponding to the unique identifier carried in the response when a response is received from the server module, so as to clean up the mapping relationship between the corresponding request and the corresponding unique identifier; and a timeout recycling unit for setting a timeout period for each mapping relationship, and cleaning up the corresponding mapping relationship if no corresponding response is received after the timeout period has elapsed since the request was sent.
[0009] In some embodiments, the session management layer includes: a response suspension unit, used to temporarily store a response carrying a unique identifier when the WebSocket connection is disconnected; and a response resending unit, used to resend the temporarily stored response according to the unique identifier and return a newly generated response when the WebSocket connection is normal.
[0010] In some embodiments, the communication system further includes an event distribution module and several front-end business modules. The server module is deployed on the server side, and the front-end management module, the event distribution module, and the front-end business modules are deployed on the client side. The front-end management module and the server module are also used to send topic-based messages to the event distribution module, and each of the front-end business modules is used to subscribe to the topic-based messages in the event distribution module on demand.
[0011] In some embodiments, the communication system is applied to the northbound development of the open-source HarmonyOS system; the communication system further includes a low-level callback module, which is used to: send a first callback function to the front-end management module when the WebSocket connection is normal; send a second callback function to the front-end management module when the WebSocket connection is disconnected; and send a third callback function to the front-end management module when the front-end management module receives a response.
[0012] To address the aforementioned technical problems, another technical solution adopted in this application is: providing a communication method applied to the communication system described above. This method includes: isolating and managing multiple independent WebSocket connections according to the requested service type using a connection table; initiating reconnection according to preset reconnection rules when a WebSocket connection is disconnected using a reconnection state machine; generating a unique identifier for each request and managing the mapping relationship between the unique identifier and the request using a request coordinator; performing business processing based on the received request using a business processing layer and generating a response carrying the unique identifier corresponding to the request; and temporarily storing the response when the WebSocket connection is disconnected and returning the response when a normal connection is established using a session management layer.
[0013] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a storage medium storing program data, characterized in that the program data, when executed by a processor, implements the steps of the communication method described above.
[0014] To solve the above-mentioned technical problems, another technical solution adopted in this application is to provide a computer device, which includes a processor and a memory connected to each other, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the steps of the communication method described above.
[0015] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses a communication system, communication method, storage medium, and computer equipment. Based on the front-end management module 110 and the server module that establish connections using the WebSocket protocol, this application specifically isolates independent WebSocket connections for multiple services through a connection table, avoiding message interference and fault propagation between services; it achieves automatic reconnection and state management through a reconnection state machine, effectively addressing connection interruption issues caused by network fluctuations, avoiding reconnection storms, and ensuring stable and controllable connection recovery; it assigns a unique identifier to each request and establishes a mapping relationship through a request coordinator, ensuring accurate matching of response messages and consistency of data processing logic; and it temporarily stores response data during disconnection through the session management layer, ensuring complete transmission of responses carrying unique identifiers after connection recovery, ensuring no request loss and traceable responses, thereby improving the communication reliability and business continuity of the system in complex network environments. This solution implements business processing logic such as self-healing after disconnection, strong request-response correlation, and idempotent resending after network outage. It can significantly improve the stability and reliability of WebSocket communication, reduce the maintenance cost and resource consumption of operating system application development, avoid the risk of business interruption and data loss due to connection abnormalities, ensure the smooth execution of business processes and efficient utilization of system resources, and help to facilitate the rapid deployment of highly reliable real-time services in operating system application development. It also reduces the maintenance cost and technical threshold for developers at the communication layer, and promotes the widespread adoption and stable operation of real-time interactive applications in the corresponding operating system ecosystem. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a schematic diagram of the structure of an embodiment of the communication system provided in this application; Figure 2 yes Figure 1 A schematic diagram of an embodiment of the preset reconnection rules for the reconnection state machine; Figure 3 yes Figure 1 A schematic diagram of the structure of a specific embodiment of the communication system; Figure 4 yes Figure 1 A schematic diagram of the communication processing logic of the communication system in this embodiment; Figure 5 This is a schematic diagram of the structure of an embodiment of the communication method provided in this application; Figure 6 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application; Figure 7 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application. Detailed Implementation
[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0018] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.
[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.
[0020] This application provides a communication system, see reference. Figure 1 , Figure 1This is a schematic diagram of a communication system 100 provided in this application. The communication system 100 includes: a front-end management module 110 and a server module 120; the front-end management module 110 and the server module 120 establish a connection based on the WebSocket protocol; the front-end management module 110 is used to send requests and receive responses, and the server module 120 is used to perform business processing based on the requests and return responses; the front-end management module 110 includes: a connection table 111, used to isolate and manage multiple independent WebSocket connections according to the business type of the request; a reconnection state machine 112, used to initiate reconnection according to preset reconnection rules when the WebSocket connection is disconnected; and a request coordinator 113, used to generate a unique identifier for each request and manage the mapping relationship between the unique identifier and the request; the server module 120 includes: a business processing layer 121, used to perform business processing based on the received requests and generate a response carrying the unique identifier corresponding to the request; and a session management layer 122, used to temporarily store responses when the WebSocket connection is disconnected and return responses when the connection is normal.
[0021] This embodiment specifies two main modules of the communication system 100: the front-end management module 110 (WebSocketManager) and the server module 120. The front-end management module 110 is the core component on the client side responsible for establishing WebSocket connections, sending requests, and receiving responses, managing the communication link and handling message exchange between the client and server. The server module 120 is the core component on the server side responsible for receiving front-end requests, executing business logic, and returning response results; it is the core carrier for business processing and response generation. The two modules establish a bidirectional communication link based on the WebSocket protocol, leveraging the WebSocket protocol's support for persistent connections, full-duplex real-time communication, and low-latency data transmission to provide a stable and efficient transmission channel for request-response interactions between the client and server.
[0022] In this embodiment, the front-end management module 110 and the server module 120 engage in request-response interaction. A request is a business data request initiated by the front-end business module, containing the business type, operation instructions, and related parameters, which is used to trigger specific business processing logic on the server side. A response is feedback data returned by the server after processing the front-end request, containing the processing status, business result, and related additional information, which is used to inform the front-end of the processing status of the request. The interaction logic between the two follows a request-triggered-response pattern: the front-end management module 110 sends a request to the server module 120, the server module 120 receives the request, processes the business data, and returns a response to the front-end management module 110, forming a complete request-response closed loop. The front-end management module 110 establishes a WebSocket connection with the server, generates requests according to business needs, sends them to the server, receives responses from the server, and passes them to the corresponding front-end business modules. The server module 120 receives the requests sent by the front-end management module 110, extracts the business information from the requests, executes the corresponding business processing logic, generates a response result, and returns it to the front-end management module 110. Through the coordination of the basic request-response interaction between the client and the server, business data can be accurately and timely transmitted between the client and the server, improving the stability and reliability of the communication link. This basic interaction mechanism is also a prerequisite for the subsequent implementation of advanced communication capabilities such as reconnection after disconnection, strong association between request and response, and resending after network outage, providing core support for building a highly reliable WebSocket communication system.
[0023] In this embodiment, the front-end management module 110 specifically includes a connection table 111, a reconnection state machine 112, and a request coordinator 113. The connection table 111 is a core component used to isolate and manage multiple independent WebSocket connections according to business type. Business types include, but are not limited to, specific business domains such as ticketing and operations. Based on this business type and utilizing the data packet structure of the WebSocket protocol, it can effectively isolate WebSocket connection instances corresponding to different business types, achieving physical message isolation for different business types, facilitating system expansion and fault domain isolation. The connection table 111 can be implemented using the business type-connection key-value pair management method described later, or it can be constructed using hash table mapping or object array indexing to achieve independent management of multiple business connections, avoiding message interference and fault propagation between businesses.
[0024] In this embodiment, the reconnection state machine 112 is a core component used to handle the automatic reconnection logic after the WebSocket connection is disconnected, ensuring the controllability of connection recovery. Its preset reconnection rules can be a combination of state counting + delay triggering + threshold judgment logic, which will be introduced later, or a reconnection strategy implemented by means of finite state machine model, machine learning model driving, etc., to restrict reconnection attempts. While making up for the lack of recovery mechanism in traditional methods, it avoids the reconnection storm caused by blind reconnection, ensures the stability and controllability of connection recovery, and improves the system's ability to cope with network fluctuations.
[0025] In this embodiment, the request coordinator 113 is a core component used to strongly associate requests and responses through a unique identifier (Correlation IdentityDocument, cid), managing the request lifecycle and resource reclamation. Specifically, it can be implemented through a combination of unique identifier generation, mapping storage, and timeout reclamation logic, as described later, or through a request-result waiting object association mechanism, callback queue management, etc., to ensure accurate matching of requests and responses, avoid data corruption, and improve resource utilization. Through this front-end management module 110, multi-service connection isolation, automatic reconnection, and accurate request-response matching can be achieved, significantly improving the communication reliability and business continuity of clients in complex network environments.
[0026] In this embodiment, the server module 120 includes a business processing layer 121 and a session management layer 122. The business processing layer 121 is the core component for executing business logic processing based on received requests and generating responses carrying unique identifiers for the corresponding requests. Specifically, it performs business processing and response generation by parsing request parameters, executing business logic rules, and generating response data carrying unique identifiers for the requests, ensuring the correct association between response data and requests and providing a foundation for a closed-loop request-response mechanism. The session management layer 122 is the core component for temporarily storing unreachable responses when the WebSocket connection is broken and resending responses according to the unique identifier of the request after the connection is restored. Specifically, it can be implemented through unreachable response temporary storage caching + reconnection resending logic + request unique identifier matching mechanism (described later), or through persistent database storage, message queue buffering, etc., ensuring that response data is not lost during network outages and that responses are reachable after reconnection. Through this server module 120, accurate association of business processing and temporary storage and resending of network outage responses can be achieved, significantly improving communication reliability and ensuring the continuity of business and data integrity of the server in complex network environments.
[0027] In this embodiment, through the collaborative interaction of the aforementioned front-end management module 110 and server module 120, a strong association between requests and responses can be achieved by carrying a unique identifier in the request and returning the same identifier in the response. Automatic reconnection is initiated through the reconnection state machine 112 to achieve self-healing after disconnection. The session management layer 122 temporarily stores and resends responses to ensure no request is lost during network outages. The connection table 111 isolates multiple service connections to achieve independent management of multiple channels. In communication processes within complex network environments, this collaborative mechanism effectively avoids technical problems such as reconnection storms, data crosstalk, memory leaks, and service interruptions, ensuring stable communication links, consistent data logic, and business continuity. It achieves stable, efficient, and reliable WebSocket communication, providing solid technical support for highly reliable real-time services in operating system application development. This reduces the technical implementation difficulty and maintenance costs for developers at the communication layer, and is conducive to promoting the widespread adoption and stable operation of real-time interactive applications in complex network environments.
[0028] Optionally, in some embodiments, the connection table 111 adopts a key-value pair structure, where the key of the key-value pair structure is a business type identifier, and the value of the key-value pair structure is WebSocket object information; the WebSocket object information includes at least one of the connection status, reconnection count, and connection resource locator of the corresponding WebSocket connection.
[0029] In this optional embodiment, a key-value mapping management method is specifically adopted, using the business type identifier as the key and WebSocket connection status information as the value. This method accurately divides WebSocket connection instances of different business types, isolating multiple business connections that might otherwise interfere with each other in the business processing logic. This overcomes the shortcomings of the native WebSocket global single connection mode in traditional solutions, similar to the open-source HarmonyOS operating system, and avoids message interference and fault propagation between businesses. The business type identifier is a unique identifier that distinguishes different business scenarios such as ticketing and operations, used to completely independent the communication links of each business. For example, ticketing corresponds to type A identifier, while operations corresponds to type B identifier, enabling physical isolation of messages from different business types and preventing message interference between businesses. The WebSocket object information is a carrier that encapsulates the operating parameters of a single connection, used for real-time management of the connection status. Specifically, it includes the connection status of the corresponding WebSocket connection (e.g., connected, disconnected and awaiting reconnection, reconnecting), the number of reconnection attempts for the corresponding WebSocket connection (e.g., the current number of reconnection attempts is 3), and the connection resource location identifier for the corresponding WebSocket connection (e.g., through a URL, i.e., a Uniform Resource Locator, to determine the server address of the WebSocket connection).
[0030] In this optional embodiment, for example, the key-value pair structure may specifically be a Map.<WebSocketType,WebSocketConnection> The structure consists of a Map, a key-value pair mapping container that supports efficient querying, adding, and deleting connection information; WebSocketType, an enumeration type identifying the business type; and WebSocketConnection, a state encapsulation object for a single connection, i.e., the WebSocket object information. Compared to the redundancy and interference caused by the native WebSocket's global listening to all messages, this structure enables clients and servers to perform targeted, related, and collaborative business processing, avoiding redundant data processing unrelated to the business and improving the accuracy and efficiency of business processing. Furthermore, adding new business types only requires adding the corresponding key-value pairs for rapid expansion, without modifying existing logic, effectively reducing business expansion and maintenance costs. This connection table 111 solution based on a key-value pair structure improves message processing accuracy and system stability, reduces maintenance costs in multi-business scenarios, and provides reliable support for real-time services in complex network environments.
[0031] Optionally, in some embodiments, the reconnection state machine 112 includes: a reconnection processing unit, used to initiate a reconnection of the corresponding WebSocket connection when a connection is detected to be disconnected or a reconnection command is received; a reconnection counting unit, used to accumulate the number of reconnections when a reconnection fails, and to clear the number of reconnections when a reconnection succeeds; a delay timing unit, used to initiate a delay timing; and an upper limit threshold unit, used to determine whether the number of reconnections exceeds a preset upper limit threshold after the delay timing reaches a preset delay duration. If the number of reconnections exceeds the preset upper limit threshold, a reconnection failure message is reported; if the number of reconnections does not exceed the preset upper limit threshold, a reconnection command is sent to the reconnection processing unit.
[0032] In this optional embodiment, the reconnection state machine 112 specifically implements the core functions of self-healing from disconnection and avoiding reconnection storms through a combination of reconnection counting, delayed reconnection, and upper limit control logic. The reconnection processing unit is the core execution unit responsible for performing disconnection reconnection operations. Specifically, it can drive the WebSocket connection instance to reconnect through system-level timers, event loop mechanisms, or asynchronous task scheduling. This reconnection operation is automatically triggered when a connection is detected as broken or a reconnection command is received. Connection break detection can be implemented based on a function callback mechanism, such as detecting or receiving the Close callback function provided by the open-source HarmonyOS WebSocket underlying library to perceive changes in connection status in real time and trigger the reconnection process. Alternatively, it can be achieved through a timed heartbeat detection mechanism or a network status monitoring interface for proactive detection. The reconnection command is a control signal generated by the internal logic of the reconnection state machine 112 to trigger the next reconnection attempt. In this embodiment, the reconnection command can be issued by the delayed timing unit after completing the delayed timing and the upper limit threshold unit determining that the number of reconnections has not exceeded the limit, thereby controlling the reconnection rhythm and avoiding a reconnection storm caused by a large number of invalid reconnections in a short period.
[0033] In this optional embodiment, the control of reconnection is specifically implemented based on the collaborative processing logic of the reconnection counter unit's accumulation / resetting logic, the delay timing unit's delay timing logic, and the upper limit threshold unit's reconnection count limitation logic. For example, see [reference needed]. Figure 2The processing logic is as follows: When a connection is detected to be broken, it indicates that a connection closure (Close) or connection error (Error) has occurred. At this time, a reconnection (StartReconnect) can be initiated through the reconnection processing unit. If the reconnection is successful, message distribution can be performed in the reconnection state. At the same time, the underlying callback mechanism of the operating system can trigger a callback function indicating a successful connection, such as the Open callback function provided by the WebSocket underlying library of the open-source HarmonyOS system, so that the reconnection counter unit can clear the reconnection count and reset the state. If the reconnection fails, the reconnection count unit will accumulate the reconnection count, and a preset duration delay timer will be initiated through the delay timer unit, and the reconnection limit will be judged through the upper limit threshold unit (Oversize). If the reconnection limit is exceeded, it means that the current network environment or server status cannot support connection recovery. At this time, the connection failure status will be reported to the connection table 111 of the front-end management module 110 or the application layer business module, etc., for subsequent error handling or user prompts. If the reconnection limit is not exceeded, a reconnection will be attempted again, and a reconnection command will be sent to the reconnection processing unit so that the reconnection processing unit can initiate the next reconnection attempt. Through the collaborative logic of the reconnection state machine 112, the reconnection operation is initiated only when the connection is broken and the reconnection limit has not been reached. This avoids the reconnection storm caused by blind reconnection, ensures that the connection recovery process is stable and controllable, effectively improves the system's ability to cope with network fluctuations, reduces ineffective resource consumption, and ensures business continuity.
[0034] Optionally, in some embodiments, the request coordinator 113 includes: an identifier generation unit for generating a unique identifier for each request; a mapping management unit for establishing and storing the mapping relationship between the unique identifier and the corresponding request; a response matching unit for matching the request corresponding to the unique identifier carried in the response when a response is received from the server module 120, so as to clean up the mapping relationship between the corresponding request and the corresponding unique identifier; and a timeout recycling unit for setting a timeout period for each mapping relationship, and cleaning up the corresponding mapping relationship when no corresponding response is received after the timeout period has expired after the request is sent.
[0035] In this optional embodiment, the request coordinator 113 specifically implements the core functions of strong request-response correlation and efficient resource management through a combination of unique identifier generation, mapping storage, and timeout recycling logic. The identifier generation unit is the core generation component used to generate a random unique identifier for each frontend request. Specifically, it can generate the identifier using random string generation algorithms, pipeline code generation rules, or a combination of timestamps and random numbers, and send the identifier along with the request data to the server. The mapping management unit is the core storage component used to establish and maintain the mapping relationship between unique identifiers and request / response. It can implement CRUD operations on this mapping relationship through data structures such as hash tables, databases, or memory caches, allowing for querying the mapping relationship using the unique identifier and performing response matching and callback triggering. Subsequent responses automatically execute callbacks and remove the mapping upon successful matching, and automatically clean up the mapping when there is no response after timeout, thus achieving control over the request lifecycle. The response matching unit is the core matching component for achieving precise association between requests and responses. Upon receiving a response message from the server, it parses the unique identifier carried in the response and matches the corresponding mapping relationship. This triggers the corresponding request callback to return the response result. Simultaneously, it can clean up the corresponding mapping relationship after triggering the callback to release memory resources and avoid data redundancy. The timeout recycling unit is the core recycling component for preventing resource leaks and business logic freezes. The specific timeout period can be set according to business scenario requirements, network latency characteristics, and server processing capabilities to balance request reliability and resource utilization. Within the timeout period, it can wait for the server response to ensure that requests are not lost. However, if the preset timeout period expires and no corresponding response is received, it usually indicates that the request has expired or the server is unable to respond. Therefore, it can proactively clean up the corresponding mapping relationship to release memory resources and achieve efficient resource recycling.
[0036] In this optional embodiment, for example, the request coordinator 113 may be specifically based on the generateCorrelationId() function and pendingRequests:Map.<cid,resolve> The mapping structure is implemented to achieve precise matching of requests and responses and lifecycle management. `generateCorrelationId()` is the core function used to generate a globally unique identifier `cid` for each frontend request, ensuring strict binding between each request and response and preventing message crosstalk. `pendingRequests` is a storage container used to temporarily store the mapping relationship between requests in the waiting response state and their corresponding callbacks. It uses a key-value pair structure, where the key is the `cid` generated by `generateCorrelationId()`, and the value is the `resolve` callback method of the asynchronous request object (Promise) bound to that `cid`. `cid` serves as a unique identifier for the request to match the response, and `resolve` is used to pass the response result returned by the server to the request initiator to end the request's waiting state. The core function of `pendingRequests` is to store the mapping relationship of requests in the waiting response state, supporting finding the corresponding `resolve` method to return the result when the server returns a response with the same `cid`. It also supports timeout recycling or mapping cleanup after response completion, thereby achieving request traceability and efficient resource management. Through the collaborative working mechanism of the request coordinator 113, it can be ensured that each request and response corresponds one-to-one, so that the front-end request and the server response can be accurately matched. Furthermore, through the resource management strategy of timeout recycling and mapping cleanup mechanism, memory leaks can be avoided, system stability can be improved, and business processes can be executed smoothly.
[0037] Optionally, in some embodiments, the session management layer 122 includes: a response suspension unit, used to temporarily store a response carrying a unique identifier when the WebSocket connection is disconnected; and a response resending unit, used to resend the temporarily stored response according to the unique identifier and return a newly generated response when the WebSocket connection is normal.
[0038] In this optional embodiment, the session management layer 122 implements the core function of resending responses after a network outage through a combination of response suspension and reconnection resending logic. The session management layer 122, through its response suspension unit, temporarily stores response data carrying a unique identifier when the WebSocket connection is disconnected, thus ensuring that response data is not lost during the outage and providing a data foundation for subsequent reconnection resending. This temporary storage can be implemented through data storage methods such as memory caching, distributed message queues, or database persistence. Based on the strong correlation between request and response, a mapping relationship is established between the corresponding unique identifier and the response data and stored. The response resending unit, upon the restoration of the WebSocket connection (e.g., through successful session authentication, a connection status marked as connected, or receipt of a frontend reconnection confirmation message), resends the response data temporarily stored during the outage. It resends the corresponding response according to the unique identifier, first resending the response data suspended during the outage, and then processing the newly generated response data, ensuring the consistency of the request-response sequence, avoiding data corruption, and achieving a closed-loop request-response mechanism. Through the session management layer 122, it is possible to ensure that responses are not lost during network outages, responses are accurate after reconnection, and idempotent resending is achieved, thus guaranteeing the integrity of request responses and business continuity in complex network environments and providing a stable and reliable communication foundation for handling complex business scenarios.
[0039] Optionally, see Figure 3 In some embodiments, the communication system 100 further includes an event distribution module 130 and several front-end service modules 140; the server module 120 is deployed on the server, and the front-end management module 110, the event distribution module 130 and the front-end service modules 140 are deployed on the client; the server module 120 is also used to send topic-based messages to the event distribution module 130, and each front-end service module 140 is used to subscribe to topic-based messages in the event distribution module 130 on demand.
[0040] In this optional embodiment, the event distribution module 130 is a message middleware responsible for distributing topic-based messages. Specifically, it can adopt a message bus architecture, using a publish-subscribe pattern to send or broadcast messages for precise routing. Furthermore, by maintaining a mapping relationship between "topic → subscriber list," it manages the listening requirements of the client's user interface (UI) and the front-end business module 140. Upon receiving topic-based messages from the server, it distributes the messages to the corresponding subscription modules according to the topic, avoiding message redundancy caused by global listening and reducing coupling between modules. The front-end business module 140 refers to the functional component on the client side that implements specific business logic. It is responsible for handling business-related logic, receiving topic-based messages pushed by the event distribution module 130, and updating the interface or performing business operations.
[0041] In this optional embodiment, topic-based messages are asynchronous push messages, distinct from request-response messages. These are real-time data messages proactively pushed from the server to the client, requiring no client-initiated request. They do not carry unique identifiers and are primarily used to transmit information such as business status updates, system notifications, and real-time scene data. The on-demand subscription of the front-end business module 140 refers to the front-end business module 140 registering a specific topic listener with the event distribution module 130 based on its own business needs. It only receives messages related to that topic and executes corresponding business logic or interface update operations upon receiving a message related to that topic. Through the collaborative work of the event distribution module 130 and several front-end business modules 140, the communication system 100 effectively reduces the processing overhead of irrelevant messages, improves client performance, achieves low coupling between modules, adapts to the message transmission needs of complex real-time business scenarios, and ensures the smooth execution of business processes.
[0042] Optionally, continue reading Figure 3 In some embodiments, the communication system 100 is applied to the northbound development of the open-source HarmonyOS system; the communication system 100 also includes a low-level callback module 150, which is used to: send a first callback function to the front-end management module 110 when the WebSocket connection is normal; send a second callback function to the front-end management module 110 when the WebSocket connection is disconnected; and send a third callback function to the front-end management module 110 when the front-end management module 110 receives a response.
[0043] In this optional embodiment, the communication system 100 is specifically applied to the northbound development of the open-source HarmonyOS system. It utilizes the underlying callback mechanism of the native WebSocket in the open-source HarmonyOS system to achieve connection status monitoring, message reception notification, and resource cleanup. Specifically, the communication system 100 also includes an underlying callback module 150, which is deployed on the client side and interacts directly with the connection table 111, reconnection state machine 112, and request coordinator 113 in the front-end management module 110. The underlying callback module 150 handles connection status changes and forwards message events, enabling the front-end management module 110 to execute corresponding connection management, reconnection triggering, and message processing logic. This achieves full-process monitoring of the lifecycle of each WebSocket connection, thereby ensuring the communication reliability and business continuity of the communication system 100.
[0044] In this optional embodiment, when the WebSocket connection is successfully established, the underlying callback module 150 generates a first callback function and sends it to the front-end management module 110 (specifically, it can call the reconnection counting unit of the reconnection state machine 112 and the state update interface of the connection table 111). The first callback function can be marked as "open". Specifically, it can set the "connected" status flag for the corresponding connection entry during the process of updating the WebSocket connection status in the connection table 111, and trigger the reconnection counting unit to clear the reconnection count during the process of reconnection state machine 112 processing connection recovery, thereby completing the reset of the connection status and preparing for subsequent communication.
[0045] In this optional embodiment, when the WebSocket connection is disconnected or an error occurs, the underlying callback module 150 generates a second callback function and sends it to the front-end management module 110 (specifically, it can call the resource cleanup interface of the request coordinator 113 and the reconnection trigger interface of the reconnection state machine 112). The second callback function can be marked as "close". Specifically, during the process of the request coordinator 113 processing incomplete requests, it can trigger the timeout recycling unit to clean up the pending request mapping relationship in the waiting state to release memory resources. Alternatively, during the process of the reconnection state machine 112 detecting connection abnormalities, it can trigger the reconnection processing unit to start the disconnection reconnection process, thereby triggering the execution of the reconnection mechanism and ensuring the automatic recovery of the connection.
[0046] In this optional embodiment, when the front-end management module 110 receives a message sent by the server, the underlying callback module 150 generates a third callback function and sends it to the front-end management module 110 (specifically, it can call the response matching interface of the request coordinator 113 and the topic routing interface of the event dispatch module 130). This third callback function can be labeled "message". Specifically, in the message processing flow, it can instruct the request coordinator 113 to perform structured parsing of the message content, so as to instruct the request coordinator 113 to parse the message content (e.g., if the message content can be in JSON format, it can be parsed by a JSON parser). If the parsing result contains a unique identifier cid, the response matching unit of the request coordinator 113 is triggered to match the corresponding identifier. During the pending request process, the underlying callback module 150 can also generate a fourth callback function (which can be labeled "resolve") to indicate that the server response has successfully matched the corresponding request and completed data transmission. This allows the front-end request coordinator 113 to pass the server's response result to the corresponding asynchronous request, ending the waiting state of the request and enabling the front-end business module 140 to obtain the response data and execute subsequent logic. Simultaneously, the front-end request coordinator 113 is triggered to clean up the mapping relationship between the cid and resolve corresponding to the request, and generates a successful reception callback data to be sent to the server. The server removes the mapping relationship between the cid and the response stored in its own memory based on this callback data, completing the entire request-response closed loop process. If the parsing result does not contain cid, the event dispatch module 130 is triggered to dispatch the message to the corresponding front-end business module 140 according to the topic type, so that the front-end business module 140 can update the interface state or execute corresponding business logic operations based on the message content. This optional embodiment, through the full lifecycle event listening and forwarding capabilities of the underlying callback module 150, can achieve real-time perception of connection status, precise message routing, and efficient resource reclamation, ensuring the stable operation of the communication system 100 and the smooth execution of services. In the specific northbound development of the open-source HarmonyOS, the above solution can effectively combine the unique event mechanism, underlying callback mechanism, and timer management of the open-source HarmonyOS system, fully adapting to HarmonyOS distributed scenarios and achieving stable communication and business collaboration across devices and scenarios.
[0047] In this embodiment, the specific communication processing flow of the communication system 100 can be found in [reference needed]. Figure 4When sending a message from the front end, a unique identifier (cid) can be created for the request through the front end request coordinator 113, or no cid can be created. The front end management module 110 can then process the request data (CreateRequestData) to obtain the request and send it (SendRequest). Simultaneously, a key-value pair structure Map is also used.<cid,Promise> The mapping relationship is stored, and a mapping dictionary between the unique identifier and the request object is established. When the front-end management module 110 receives the response, the front-end will process the received response data (GetResponse) containing the unique identifier. On the one hand, it will determine the successful reception callback function (SuccessCallBack) based on the unique identifier and send it to the server to inform the server that the response has been successfully received. The server can then perform corresponding resource cleanup operations. On the other hand, it will compare the unique identifier in the response with the unique identifier in the key-value pair structure to obtain the corresponding Promise object (GetPromise) and trigger the fourth callback function (Resolve) indicating that the data transmission is complete, thereby removing the mapping relationship corresponding to the unique identifier.
[0048] In this embodiment, please continue to refer to Figure 4 The server maintains a Map that stores unique identifiers and response relationships.<cid,Response> Upon receiving a request (GetRequest), the server checks if the request contains a unique identifier. If the request does not contain an cid, it indicates that the request is a topic-based push request, and the response data can be distributed to the message bus of the event distribution module 130 for the front-end business module 140 to subscribe to on demand. If the request contains an cid, it checks if the request is a success callback request (SuccessCallBack) indicating that the front-end has successfully received the response. If the request is a success callback request (SuccessCallBack), the cid and its mapping in the mapping dictionary can be removed. If the request is not a success callback request (SuccessCallBack), it is a business request, and the server can process the response based on the business request, generate response data containing the corresponding unique identifier (CreateResponse), and send the response data (SendResponse). At the same time, the cid can be inserted into the mapping dictionary so that the response can be suspended when the connection is broken, and the response data can be temporarily stored when the connection is broken and resent after the connection is restored. During the communication process between the two ends, the reconnection state machine 112 will determine whether the connection is successful and handle the reconnection when the connection is broken. If the connection is successful, it will send the response message to the front end for reception (GetResponse) and processing.
[0049] This embodiment, based on the front-end management module 110 and the server module 120 that establish connections using the WebSocket protocol, specifically isolates independent WebSocket connections for multiple services through a connection table 111 to avoid message interference and fault propagation between services; it achieves automatic reconnection and state management through a reconnection state machine 112 to effectively address connection interruption issues caused by network fluctuations, avoid reconnection storms, and ensure stable and controllable connection recovery; it assigns a unique identifier to each request and establishes a mapping relationship through a request coordinator 113 to ensure accurate matching of response messages and consistency of data processing logic; and it temporarily stores response data during disconnection through a session management layer 122 to ensure the complete transmission of responses carrying unique identifiers after connection recovery, ensuring that requests are not lost and responses are traceable, thereby improving the communication reliability and business continuity of the system in complex network environments. This solution implements business processing logic such as self-healing after disconnection, strong request-response correlation, and idempotent resending after network outage. It can significantly improve the stability and reliability of WebSocket communication, reduce the maintenance cost and resource consumption of operating system application development, avoid the risk of business interruption and data loss due to connection abnormalities, ensure the smooth execution of business processes and efficient utilization of system resources, and help to facilitate the rapid deployment of highly reliable real-time services in operating system application development. It also reduces the maintenance cost and technical threshold for developers at the communication layer, and promotes the widespread adoption and stable operation of real-time interactive applications in the corresponding operating system ecosystem.
[0050] See Figure 5 , Figure 5 This is a schematic diagram of an embodiment of the communication method provided in this application. The method is applied to, for example... Figures 1 to 4 The described communication system 100. The communication method specifically includes: Step 201: Isolate and manage multiple independent WebSocket connections according to the requested business type using connection table 111; Step 202: Initiate a reconnection according to the preset reconnection rules when the WebSocket connection is broken via the reconnection state machine 112; Step 203: Generate a unique identifier for each request through the request coordinator 113, and manage the mapping relationship between the unique identifier and the request; Step 204: The business processing layer 121 performs business processing based on the received request and generates a response carrying a unique identifier corresponding to the request; Step 205: Through the session management layer 122, temporarily store the response when the WebSocket connection is broken, and return the response when the connection is restored.
[0051] Optionally, in some embodiments, multiple independent WebSocket connections are isolated and managed according to the requested service type through the connection table 111, including: based on the connection table 111 which adopts a key-value pair structure, multiple independent WebSocket connections are isolated and managed according to the requested service type; wherein, the key of the key-value pair structure is a service type identifier, and the value of the key-value pair structure is WebSocket object information; the WebSocket object information includes at least one of the connection status, reconnection count, and connection resource locator of the corresponding WebSocket connection.
[0052] Optionally, in some embodiments, the reconnection state machine 112 initiates a reconnection according to a preset reconnection rule when the WebSocket connection is disconnected. This includes: initiating a disconnection reconnection for the corresponding WebSocket connection by the reconnection processing unit when a connection disconnection is detected or a reconnection command is received; accumulating the number of reconnections when a reconnection fails by the reconnection counting unit, and clearing the number of reconnections when a reconnection succeeds by the reconnection counting unit; initiating a delay timer by the delay timer unit; and determining whether the number of reconnections exceeds a preset upper limit threshold by the upper limit threshold unit after the delay timer reaches a preset delay duration. If the number of reconnections exceeds the preset upper limit threshold, a reconnection failure message is reported; if the number of reconnections does not exceed the preset upper limit threshold, a reconnection command is sent to the reconnection processing unit.
[0053] Optionally, in some embodiments, the request coordinator 113 generates a unique identifier for each request and manages the mapping relationship between the unique identifier and the request, including: generating a unique identifier for each request through an identifier generation unit; establishing and storing the mapping relationship between the unique identifier and the corresponding request through a mapping management unit; matching the request corresponding to the unique identifier carried in the response when a response is received from the server module 120 through a response matching unit, so as to clean up the mapping relationship between the corresponding request and the corresponding unique identifier; and setting a timeout period for each mapping relationship through a timeout recycling unit, and cleaning up the corresponding mapping relationship if no corresponding response is received after the timeout period has expired after the request is sent.
[0054] Optionally, in some embodiments, the session management layer 122 temporarily stores the response when the WebSocket connection is disconnected and returns the response when the connection is restored, including: temporarily storing the response carrying a unique identifier when the WebSocket connection is disconnected through the response suspension unit; and resending the temporarily stored response according to the unique identifier and returning the newly generated response when the WebSocket connection is restored through the response resending unit.
[0055] Optionally, in some embodiments, the communication method further includes: sending topic-type messages to the event distribution module 130 through the server module 120; and subscribing to topic-type messages in the event distribution module 130 on demand through the front-end business module 140.
[0056] Optionally, in some embodiments, the communication system 100 is applied to the northbound development of the open-source HarmonyOS system; the communication method further includes: sending a first callback function to the front-end management module 110 through the underlying callback module 150 when the WebSocket connection is normal, sending a second callback function to the front-end management module 110 when the WebSocket connection is disconnected, and sending a third callback function to the front-end management module 110 when the front-end management module 110 receives a response.
[0057] Since the embodiments of the method section correspond to the embodiments of the system described above, please refer to the system embodiments described above for the description of the communication method provided by the embodiments of the present invention. The embodiments of the present invention will not be described again here, but have the same beneficial effects as the communication system 100 described above.
[0058] See Figure 6 , Figure 6 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application.
[0059] The storage medium 300 stores program data 310, which, when executed by the processor, implements, as follows: Figure 5 The described communication method. The program data 310 is stored in a storage medium 300 and includes several instructions for causing a network device (such as a router, personal computer, or server) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. Optionally, the storage medium 300 can be any medium capable of storing the program data 310, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.
[0060] See Figure 7 , Figure 7 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application.
[0061] The computer device 400 includes a processor 420 and a memory 410 interconnected. The memory 410 stores a computer program, and when the processor 420 executes the computer program, it implements, for example, Figure 5The described communication method. Specifically, the computer device 400 can be a mobile phone, tablet, personal computer, or set-top box, such as a mobile phone or tablet running the HarmonyOS operating system. Utilizing its powerful processor and memory combination, it efficiently executes each step of the communication method. The memory 410 can include storage medium 300 or other separately developed memory. The processor 420 can be a system-on-a-chip (SoC), central processing unit (CPU), or graphics processing unit (GPU) with powerful computing capabilities. This application does not specifically limit the type and specifications of the aforementioned computer device 400, memory 410, and processor 420.
[0062] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations 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 patent protection scope of this application.
Claims
1. A communication system, characterized in that, The communication system includes a front-end management module and a server-side module; the front-end management module and the server-side module establish a connection based on the WebSocket protocol; the front-end management module is used to send requests and receive responses, and the server-side module is used to perform business processing based on the requests and return responses; The front-end management module includes: a connection table, used to isolate and manage multiple independent WebSocket connections according to the business type of the request; a reconnection state machine, used to initiate reconnection according to preset reconnection rules when a WebSocket connection is broken; and a request coordinator, used to generate a unique identifier for each request and manage the mapping relationship between the unique identifier and the request. The server-side module includes: a business processing layer, used to perform business processing based on the received request and generate a response carrying a unique identifier corresponding to the request; and a session management layer, used to temporarily store the response when the WebSocket connection is disconnected and return the response when the connection is restored.
2. The communication system according to claim 1, characterized in that, The connection table adopts a key-value pair structure, where the key of the key-value pair structure is a business type identifier, and the value of the key-value pair structure is WebSocket object information; the WebSocket object information includes at least one of the following: connection status of the corresponding WebSocket connection, number of reconnections, and connection resource locator.
3. The communication system according to claim 1, characterized in that, The reconnection state machine includes: The reconnection processing unit is used to initiate a reconnection of the corresponding WebSocket connection when a connection is detected to be disconnected or a reconnection command is received. The reconnection counter unit is used to accumulate the number of reconnections when a reconnection fails, and to clear the number of reconnections when a reconnection succeeds. The delay timing unit is used to initiate delay timing; The upper limit threshold unit is used to determine whether the number of reconnections exceeds a preset upper limit threshold after the delay time reaches a preset delay duration. If the number of reconnections exceeds the preset upper limit threshold, a reconnection failure message is reported. If the number of reconnections does not exceed the preset upper limit threshold, a reconnection instruction is sent to the reconnection processing unit.
4. The communication system according to claim 1, characterized in that, The request coordinator includes: The identifier generation unit is used to generate a unique identifier for each request. The mapping management unit is used to establish and store the mapping relationship between unique identifiers and corresponding requests; The response matching unit is used to match the request corresponding to the unique identifier carried in the response when the response is received from the server module, so as to clean up the mapping relationship between the corresponding request and the corresponding unique identifier. The timeout recycling unit is used to set a timeout period for each mapping relationship. If no corresponding response is received after the timeout period has elapsed after a request is sent, the corresponding mapping relationship is cleaned up.
5. The communication system according to claim 1, characterized in that, The session management layer includes: The response suspend unit is used to temporarily store a response carrying a unique identifier when the WebSocket connection is closed; The response resending unit is used to resend the temporarily stored response and return the newly generated response according to the unique identifier when the WebSocket connection is normal.
6. The communication system according to claim 1, characterized in that, The communication system also includes an event distribution module and several front-end service modules; The server-side module is deployed on the server side, and the front-end management module, the event distribution module, and the front-end business module are deployed on the client side. The server module is also used to send topic-based messages to the event distribution module, and each of the front-end business modules is used to subscribe to the topic-based messages in the event distribution module as needed.
7. The communication system according to any one of claims 1-6, characterized in that, The communication system is used for northbound development of the open-source HarmonyOS system; the communication system also includes a low-level callback module, which is used for: When the WebSocket connection is successful, the first callback function is sent to the front-end management module; When the WebSocket connection is broken, a second callback function is sent to the front-end management module; When the front-end management module receives a response, a third callback function is sent to the front-end management module.
8. A communication method, applied to a communication system as described in any one of claims 1-7, characterized in that, The method includes: Multiple independent WebSocket connections can be isolated and managed according to the business type of the request using a connection table; By using a reconnection state machine, a reconnection is initiated according to preset reconnection rules when the WebSocket connection is broken; The request coordinator generates a unique identifier for each request and manages the mapping between the unique identifier and the request. The business processing layer processes the received request and generates a response carrying a unique identifier corresponding to the request. The session management layer temporarily stores responses when the WebSocket connection is closed and returns responses when the connection is restored.
9. A storage medium storing program data thereon, characterized in that, When the program data is executed by the processor, the steps of the communication method as described in claim 8 are implemented.
10. A computer device, characterized in that, It includes an interconnected processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the steps of the communication method as described in claim 8.