Method, apparatus, electronic device, and storage medium for communication mode switching

Abstract

This invention relates to the field of data processing, and discloses a communication mode switching method, apparatus, electronic device, and storage medium. The method includes: determining a first communication mode for the client based on the client's attribute information; establishing an initial communication connection between the client and a server; collecting time-series data between the client and the server; if abnormal event data of a preset type is identified from the time-series data, disconnecting the initial communication connection; determining a backup second communication mode corresponding to the first communication mode from a mapping relationship; and using the second communication mode, establishing a target communication connection between a second communication submodule in the client and a second service submodule in the server. This invention can dynamically allocate communication modes based on the client's attribute information and automatically switch communication modes based on abnormal event data.

Description

1. Description of Communication Mode Switching Method, Apparatus, Electronic Device, and Storage Medium Technical Field This invention relates to the field of data processing, and more particularly to a communication mode switching method, apparatus, electronic device, and storage medium. Background Art With the popularization of mobile Internet applications, the data interaction scenarios between clients and servers are becoming increasingly complex. Currently, the mainstream communication modes mainly include the WebSocket protocol based on long connections and the HTTP protocol based on short connections. WebSocket has the advantages of low latency and bidirectional real-time push, but it has high requirements for network stability, is prone to connection failure in weak network environments, and consumes a lot of energy; the HTTP protocol has strong compatibility and good penetration, making it suitable for weak network environments, but its request-response mechanism leads to poor real-time performance, and frequent handshakes increase the server load. In practical applications, the network environment, business operation scenarios, and terminal status of users are constantly changing dynamically. An ideal communication solution should be able to automatically select the most suitable communication mode according to these changes to balance real-time performance, success rate, and energy consumption. However, existing technical solutions have obvious rigidity defects in the selection and application of communication modes: existing clients usually lock the use of a single communication mode only based on the application type or hard-coded configuration during the application initialization phase. Once selected, the communication mode remains unchanged throughout the entire session lifecycle, regardless of network quality fluctuations or changes in business needs. This can lead to high latency when high real-time performance is required due to sticking to the HTTP mode, or connection interruptions and resource waste when sticking to the WebSocket mode in a deteriorating network environment. Existing technologies, due to their static and fixed communication strategies and lack of anomaly detection and dynamic switching capabilities based on time-series data analysis, struggle to simultaneously guarantee high real-time performance, high success rate, and low energy consumption in the complex and ever-changing mobile internet environment. Therefore, there is an urgent need for a method that can dynamically allocate and automatically switch communication modes based on anomaly event data detection. Summary of the Invention: In view of the above, it is necessary to provide a communication mode switching method, the purpose of which is to provide a method that can dynamically allocate communication modes based on client attribute information and automatically switch to the optimal second communication mode based on anomaly event data.The present invention provides a communication mode switching method, the method comprising: when a client initiates a request to a server to establish a communication connection, obtaining attribute information related to the communication mode in the client, searching for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the first communication mode of the client; using the first communication mode, establishing an initial communication connection between a first communication submodule in the client and a first service submodule in the server; after the initial communication connection is established, collecting communication interaction data between the client and the server in real time, generating time-series data based on the communication interaction data, and monitoring in real time whether a preset type of abnormal event data appears in the time-series data; if the abnormal event data is detected, disconnecting the initial communication connection, and determining a backup second communication mode corresponding to the first communication mode from the mapping relationship based on the attribute information; using the second communication mode, establishing a target communication connection between a second communication submodule in the client and a second service submodule in the server. Optionally, obtaining the attribute information related to the communication mode in the client includes: obtaining historical communication data of the client within a preset time period; performing feature extraction and classification processing on the historical communication data to obtain the business scenario type to which the client belongs; and determining the business scenario type as the attribute information of the client. Optionally, searching for a communication mode that matches the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the first communication mode of the client, includes: using the business scenario type to which the client belongs as the attribute information; querying a pre-defined business scenario type-communication mode mapping table according to the business scenario type, and determining the found communication mode as the first communication mode of the client. Optionally, the attribute information includes at least one of the client's device identifier and user account identifier. The step of searching for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the client's first communication mode, includes: extracting an ID identifier from the attribute information, where the ID identifier is either the device identifier or the user account identifier; searching for a communication mode matching the ID identifier based on a preset identifier-communication mode mapping table; and determining the found communication mode as the client's first communication mode.Optionally, the identifier-communication mode mapping table is constructed as follows: Registration information of multiple clients is obtained, the registration information including the client's ID identifier and the user level associated with the ID identifier; A first communication mode corresponding to the ID identifier and a backup second communication mode corresponding to the first communication mode are determined according to a preset mapping rule; A mapping relationship is established between the ID identifier and the first and second communication modes, and the identifier-communication mode mapping table is generated based on the mapping relationship. Optionally, establishing an initial communication connection between a first communication submodule in the client and a first service submodule in the server using the first communication mode includes: Parsing component configuration information corresponding to the first communication mode, the component configuration information including the identifier of the first communication submodule and the access address of the first service submodule; Based on the identifier, obtaining a first communication submodule matching the identifier in the client; Initiating a connection request to the access address using the first communication submodule to trigger a handshake negotiation between the first service submodule in the server and the first communication submodule to establish the initial communication connection. Optionally, the preset type of abnormal event data includes business interface response failure events and heartbeat timeout events. Monitoring whether the preset type of abnormal event data appears in the time-series data includes: When the first communication mode is HTTP communication mode, analyzing the business request data items in the time-series data, detecting whether the response data item corresponding to the business request data item appears within a preset first response time threshold, and whether the status code of the response data item indicates success; if no response appears within the first response time threshold or the status code indicates an error, it is identified as a business interface response failure event; When the first communication mode is WebSocket communication mode, analyzing the heartbeat request data items in the time-series data, detecting whether the heartbeat response data item corresponding to the heartbeat request data item appears within a preset second heartbeat time threshold; if the heartbeat response data item does not appear within the second heartbeat time threshold, it is identified as a heartbeat timeout event.To address the aforementioned problems, the present invention also provides a communication mode switching device, comprising: a lookup module, configured to, when a client initiates a request to establish a communication connection with a server, acquire attribute information related to the communication mode in the client, search for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determine the found communication mode as the first communication mode of the client; an establishment module, configured to, using the first communication mode, establish an initial communication connection between a first communication submodule in the client and a first service submodule in the server; an identification module, configured to, after the initial communication connection is established, collect communication interaction data between the client and the server in real time, generate time-series data based on the communication interaction data, and monitor in real time whether a preset type of abnormal event data appears in the time-series data; and a backup module, configured to, if the abnormal event data is detected, disconnect the initial communication connection and, based on the attribute information, determine a backup second communication mode corresponding to the first communication mode from the mapping relationship; A connection module is used to establish a target communication connection between a second communication submodule in the client and a second service submodule in the server using the second communication mode. To address the above problems, the present invention also provides an electronic device comprising: at least one processor; and a memory initially communicatively connected to the at least one processor; wherein the memory stores a communication mode switching program executable by the at least one processor, the communication mode switching program being executed by the at least one processor to enable the at least one processor to perform the above-described communication mode switching method. To address the above problems, the present invention also provides a computer-readable storage medium storing a communication mode switching program, the communication mode switching program being executable by one or more processors to implement the above-described communication mode switching method. Compared to the prior art, the present invention dynamically allocates communication modes to clients based on attribute information, which not only ensures compatibility with various terminal access methods but also optimizes server resource scheduling from the source, avoiding the waste of long-connection resources caused by a "one-size-fits-all" strategy. After the initial communication connection is established between the client and the server, the interaction data between the two parties is collected in real time and time-series data is generated. By analyzing this time-series data, abnormal event data such as business interface response failure or heartbeat timeout can be accurately identified. Once such a preset trigger condition is detected, the current initial communication connection with faulty or high latency risk is immediately disconnected, and the system automatically switches from the first communication mode to the preset second communication mode. Subsequently, using a dedicated submodule adapted to the second communication mode, the target communication connection between the server and the client is quickly rebuilt.This process enables the communication system to move away from relying on a single fixed link and instead proactively and quickly switch to a backup communication protocol when a degradation in communication quality or connection failure is detected (HK 20135248 A 6). This effectively avoids prolonged service interruptions or data loss due to a single communication mode failure, significantly improving the stability, fault tolerance, and continuity of service between the client and server. It ensures that the data transmission channel remains uninterrupted even when the network environment fluctuates or some protocols are unavailable. Figure 1 is a flowchart illustrating a communication mode switching method according to an embodiment of the present invention; Figure 2 is a block diagram illustrating a communication mode switching device according to an embodiment of the present invention; Figure 3 is a structural diagram illustrating an electronic device implementing the communication mode switching method according to an embodiment of the present invention. The objectives, functional characteristics, and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Description To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this invention. It should be noted that the descriptions involving "first," "second," etc., in this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of 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. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention. Referring to Figure 1, a flowchart of a communication mode switching method provided by an embodiment of this invention is shown. This method is executed by an electronic device. In this embodiment, the method for switching communication modes includes: S1. When a client initiates a request to the server to establish a communication connection, it obtains attribute information related to the communication mode in the client, searches for a communication mode that matches the attribute information in a preset mapping relationship between attribute information and communication modes, and determines the found communication mode as the client's first communication mode. In this embodiment, when the client starts an application, refreshes a page, or detects a network change requiring reconnection, it actively initiates a request to the server to establish a communication connection. This request is an independent handshake message or an initial service request containing a specific identifier.The system retrieves communication mode-related attribute information from the client, such as business scenario type, client ID identifier, device performance classification, network environment, communication information, or behavioral feature vectors. Acquisition methods include direct parsing of request messages or querying the server-side database based on a unique identifier. The system then searches for a communication mode that matches the attribute information within a predefined mapping relationship between attribute information and communication modes. This mapping relationship defines the correspondence between attribute information and communication protocols (such as HTTP long polling, HTTP short polling, WebSocket, Server-Sent Events (SSE), and MQTT). Using the attribute information as an index, the system retrieves the first communication mode by searching the mapping relationship between attribute information and communication modes. This invention achieves dynamic allocation of communication modes based on client-side attribute information, ensuring compatibility with various terminal access methods, optimizing server-side resource scheduling from the source, avoiding the waste of long-connection resources caused by a "one-size-fits-all" strategy, and laying the foundation for establishing efficient and adaptable initial communication connections. In one embodiment, obtaining attribute information related to the communication mode in the client includes: obtaining historical communication data of the client within a preset time period; performing feature extraction and classification processing on the historical communication data to obtain the HK 20135248 A 8 business scenario type to which the client belongs; and determining the business scenario type as the attribute information of the client. Obtaining historical communication data of the client within a preset time period (such as the past 24 hours or the current session period) covers dimensions such as request frequency, average message size, connection hold duration, heartbeat interval, error retransmission rate, and main interaction interface types. Feature extraction and quantification processing are performed on the historical communication data to transform unstructured logs into feature vectors representing key indicators of communication behavior, including concurrent frequency distribution, message size patterns, and connection stability characteristics. The feature vectors are then matched with a predefined business scenario feature library. If the characteristics indicate high concurrency, low latency sensitivity, and strong connection persistence, it is identified as a "real-time high-frequency trading scenario"; if it indicates periodic bursts, large data volumes, and long interaction intervals, it is identified as a "batch data synchronization scenario"; if it indicates low-frequency access, small data packets, and no need for continuous connection, it is identified as a "low-frequency information query scenario." The determined business scenario type is directly used as the client's current attribute information. This attribute information will serve as a key index for subsequent mapping relationship lookups, ensuring that the most suitable communication protocol is dynamically matched based on the client's real-time behavior patterns, thereby achieving on-demand allocation of communication resources.In one embodiment, the step of searching for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the first communication mode of the client, includes: using the business scenario type to which the client belongs as the attribute information; querying a pre-prepared business scenario type-communication mode mapping table according to the business scenario type, and determining the found communication mode as the first communication mode of the client. The business scenario type to which the client belongs is used as the client's attribute information. This business scenario type is a core identifier characterizing the client's current behavioral features (e.g., "real-time high-frequency trading scenario," "batch data synchronization scenario," or "low-frequency information query scenario"); accessing a pre-built and stored business scenario type-communication mode mapping table. This business scenario type-communication mode mapping table explicitly defines the correspondence between different business scenario types and the optimal communication protocol or strategy. For example, when the business scenario type is "real-time high-frequency trading scenario," the communication mode corresponding to HK 20135248 A 9 in the mapping table is configured as WebSocket full-duplex long connection to ensure low latency and bidirectional real-time push; when the business scenario type is "batch data synchronization scenario," the corresponding communication mode in the mapping table is configured as HTTP long polling to optimize high-throughput transmission efficiency; when the business scenario type is "low-frequency information query scenario," the corresponding communication mode in the mapping table is configured as HTTP short polling to save server resources. These examples are not intended to be limiting. Utilizing the business scenario type-communication mode mapping table to dynamically allocate communication modes to clients ensures that valuable server connections are reserved for truly needed business operations, thereby supporting greater concurrency under the same hardware conditions and improving system resource utilization. In one embodiment, the business scenario type-communication mode mapping table is constructed as follows: Multi-dimensional transmission features are extracted from historical sample data, including at least one of average data packet size, sending frequency, connection duration, and uplink / downlink traffic ratio; Based on the multi-dimensional transmission features, business scenario types are divided into multiple feature intervals, where each feature interval corresponds to a preset type of business communication requirement; According to preset mapping rules, a first communication mode and a corresponding backup second communication mode are configured for each feature interval; A mapping relationship is established between each business scenario type and its corresponding first and second communication modes to generate the business scenario type-communication mode mapping table. Historical sample data is parsed to extract multi-dimensional transmission features such as average data packet size, sending frequency, connection duration, and uplink / downlink traffic ratio.Based on the numerical distribution of multidimensional transmission characteristics, business scenario types are divided into multiple characteristic intervals, and the preset business communication requirements corresponding to each characteristic interval are clearly defined (e.g., distinguishing between those emphasizing real-time interaction and those emphasizing resource saving or compatibility). According to preset mapping rules, communication mode pairs are configured for each characteristic interval: for intervals emphasizing real-time interaction, WebSocket communication mode is configured as the first communication mode; for intervals emphasizing resource saving or compatibility, HTTP short polling mode is configured as the first communication mode. Simultaneously, a corresponding backup second communication mode is configured for each first communication mode (e.g., when the first communication mode is WebSocket HK 20135248 A 10, the backup second communication mode can be HTTP long polling, server-sent event SSE, or other applicable alternative protocols; when the first communication mode is HTTP short polling, the backup second communication mode can be HTTP long polling, server-sent event SSE, WebSocket, or other applicable alternative protocols). The specific type of the second communication mode is not limited; it only needs to ensure that it effectively complements the first communication mode to guarantee connection availability. HTTP long polling mode is configured as the second communication mode with higher connection stability. For regions prioritizing resource conservation or compatibility, HTTP short polling mode is configured as the first communication mode, and Server Send Event (SSE) mode is configured as the second communication mode with lower latency, ensuring that the preferred and backup modes complement each other in terms of technical characteristics. A mapping relationship is established between each business scenario type and its corresponding first and second communication modes, generating and storing a business scenario type-communication mode mapping table. The corresponding communication mode can be directly retrieved from the business scenario type-communication mode mapping table. This avoids re-running complex feature extraction algorithms or machine learning models for real-time inference on each request, significantly reducing server CPU load and decision latency. In one embodiment, the attribute information includes at least one of the client's device identifier and user account identifier. The step of searching for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the client's first communication mode, includes: extracting an ID identifier from the attribute information, where the ID identifier is either the device identifier or the user account identifier; searching for a communication mode matching the ID identifier based on a preset identifier-communication mode mapping table; and determining the found communication mode as the client's first communication mode. Extracting the ID identifier from the attribute information, if the attribute information contains a logged-in User_ID (such as a user UID, mobile phone number hash value, etc.), then using that as the ID identifier.If a user is not logged in (anonymous) or their user account identifier is missing from their attribute information, the Device_ID (such as IMEI, IDFA, HK 20135248 A 11 MAC address, or device fingerprint) is extracted as the ID identifier. The extracted ID identifier is used as the search key to access a pre-built identifier-communication mode mapping table. This mapping table records the optimal communication strategy associated with each identifier. For example, if the ID identifier is "User A is a premium user (paid member)," the mapping table pre-stores the association for using WebSocket full-duplex mode. If the ID identifier is "User B is a low-level user (regular registered user)," the mapping table pre-stores the association for using HTTP short connection mode to reduce device power consumption and server load. Dynamically assigning the first communication mode to the client based on the ID identifier ensures that valuable server connections are reserved for truly needed business operations, thereby supporting greater concurrency under the same hardware conditions and improving system resource utilization. In one embodiment, the identifier-to-communication mode mapping table is constructed as follows: Registration information of multiple clients is obtained, the registration information including the client's ID identifier and the user level associated with the ID identifier; A first communication mode corresponding to the ID identifier and a backup second communication mode corresponding to the first communication mode are determined according to a preset mapping rule; A mapping relationship is established between the ID identifier and the first and second communication modes, and the identifier-to-communication mode mapping table is generated based on the mapping relationship. Registration information of multiple clients is obtained, and a unique ID identifier (such as device ID or user account) of the client is parsed from each registration information entry, and the user level attribute directly associated with the ID identifier is extracted. According to the preset mapping rule, the communication mode pair corresponding to the ID identifier is determined based on the extracted user level: if the user level is a high-level user, the WebSocket communication mode is designated as the first communication mode; if the user level is a low-level user, the HTTP short polling mode is designated as the first communication mode.Simultaneously, a corresponding backup second communication mode is configured for each first communication mode (for example, when the first communication mode is WebSocket, the backup second communication mode can use HTTP long polling, server-sent event SSE, or other suitable alternative protocols; when the first communication mode is HTTP short polling, the backup second communication mode can use HTTP long polling, server-sent event SSE, WebSocket, or other suitable alternative protocols). The specific type of the second communication mode is not limited; it only needs to ensure that it effectively complements the first communication mode to guarantee connection availability. A mapping relationship is established between each ID identifier and its corresponding first and second communication modes. The mode configurations of all identifiers are summarized, and an identifier-communication mode mapping table is generated and stored for subsequent business connection queries. By querying the identifier-communication mode mapping table based on the ID identifier, the first communication mode can be dynamically allocated to the client, realizing differentiated service quality assurance and high-availability connection strategies based on user levels. S2. Using the first communication mode, an initial communication connection is established between the first communication submodule in the client and the first service submodule in the server. In this embodiment, the corresponding first communication submodule is dynamically loaded from the component factory within the client, based on the specific type of the first communication mode. If the mode is WebSocket, the system instantiates a socket manager containing heartbeat maintenance and binary frame parsing functions; if it is HTTP mode, it instantiates an HTTP client component responsible for request queue management and timeout retries, and injects previously determined parameters such as heartbeat interval and timeout into these components. After receiving a connection request carrying the mode identifier of the first communication mode, the server-side access gateway routes the traffic to the first service submodule adapted to the first communication mode. Both submodules then begin executing a handshake process according to a predetermined protocol to establish an initial communication connection (such as a physical or logical channel). In the WebSocket scenario, the client sends a protocol upgrade request. After verifying the key and user authentication information, the server returns a protocol switch response, upgrading the TCP connection to a full-duplex channel and immediately exchanging the first heartbeat packet to confirm link liveness and synchronize the clock. In the HTTP scenario, the client initiates a session initialization request. After verifying the signature, the server generates a temporary session ID and returns it. The client then initiates the first round of data retrieval, completing the "connection is data" closed loop without needing to maintain the underlying long connection.In one embodiment, before establishing the initial communication connection between the first communication submodule in the client and the first service submodule in the server, the method further includes: pre-installing the first communication submodule and the second communication submodule in the client; and pre-installing the first service submodule and the second service submodule in the server; wherein the first communication submodule and the first service submodule are both interactive components adapted to the first communication mode, and the second communication submodule and the second service submodule are both interactive components adapted to the second communication mode. During system deployment, the client and server will pre-integrate two independent communication capabilities: the client has the first communication submodule and the second communication submodule built-in, and the server deploys the first service submodule and the second service submodule accordingly. These two sets of components are not general-purpose interfaces, but rather dedicated interactive units deeply customized for specific communication protocols. The first communication submodule and the first service submodule form a dedicated pair adapted to the "first communication mode." For example, they include a socket manager and a full-duplex channel processor specifically for handling WebSocket long connections, internally embedding the heartbeat maintenance, binary frame parsing, and real-time push logic specific to this mode. The second communication submodule and the second service submodule form another dedicated pair adapted to the "second communication mode." For example, they include a request queue manager and a stateless dispatcher specifically for handling HTTP short connections or polling scenarios, with core logic focusing on fast response, timeout retries, and session lifecycle management. This pre-installation of two independent communication submodules enables the system to switch communication modes without downloading code or restarting services; simply activating the corresponding submodule pair via configuration commands is sufficient. The selected submodule immediately takes over the network stack, establishing a connection with the server using pre-defined protocol logic. This not only avoids performance degradation of general-purpose components but also enhances the system's adaptability and disaster recovery capabilities in complex environments through pre-defined redundancy. In one embodiment, before establishing the initial communication connection between the first communication submodule in the client and the first service submodule in the server, the method further includes: monitoring the client establishing a connection with the server through the first communication mode; if the number of consecutive connection failures reaches a preset threshold, switching the first communication mode to a backup second communication mode corresponding to the first communication mode, wherein the second communication mode and the first communication mode are backup protocols for each other. Continuously monitoring the process of the client initiating a connection request to the server using the first communication mode, and counting the number of connection failures in real time.Once the number of consecutive failures reaches a preset threshold (e.g., 3 or 5 consecutive handshake timeouts, rejections, or no response), the current first communication mode is determined to be unavailable or extremely unstable in the current network environment. At this point, based on the client's attribute information, a backup second communication mode corresponding to the first communication mode is determined from the mapping relationship. Subsequently, the client uses the second communication submodule adapted to the second communication mode to re-initiate a connection request to the corresponding second service submodule on the server. This dual-mode switching mechanism ensures that if the first mode fails due to network blockage, firewall restrictions, or excessive server load, the communication link can be quickly rebuilt through the second mode, thus guaranteeing uninterrupted business continuity. In one embodiment, establishing an initial communication connection between a first communication submodule in the client and a first service submodule in the server using the first communication mode includes: parsing component configuration information corresponding to the first communication mode, the component configuration information including an identifier of the first communication submodule and an access address of the first service submodule; obtaining a first communication submodule matching the identifier in the client based on the identifier; and initiating a connection request to the access address using the first communication submodule to trigger a handshake negotiation between the first service submodule in the server and the first communication submodule to establish the initial communication connection. Parsing the component configuration information of the first communication mode extracts the unique identifier of the first communication submodule and the access address of the server. The client accurately locates and loads the matching first communication submodule from a pre-installed component library based on the identifier. The first communication submodule initiates a connection request to the server using the obtained access address, triggering a response from the corresponding first service submodule on the server. Both parties complete protocol verification and parameter synchronization through a specific handshake negotiation process, thereby successfully establishing the initial communication connection. The initial communication connection is established using the first communication mode, eliminating the need for frequent polling requests from the client and avoiding invalid polling requests. This significantly reduces redundant HTTP header information transmitted over the network, thus saving bandwidth resources. S3: After the initial communication connection is established, real-time data collection is performed on the communication interaction data between the client and the server (HK 20135248 A 15). Time-series data is generated based on this data, and the system monitors in real-time for any pre-defined type of abnormal event data. In this embodiment, after the initial communication connection is successfully established, raw data from each communication interaction between the client and the server is collected in real-time. This communication interaction data includes not only business-level information but also underlying network status indicators, such as packet transmission time, the specific number of lost packets, connection jitter, and retransmission frequency.The collected discrete data is organized and structured according to chronological order to generate a continuous time-series data stream. This clearly shows the complete trajectory of network connection quality changes over time, thus distinguishing between instantaneous network fluctuations and continuous performance degradation. Real-time monitoring is performed to check for pre-defined types of abnormal event data in the time-series data. Abnormal event data are early signals of network environment deterioration, such as multiple consecutive request-response timeouts, sudden precipitous drops in data transmission rates, or frequent unstable "flashovers" in the link within a short period. In one embodiment, the real-time collection of communication interaction data between the client and the server, and the generation of time-series data based on this communication interaction data, includes: real-time collection of communication interaction data between the client and the server; extracting the timestamp, message type identifier, and status code of each data packet from the communication interaction data to generate time-series data arranged in chronological order. All communication interaction data between the client and server is collected in real time. For each transmitted data packet, three dimensions of information are captured: 1. Timestamp: Precisely records the millisecond-level moment of data packet generation or arrival, providing a time reference for subsequent analysis; 2. Message type identifier: Clarifies the business attributes of the data packet (e.g., heartbeat packet, business instruction, error report, or control signaling) to distinguish different types of communication behavior; 3. Status code: Directly reflects the execution result of the interaction (e.g., success, timeout, rejection, or service unavailable), a key indicator for judging network health. These extracted dimensions are arranged and reorganized in chronological order to generate a continuous, complete, and semantically rich time-series data stream. Transforming discrete communication interaction data into time-series data is not merely a simple recording and organization process, but a qualitative leap from "single-point monitoring" to "trend insight," enabling smarter, more proactive, and more stable communication mode switching decisions.In one embodiment, the preset type of abnormal event data includes business interface response failure events and heartbeat timeout events. Monitoring whether the preset type of abnormal event data appears in the time-series data includes: When the first communication mode is HTTP communication mode, analyzing the business request data items in the time-series data, detecting whether the response data item corresponding to the business request data item appears within a preset first response time threshold, and whether the status code of the response data item indicates success; if no response appears within the first response time threshold or the status code indicates an error, it is identified as a business interface response failure event; When the first communication mode is WebSocket communication mode, analyzing the heartbeat request data items in the time-series data, detecting whether the heartbeat response data item corresponding to the heartbeat request data item appears within a preset second heartbeat time threshold; if the heartbeat response data item does not appear within the second heartbeat time threshold, it is identified as a heartbeat timeout event. The preset type of abnormal event data also includes a packet verification error rate exceeding a threshold or a connection unexpected interruption signal. When the first communication mode is HTTP communication mode, traversing each business request data item in the time-series data and monitoring the corresponding response data item. Not only must the response arrive within a preset first response time threshold, but it must also carry a status code indicating success (e.g., HTTP 200). If the response data item fails to arrive within this time threshold, or if it arrives but displays an incorrect status code (e.g., 5xx server error or 4xx client error), the interaction is classified as a "business interface response failure event." This means that the current HTTP link can no longer reliably transmit business data. When the first communication mode switches to WebSocket communication mode, since this is a long-connection mechanism (HK 20135248 A 17), the system's monitoring focus shifts from specific business requests to the heartbeat mechanism that maintains connection activity. At this time, the system specifically analyzes the heartbeat request data item in the time-series data and checks whether a corresponding heartbeat response data item is returned within a preset second heartbeat time threshold. If a heartbeat response is not received within the specified time, whether due to network interruption, server non-response, or data packet loss, the system will directly identify it as a "heartbeat timeout event." This indicates that the current WebSocket long-connection link has failed or is in an unstable "half-open" state. This differentiated analysis logic, tailored to the characteristics of different protocols, can accurately detect service interruptions in HTTP mode and connection breaks in WebSocket mode.Once any of the above-mentioned preset types of abnormal event data are identified, a conclusive basis for triggering a communication mode switch is obtained, enabling a timely and proactive smooth transition from the current fault mode to the second communication mode, ensuring the continuity and stability of user services. S4. If the abnormal event data is detected, the initial communication connection is disconnected, and based on the attribute information, the backup second communication mode corresponding to the first communication mode is determined from the mapping relationship. In this embodiment, once preset abnormal event data (such as continuous heartbeat timeout, data packet verification error rate exceeding a threshold, or unexpected connection interruption signal) is identified, the abnormal handling mechanism is immediately triggered, and the initial communication connection is proactively disconnected to release resources and prevent error propagation. The attribute information of the current client (including the ID identifier or business scenario type determined above) is extracted, and the attribute information is used as a query key to search in the constructed mapping table (business scenario type-communication mode mapping table or identifier-communication mode mapping table) to locate the backup second communication mode corresponding to the first communication mode currently used by the client (i.e., the initial mode that was just disconnected). This situation is set up with a backup second communication mode paired with the first communication mode. Finally, a new connection establishment process is initiated, using a defined second communication mode (e.g., switching from WebSocket to HTTP long polling, or from HTTP short polling to SSE) to send a connection request to the server, completing the reorganization and recovery of the communication link, and ensuring that business data can continue to be transmitted through complementary technical paths after an anomaly occurs. In other embodiments, when the first communication mode is paired with multiple backup second communication modes, the client's current multi-dimensional context features are collected, including real-time network environment quality, client device performance classification, current business scenario type, historical communication information, and user behavior feature vectors. According to the preset dynamic optimization strategy, the matching degree between the multi-dimensional context features and each candidate communication mode is calculated. The specific matching degree calculation process is as follows: First, the system calculates the network environment weight based on real-time network environment quality parameters: if the packet loss rate or jitter exceeds a preset threshold, it is determined that the network fluctuation is severe, and a higher weight coefficient is assigned to the anti-interference dimension; otherwise, a lower weight is assigned. Second, the system calculates the device resource weight based on the client device performance parameters: if the battery power is lower than a preset value or the CPU load is too high, it is determined that the resources are limited, and a higher weight coefficient is assigned to the low power consumption dimension; otherwise, a lower weight is assigned. Third, the system calculates the business demand weight based on the current business scenario parameters: if it is marked as a high real-time requirement, a higher weight coefficient is assigned to the low latency dimension; otherwise, a standard weight is assigned. The above three dynamic weight coefficients are multiplied by the corresponding inherent capability scores in the candidate mode characteristic matrix, and the three product results are summed to obtain the initial matching score of the candidate mode.Finally, the system uses connection success rate data from historical communication information to linearly correct the initial matching score (e.g., multiplying the initial score by the historical success rate coefficient), thereby obtaining the final comprehensive score for each candidate mode. The candidate communication modes are then sorted in descending order according to the calculated comprehensive scores, and the candidate communication mode with the highest score is directly selected as the backup second communication mode corresponding to the first communication mode. The client is then controlled to initiate a new connection request according to the protocol specifications of this mode, completing the switching of the communication link. This invention overcomes the limitation of the fixed and rigid second communication mode in existing technologies, proposing an adaptive optimization mechanism based on real-time multi-dimensional contextual features of the client. This mechanism can dynamically perceive network environment fluctuations, device resource status, and business scenario requirements, intelligently matching and switching to the optimal second communication mode. Through this dynamic adaptation strategy, not only is the continuity and stability of business connections effectively guaranteed under extreme conditions, avoiding service interruptions, but communication efficiency and resource utilization are also significantly improved, thereby maximizing the overall user experience in complex and ever-changing network environments. HK 20135248 A 19 S5. Using the second communication mode, a target communication connection is established between the second communication submodule in the client and the second service submodule in the server. In this embodiment, after determining the backup second communication mode, the connection reconstruction process is initiated. The second communication submodule, specifically adapted to the second communication mode within the client, is activated and actively initiates a connection request to the server; simultaneously, the corresponding second service submodule on the server side also enters a ready state to respond to this request. These two submodules, as interactive components designed specifically for the second communication protocol, execute a specific handshake protocol with each other, thereby establishing a completely new target communication connection between the client and the server. In one embodiment, establishing a target communication connection between a second communication submodule in the client and a second service submodule in the server using the second communication mode includes: parsing component configuration information corresponding to the second communication mode, wherein the component configuration information includes an identifier of the second communication submodule and an access address of the second service submodule; obtaining a second communication submodule matching the identifier in the client based on the identifier; and initiating a connection request to the access address using the second communication submodule to trigger a handshake negotiation between the second service submodule in the server and the second communication submodule to establish the initial communication connection. Parsing the component configuration information corresponding to the second communication mode includes two key elements: first, a unique identifier for the client-side second communication submodule, used to accurately locate the specific interactive component; and second, the network access address (such as IP address, domain name, and port number) of the server-side second service submodule, indicating the destination of the connection.Based on the parsed identifier, a search is performed in the client's local component library or registry to quickly locate and load the second communication submodule that perfectly matches the identifier. The activated second communication submodule will actively initiate a connection request to the server using the access address in the configuration. This action will trigger a response from the corresponding second service submodule on the server, and both parties will then begin the handshake negotiation process for this communication mode (e.g., exchanging keys, negotiating parameter versions, or confirming heartbeat mechanisms). Once the handshake is successful, a brand new target communication connection based on the second communication mode is formally established, replacing the previously disconnected faulty link and restoring the data interaction capability between the client and the server. Figure 2 shows a schematic diagram of the communication mode switching device provided in an embodiment of the present invention. The communication mode switching device 100 of the present invention can be installed in a device. Depending on the implemented functions, the communication mode switching device 100 may include a search module 110, an establishment module 120, an identification module 130, a backup module 140, and a connection module 150. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by a device processor and perform a fixed function, and are stored in the device's memory. In this embodiment, the functions of each module / unit are as follows: A lookup module 110 is used to obtain attribute information related to the communication mode in the client when the client initiates a request to establish a communication connection with the server, search for a communication mode that matches the attribute information in a preset mapping relationship between attribute information and communication modes, and determine the found communication mode as the client's first communication mode; An establishment module 120 is used to establish an initial communication connection between a first communication submodule in the client and a first service submodule in the server using the first communication mode; An identification module 130 is used to collect communication interaction data between the client and the server in real time after the initial communication connection is established, generate time-series data based on the communication interaction data, and monitor in real time whether a preset type of abnormal event data appears in the time-series data; A backup module 140 is used to disconnect the initial communication connection if the abnormal event data is detected, and determine a backup second communication mode corresponding to the first communication mode from the mapping relationship based on the attribute information. The connection module 150 is used to establish a target communication connection between the second communication submodule in the client and the second service submodule in the server using the second communication mode.In one embodiment, obtaining the attribute information related to the communication mode in the client includes: HK 20135248 A 21 obtaining the client's historical communication data within a preset time period; performing feature extraction and classification processing on the historical communication data to obtain the business scenario type to which the client belongs; and determining the business scenario type as the attribute information of the client. In one embodiment, searching for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the first communication mode of the client, includes: using the business scenario type to which the client belongs as the attribute information; querying a pre-prepared business scenario type-communication mode mapping table according to the business scenario type, and determining the found communication mode as the first communication mode of the client. In one embodiment, the attribute information includes at least one of the client's device identifier and user account identifier. The step of searching for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the client's first communication mode, includes: extracting an ID identifier from the attribute information, where the ID identifier is either the device identifier or the user account identifier; searching for a communication mode matching the ID identifier based on a preset identifier-communication mode mapping table; and determining the found communication mode as the client's first communication mode. In one embodiment, the identifier-communication mode mapping table is constructed as follows: obtaining registration information from multiple clients, where the registration information includes the client's ID identifier and the user level associated with the ID identifier; determining the first communication mode corresponding to the ID identifier and a backup second communication mode corresponding to the first communication mode according to preset mapping rules; establishing a mapping relationship between the ID identifier and the first and second communication modes, and generating the identifier-communication mode mapping table based on the mapping relationship. HK 20135248 A 22 In one embodiment, establishing an initial communication connection between a first communication submodule in the client and a first service submodule in the server using the first communication mode includes: parsing component configuration information corresponding to the first communication mode, the component configuration information including an identifier of the first communication submodule and an access address of the first service submodule; obtaining a first communication submodule matching the identifier in the client based on the identifier; and initiating a connection request to the access address using the first communication submodule to trigger a handshake negotiation between the first service submodule in the server and the first communication submodule to establish the initial communication connection.In one embodiment, the preset type of abnormal event data includes business interface response failure events and heartbeat timeout events. Monitoring whether the preset type of abnormal event data appears in the time-series data includes: When the first communication mode is HTTP communication mode, analyzing the business request data items in the time-series data, detecting whether the response data item corresponding to the business request data item appears within a preset first response time threshold, and whether the status code of the response data item indicates success; if no response appears within the first response time threshold or the status code indicates an error, it is identified as a business interface response failure event; When the first communication mode is WebSocket communication mode, analyzing the heartbeat request data items in the time-series data, detecting whether the heartbeat response data item corresponding to the heartbeat request data item appears within a preset second heartbeat time threshold; if the heartbeat response data item does not appear within the second heartbeat time threshold, it is identified as a heartbeat timeout event. Figure 3 shows a schematic diagram of the structure of an electronic device for implementing a communication mode switching method according to an embodiment of the present invention. In this embodiment, electronic device 1 includes, but is not limited to, a memory 11, a processor 12, and a network interface 13, which are initially communicatively connected to each other via a system bus. The memory 11 stores a communication mode switching program 10, which can be executed by the processor 12. Figure 3 only shows electronic device 1 with components 11-13 and the communication mode switching program 10. Those skilled in the art will understand that the structure shown in Figure 3 does not constitute a limitation on electronic device 1, and it may include fewer or more components than shown, or combine certain components, or have different component arrangements. The memory 11 includes RAM and at least one type of readable storage medium. The memory provides a cache for the operation of the electronic device 1; the readable storage medium can be a non-volatile storage medium such as 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, disk, optical disk, etc. In some embodiments, the readable storage medium can be an internal storage unit of the electronic device 1; in other embodiments, the non-volatile storage medium can also be an external storage device of the electronic device 1, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. equipped on the electronic device 1.In this embodiment, the readable storage medium of the memory 11 is typically used to store the operating system and various application software installed on the electronic device 1, such as storing the code of the communication mode switching program 10 in one embodiment of the present invention. Furthermore, the memory 11 can also be used to temporarily store various types of data that have been output or will be output. The processor 12 in some embodiments may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 12 is typically used to control the overall operation of the electronic device 1, such as performing control and processing related to data interaction or communication with other devices. In this embodiment, the processor 12 is used to run the program code stored in the memory 11 or process data, such as running the communication mode switching program 10. The network interface 13 may include a wireless network interface or a wired network interface, which is used to establish an initial communication connection between the electronic device 1 and a terminal (not shown in the figure). Optionally, the electronic device 1 may further include a user interface, which may include a display, an input unit such as a keyboard, and optionally a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the electronic device 1 and to display a visual user interface. It should be understood that the embodiments described are for illustrative purposes only and are not limited to this structure in the scope of the patent application.The communication mode switching program 10 stored in the memory 11 of the electronic device 1 is a combination of multiple instructions. When run in the processor 12, it can achieve the following: When the client initiates a request to establish a communication connection with the server, it obtains the attribute information related to the communication mode in the client, searches for a communication mode that matches the attribute information in a preset mapping relationship between attribute information and communication modes, and determines the found communication mode as the first communication mode of the client; Using the first communication mode, it establishes an initial communication connection between the first communication submodule in the client and the first service submodule in the server; After the initial communication connection is established, it collects the communication interaction data between the client and the server in real time, generates time-series data based on the communication interaction data, and monitors in real time whether the time-series data contains a preset type of abnormal event data; If the abnormal event data is detected, it disconnects the initial communication connection, and determines the backup second communication mode corresponding to the first communication mode from the mapping relationship based on the attribute information; Using the second communication mode, it establishes a target communication connection between the second communication submodule in the client and the second service submodule in the server. Specifically, the specific implementation method of the communication mode switching program 10 by the processor 12 can be referred to the description of the relevant steps in the corresponding embodiment of Figure 1, which will not be repeated here. Further, if the module / unit integrated by the electronic device 1 is implemented as a software functional unit (HK 20135248 A 25) and sold or used as an independent product, it can be stored in a computer-readable storage medium. The computer-readable medium can be non-volatile or non-volatile. The computer-readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, or a read-only memory (ROM). The communication mode switching program 10 is stored on the computer-readable storage medium, and the communication mode switching program 10 can be executed by one or more processors. The specific implementation of the computer-readable storage medium of the present invention is basically the same as the various embodiments of the communication mode switching method described above, and will not be repeated here. In the several embodiments provided by the present invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of the modules is only a logical functional division, and there may be other division methods in actual implementation.The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules. It is obvious to those skilled in the art that the present invention is not limited to the details of the above exemplary embodiments, and that the present invention can be implemented in other specific forms without departing from the spirit or basic characteristics of the present invention. Therefore, the embodiments should be considered exemplary and non-limiting in all respects. The scope of the present invention is defined by the appended claims rather than the foregoing description, and therefore all changes falling within the meaning and scope of the equivalents of the claims are intended to be included within the present invention. No appended diagram markings in the claims of HK 20135248 A 26 should be considered as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the system claims may also be implemented by a single unit or device through software or hardware. The term "second class" is used to indicate names and does not imply any specific order. Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent conversions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention.HK 20135248 A 1 Claim 1. A communication mode switching method, characterized in that the method includes: when a client initiates a request to a server to establish a communication connection, obtaining attribute information related to the communication mode in the client, searching for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the first communication mode of the client; using the first communication mode, establishing an initial communication connection between a first communication submodule in the client and a first service submodule in the server; after the initial communication connection is established, collecting communication interaction data between the client and the server in real time, generating time-series data based on the communication interaction data, and monitoring in real time whether a preset type of abnormal event data appears in the time-series data; if the abnormal event data is detected, disconnecting the initial communication connection, and determining a backup second communication mode corresponding to the first communication mode from the mapping relationship based on the attribute information; using the second communication mode, establishing a target communication connection between a second communication submodule in the client and a second service submodule in the server. 2. The communication mode switching method as described in claim 1, characterized in that, obtaining the attribute information related to the communication mode in the client includes: obtaining historical communication data of the client within a preset time period; performing feature extraction and classification processing on the historical communication data to obtain the business scenario type to which the client belongs; and determining the business scenario type as the attribute information of the client. 3. The communication mode switching method as described in claim 2, characterized in that, searching for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the first communication mode of the client, includes: using the business scenario type to which the client belongs as the attribute information; querying a preset business scenario type-communication mode mapping table according to the business scenario type, and determining the found communication mode as the first communication mode of the client.4. The communication mode switching method as described in claim 1, wherein the attribute information includes at least one of the client's device identifier and user account identifier, and the step of searching for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determining the found communication mode as the client's first communication mode, includes: extracting an ID identifier from the attribute information, wherein the ID identifier is the device identifier or the user account identifier; searching for a communication mode matching the ID identifier based on a preset identifier-communication mode mapping table; and determining the found communication mode as the client's first communication mode. 5. The communication mode switching method as described in claim 4, wherein the identifier-communication mode mapping table is constructed according to the following method: obtaining registration information of multiple clients, wherein the registration information includes the client's ID identifier and the user level associated with the ID identifier; determining the first communication mode corresponding to the ID identifier and a backup second communication mode corresponding to the first communication mode according to a preset mapping rule; establishing a mapping relationship between the ID identifier and the first and second communication modes, and generating the identifier-communication mode mapping table based on the mapping relationship. 6. The communication mode switching method as described in claim 1, characterized in that, establishing an initial communication connection between the first communication submodule in the client and the first service submodule in the server using the first communication mode includes: parsing component configuration information corresponding to the first communication mode, wherein the component configuration information includes an identifier of the first HK 20135248 A 3 communication submodule and an access address of the first service submodule; obtaining, based on the identifier, a first communication submodule matching the identifier in the client; and initiating a connection request to the access address using the first communication submodule to trigger a handshake negotiation between the first service submodule in the server and the first communication submodule to establish the initial communication connection.7. The communication mode switching method as described in claim 1, characterized in that the preset type of abnormal event data includes business interface response failure events and heartbeat timeout events, and the monitoring of whether the preset type of abnormal event data appears in the time series data includes: when the first communication mode is HTTP communication mode, analyzing the business request data items in the time series data, detecting whether the response data item corresponding to the business request data item appears within a preset first response time threshold, and whether the status code of the response data item indicates success; if no response or status code indicates error appears within the first response time threshold, it is identified as a business interface response failure event; when the first communication mode is WebSocket communication mode, analyzing the heartbeat request data items in the time series data, detecting whether the heartbeat response data item corresponding to the heartbeat request data item appears within a preset second heartbeat time threshold; if the heartbeat response data item does not appear within the second heartbeat time threshold, it is identified as a heartbeat timeout event. 8. A communication mode switching device, characterized in that the device comprises: a lookup module, configured to, when a client initiates a request to establish a communication connection with a server, obtain attribute information related to the communication mode in the client, search for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determine the found communication mode as the first communication mode of the client; an establishment module, configured to, using the first communication mode, establish an initial communication connection between a first communication sub-module in the client and a first service sub-module in the server; an identification module, configured to, after the initial communication connection is established, collect communication interaction data between the client and the server in real time, generate time-series data based on the communication interaction data, and monitor in real time whether a preset type of abnormal event data appears in the time-series data; and a backup module, configured to, if the abnormal event data is detected, disconnect the initial communication connection, and determine a backup second communication mode corresponding to the first communication mode from the mapping relationship based on the attribute information; A connection module is used to establish a target communication connection between a second communication submodule in the client and a second service submodule in the server using the second communication mode. 9. An electronic device, characterized in that the device comprises: at least one processor; and a memory initially communicatively connected to the at least one processor; wherein the memory stores a communication mode switching program executable by the at least one processor, the communication mode switching program being executed by the at least one processor to enable the at least one processor to perform the communication mode switching method as described in any one of claims 1 to 7.10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a communication mode switching program, the communication mode switching program being executable by one or more processors to implement the communication mode switching method as described in any one of claims 1 to 7. HK 20135248 A 1 Specification Drawings When the client initiates a request to establish a communication connection with the server, the client obtains attribute information related to the communication mode, searches for a communication mode matching the attribute information in a preset mapping relationship between attribute information and communication modes, and determines the found communication mode as the client's first communication mode. Using the first communication mode, an initial communication connection is established between the first communication submodule in the client and the first service submodule in the server. S1 After the initial communication connection is established, the client and the server collect communication interaction data in real time, generates time-series data based on the communication interaction data, and monitors in real time whether a preset type of abnormal event data appears in the time-series data. If the abnormal event data is detected, the initial communication connection is disconnected, and based on the attribute information, a backup second communication mode corresponding to the first communication mode is determined from the mapping relationship. S2 S3 S4 Using the second communication mode, a target communication connection is established between the second communication submodule in the client and the second service submodule in the server. S5 Figure 1 HK 20135248 A 2 Communication Mode Switching Device 100 Identification module 130 Backup module 140 Establishment module 120 Search module 110 Connection module 150 Figure 2 Communication mode switching program 10 Electronic device 1 Processor 12 Network interface 13 Memory 11 Figure 3 HK 20135248 A.

Images