Communication system and method supporting multiple protocols, and medium

Abstract

The invention provides a communication system and method supporting multiple protocols and a medium, a local service platform realizes bidirectional data interaction with a third-party client platform through multiple built-in basic communication protocols, the development of an additional protocol adaptation layer is omitted, the docking difficulty and cost of a cross-protocol heterogeneous system are reduced, and the system architecture is simplified; meanwhile, double-factor verification, data encryption protection and middleware authentication operation are introduced, multi-layer verification is conducted on identity legality and data integrity, the risk that data are stolen, tampered or forged is effectively prevented, and communication safety and reliability are improved. Besides, a communication channel between the local server and the local client is established by means of middleware, an internal data interaction link is opened, intermediate links of data interaction are reduced, and the data transmission and processing efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer communication technology, and in particular to a communication system, method and medium that supports multiple protocols. Background Technology

[0002] In today's digital age, communication and interaction between various software systems have become increasingly frequent and complex. In numerous application scenarios, different systems or modules often require different communication protocols to meet their specific needs.

[0003] In existing technologies, the server-side architecture of most software systems suffers from the problem of supporting only one communication protocol. Many traditional server-side architectures only support one or a few communication protocols. For example, some early enterprise applications typically only support the HTTP protocol for data interaction, making it difficult to adapt to the interfacing requirements of multi-protocol heterogeneous systems. This results in significant obstacles to data interaction between cross-protocol systems, greatly increasing system integration costs and interfacing difficulties.

[0004] Specifically, in IoT device management scenarios, when a web application server based on the HTTP protocol needs to interact with an IoT device management system that has high real-time requirements, the data cannot be directly exchanged because the IoT device management system generally uses the WebSocket protocol, which supports bidirectional real-time communication. However, the web application server does not natively support the WebSocket protocol. Therefore, a complex protocol adaptation layer needs to be developed for conversion, which not only increases development investment and manpower costs, but also increases the overall system architecture complexity of the newly added adaptation layer module.

[0005] Furthermore, in scenarios with stringent real-time requirements, such as online games and real-time security monitoring, the TCP protocol has advantages in maintaining long connections and real-time data transmission. However, if existing servers do not natively support the TCP protocol, the implementation of related real-time transmission functions becomes significantly more difficult. Meanwhile, the Socket.IO protocol possesses unique technical advantages in cross-domain communication and cross-terminal / cross-browser compatibility. However, many existing software systems cannot directly support this protocol, hindering the realization of its technical advantages. Alternative adaptations are often achieved through additional cross-domain rule configurations and compatibility plugins, resulting in poor compatibility and insufficient stability.

[0006] Furthermore, existing communication technologies between software systems suffer from inadequate security mechanisms, lacking effective end-to-end security verification and protection during communication. Most systems rely solely on simple username and password verification for access authentication, failing to encrypt and verify the integrity of data during transmission. This makes data vulnerable to illegal theft, tampering, or forgery in the transmission chain, compromising the security and reliability of communication and posing a significant threat to data confidentiality and integrity.

[0007] In summary, existing communication technologies have significant shortcomings in terms of protocol diversity and communication security and reliability. There is an urgent need for a technical solution that can support multiple mainstream communication protocols and ensure communication security and reliability to solve these problems. Summary of the Invention

[0008] In view of the shortcomings of the prior art described above, the purpose of this application is to provide a communication system, method and medium that supports multiple protocols to solve the technical problem of insufficient communication security and reliability in the prior art.

[0009] To achieve the above and other related objectives, a first aspect of this application provides a multi-protocol communication system, including a local service platform with multiple basic communication protocols and a third-party client platform operating in a preset environment; the local service platform interacts bidirectionally with the third-party client platform based on a pre-matched target communication protocol, the method including: in response to a login success signal from the third-party client platform, generating a dynamic two-factor feature token based on the login ID of the third-party client platform and a first preset combination rule; returning the dynamic two-factor feature token to the third-party client platform, so that the third-party client platform generates a request data packet based on the dynamic two-factor feature token, and returns the request data packet to the local service platform; according to the... The request data packet undergoes a two-factor authentication operation. After the two-factor authentication operation passes, business logic processing is performed on the request data packet to generate business response data and configure a corresponding first real-time message event name for the business response data. Based on the first real-time message event name, a first authentication operation is performed. After the first authentication operation passes, local processing is performed on the business response data to generate response result data and configure a corresponding second real-time message event name for the response result data. Based on the second real-time message event name, a second authentication operation is performed. After the second authentication operation passes, a reasonableness verification operation is performed on the response result data, and the response result data that passes the reasonableness verification operation is returned to the third-party client platform.

[0010] In some embodiments of the first aspect of this application, the local service platform includes a local server. The local server, in response to a successful login signal from a third-party client platform, generates a dynamic two-factor feature token based on the login ID of the third-party client platform and a first preset combination rule. This generation process includes: generating raw key data based on the login ID of the third-party client platform and the first preset combination rule; performing a first encryption operation on the raw key data according to a preset cryptographic algorithm to generate a dynamic credential token; performing a second encryption operation on the login ID of the third-party client platform according to a preset hash algorithm to generate a static credential token; establishing a mapping relationship between the dynamic credential token and the static credential token, and caching the mapping relationship between the dynamic credential token and the static credential token in a pre-constructed mapping table; and performing a concatenation operation on the dynamic credential token and the static credential token to generate a dynamic two-factor feature token.

[0011] In some embodiments of the first aspect of this application, the local server is further configured to perform a two-factor authentication operation based on the request data packet, the method comprising: extracting a two-factor feature token to be authenticated from the request data packet, and performing a segmentation operation on the two-factor feature token to be authenticated to generate a dynamic token to be authenticated and a static token to be authenticated; traversing and querying the pre-built mapping table to lock a static credential token that matches the static token to be authenticated, and obtaining a dynamic credential token that has a mapping relationship with the static credential token; determining whether the dynamic token to be authenticated is the same as the dynamic credential token; if the dynamic token to be authenticated is the same as the dynamic credential token, then determining that the two-factor authentication operation has passed; if the dynamic token to be authenticated is not the same as the dynamic credential token, then determining that the two-factor authentication operation has failed, and performing an interruption operation.

[0012] In some embodiments of the first aspect of this application, the local server is further configured to generate a bus feature token according to a second preset combination rule, and perform a third encryption operation on the first real-time message event name according to the bus feature token to generate a first encrypted message event name, and encapsulate the first encrypted message event name with the business response data and then initiate a first bus call request.

[0013] In some embodiments of the first aspect of this application, the local service platform further includes middleware, which is used to perform a first authentication operation based on the first real-time message event name. The middleware includes: intercepting the first bus call request to extract a second encrypted message event name; performing a first decryption operation on the second encrypted message event name based on the bus feature token to generate a third real-time message event name; determining whether the third real-time message event name is the same as the first real-time message event name; if the third real-time message event name is the same as the first real-time message event name, then determining that the first authentication operation has passed; if the third real-time message event name is different from the first real-time message event name, then determining that the first authentication operation has failed and performing an interrupt operation.

[0014] In some embodiments of the first aspect of this application, the local service platform further includes a local client, which is used to perform local processing on the business response data to generate response result data, and configure a corresponding second real-time message event name for the response result data; according to the bus feature token, perform a fourth encryption operation on the second real-time message event name to generate a third encrypted message event name, and encapsulate the third encrypted message event name with the response result data to initiate a second bus call request.

[0015] In some embodiments of the first aspect of this application, the middleware is further configured to perform a second authentication operation based on the second real-time message event name, the method comprising: intercepting the second bus call request to extract a fourth encrypted message event name; performing a second decryption operation on the fourth encrypted message event name based on the bus feature token to generate a fourth real-time message event name; determining whether the fourth real-time message event name is the same as the second real-time message event name; if the fourth real-time message event name is the same as the second real-time message event name, then determining that the second authentication operation is successful; if the fourth real-time message event name is not the same as the second real-time message event name, then determining that the second authentication operation is unsuccessful, and performing an interrupt operation.

[0016] In some embodiments of the first aspect of this application, the matching method of the target communication protocol includes: obtaining the original communication protocol supported by the third-party client platform and determining the type of the original communication protocol; if the type of the original communication protocol belongs to a first preset protocol type, then the original communication protocol is used as the target communication protocol; if the type of the original communication protocol belongs to a second preset protocol type, then network indicator data and data volume identification data of the third-party client platform are obtained to determine the target communication protocol; wherein, the network indicator data includes network latency data and network bandwidth data.

[0017] To achieve the above and other related objectives, a second aspect of this application provides a multi-protocol communication method applied to a local service platform in a multi-protocol communication system as described above. The multi-protocol communication method includes: responding to a login success signal from a third-party client platform; generating a dynamic two-factor signature token based on the login ID of the third-party client platform and a first preset combination rule; returning the dynamic two-factor signature token to the third-party client platform, so that the third-party client platform generates a request data packet based on the dynamic two-factor signature token and returns the request data packet to the local service platform; performing a two-factor verification operation based on the request data packet, and verifying the two-factor signature. After the factor verification operation passes, business logic processing is performed on the request data packet to generate business response data and configure a corresponding first real-time message event name for the business response data; based on the first real-time message event name, a first authentication operation is performed, so that after the first authentication operation passes, local processing is performed on the business response data to generate response result data and a corresponding second real-time message event name is configured for the response result data; based on the second real-time message event name, a second authentication operation is performed, so that after the second authentication operation passes, a reasonableness verification operation is performed on the response result data, and the response result data that passes the reasonableness verification operation is returned to the third-party customer platform.

[0018] To achieve the above and other related objectives, a third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-protocol communication method described above.

[0019] As described above, the multi-protocol communication system, method, and medium of this application have the following beneficial effects:

[0020] (1) The local service platform has multiple built-in basic communication protocols to match with third-party customer platforms and achieve bidirectional data interaction with third-party customer platforms based on the pre-matched target communication protocol. There is no need to develop a complex protocol adaptation layer, which reduces the difficulty of connecting cross-protocol heterogeneous systems and the development investment, while simplifying the overall system architecture complexity.

[0021] (2) The introduction of two-factor authentication to prevent tampering and forgery is used to achieve secure authentication of access identity and to encrypt and protect transmitted data, thereby improving the security of data transmission. At the same time, combined with the authentication operation of the middleware, the validity of event names and data integrity of business response data and response result data are verified, which effectively prevents the risk of data being stolen, tampered or forged during transmission, reduces the risk of data leakage, and improves the security and reliability of the communication process.

[0022] (3) The local service platform builds a communication channel between the local server and the local client through middleware, opens up the data interaction link between the local server and the local client, reduces the intermediate links of data interaction, and improves the efficiency of data transmission and processing. Attached Figure Description

[0023] Figure 1 The diagram shown is a schematic representation of a communication system supporting multiple protocols according to an embodiment of this application.

[0024] Figure 2 The diagram shown is a flowchart illustrating the process of generating a dynamic two-factor feature token in one embodiment of this application.

[0025] Figure 3 The diagram shown is a flowchart illustrating the two-factor authentication operation performed in one embodiment of this application.

[0026] Figure 4 The diagram shows a flowchart of the first authentication operation performed in one embodiment of this application.

[0027] Figure 5 The diagram shows a flowchart of the second authentication operation performed in one embodiment of this application.

[0028] Figure 6 The diagram shown is a flowchart illustrating a communication method supporting multiple protocols in one embodiment of this application. Detailed Implementation

[0029] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0030] Before providing a further detailed description of the present invention, the nouns and terms used in the embodiments of the present invention are explained, and the nouns and terms used in the embodiments of the present invention are subject to the following interpretations:

[0031] <1> HTTP (HyperText Transfer Protocol) is an application layer protocol based on TCP, primarily used for transferring data between web browsers and web servers.

[0032] <2> Web (World Wide Web): The World Wide Web is an information system built on the Internet and composed of countless interconnected hypertexts.

[0033] <3> WebSocket: A network socket protocol that allows servers to proactively push data to clients without requiring frequent client requests. It is ideal for scenarios requiring real-time data interaction, such as online chat, real-time market data, and collaborative editing.

[0034] <4> TCP (Transmission Control Protocol) is a connection-oriented, reliable, byte-stream-based transport layer protocol located at the transport layer of the network model. Its role is to provide reliable data transmission services for application layer protocols in unreliable network environments.

[0035] <5> Socket.IO: A socket I / O framework, it is a real-time communication framework based on JavaScript that encapsulates various communication methods such as WebSocket and polling, enabling real-time, bidirectional data transmission between browsers and servers.

[0036] <6> JavaScript is an interpreted, weakly typed scripting language whose core function is to add interactive logic and dynamic effects to web pages, making static web pages "interactive and dynamically updatable".

[0037] <7> Token: An authentication token is an "identity credential" between the client and the server. It eliminates the need to transmit account and password every time you log in, making it both secure and efficient.

[0038] <8> Node.js is a JavaScript runtime environment built on the Chrome V8 engine that supports manipulating local system resources.

[0039] <9> Chrome: Google Chrome, built on the Chromium rendering engine, is characterized by its smooth operation, rich extension ecosystem, and strong compatibility. It is one of the most widely used web browsers in the world.

[0040] <10> Chromium is an open-source web page rendering engine and a core underlying component of the Chrome browser. It is responsible for parsing and rendering web page resources such as HTML, CSS, and JavaScript to present a complete web page interface.

[0041] <11> HTML (Hyper Text Markup Language): A markup language whose core function is to build the structural framework of web pages.

[0042] <12> CSS (Cascading Style Sheets): Its core function is to set visual styles for the structure of web pages built with HTML, thus solving the problem of web page aesthetics.

[0043] <13> gm-crypto: A national cryptographic algorithm library, specifically developed for the Node.js environment. It encapsulates the national cryptographic algorithms such as SM2, SM3, and SM4 formulated by the State Cryptography Administration into APIs that can be called directly. This allows developers to quickly complete data encryption, signing, and signature verification operations without having to implement complex encryption logic from scratch, simply by importing the library.

[0044] <14> SM2: The SM2 elliptic curve public-key cryptography algorithm is used for authentication, digital signatures, and key exchange.

[0045] <15> SM3: The SM3 cryptographic hash algorithm (also commonly known as the SM3 hash algorithm) is used for data integrity verification. It can convert raw data of any length into a fixed-length (256-bit) hash value, and has the characteristics of being "irreversible and uniquely corresponding".

[0046] <16> SM4: The SM4 block cipher algorithm (also commonly known as the SM4 symmetric encryption algorithm) is used for encrypted data transmission. It uses the same key for encryption and decryption, is fast and efficient, and is suitable for encrypting core data (such as diagnostic results and business data) during communication to ensure data transmission security.

[0047] <17> API (Application Programming Interface): An application programming interface is a bridge for communication between different programs.

[0048] <18> Crypto module: The cryptography module is a native encryption toolkit provided by Node.js that requires no additional installation. It is a fundamental tool for implementing data encryption, token generation, and identity authentication.

[0049] <19> HMAC-SHA256: Hash-based Message Authentication Code - SHA256 algorithm is a keyed hash authentication algorithm.

[0050] To facilitate understanding of the embodiments of this application, firstly, in conjunction with Figure 1 Detailed explanation. Figure 1A schematic diagram of a multi-protocol communication system according to an embodiment of the present invention is shown. The multi-protocol communication system 100 in this embodiment includes a local service platform 101 that creates multiple basic communication protocols and a third-party client platform 102 operating in a preset environment. The local service platform 101 interacts bidirectionally with the third-party client platform 102 based on a pre-matched target communication protocol, and the interaction includes:

[0051] (1) In response to the login success signal of the third-party client platform, generate a dynamic two-factor feature token based on the login ID of the third-party client platform and the first preset combination rule.

[0052] (2) The dynamic two-factor feature token is returned to the third-party client platform so that the third-party client platform generates a request data packet based on the dynamic two-factor feature token and returns the request data packet to the local service platform.

[0053] (3) Perform a two-factor authentication operation based on the request data packet, and after the two-factor authentication operation passes, perform business logic processing on the request data packet to generate business response data and configure the corresponding first real-time message event name for the business response data.

[0054] (4) Perform a first authentication operation based on the first real-time message event name, so that after the first authentication operation is passed, perform local processing on the business response data to generate response result data, and configure a corresponding second real-time message event name for the response result data.

[0055] (5) Perform a second authentication operation based on the second real-time message event name, so that after the second authentication operation passes, a reasonableness check operation is performed on the response result data, and the response result data that passes the reasonableness check operation is returned to the third-party customer platform.

[0056] In this embodiment, the local service platform 101 includes a local server 1011, middleware 1012, and a local client 1013. Middleware 1012 is responsible for bridging the communication channel between the local server 1011 and the local client 1012. Its core principle is based on the module shared process object exposed by the local server 1011. By creating a callback method for receiving data on the module shared process object, efficient data reception is achieved, and then the same bus scheme is used to publish messages to the local client.

[0057] In this embodiment, the third-party client platform (access party) 102 uses Node.js as its default runtime environment and introduces the national cryptographic algorithm library (gm-crypto) within this environment. The local server (interface party) 1011 creates various basic communication protocols based on the Node.js runtime environment. These basic communication protocols include, but are not limited to, TCP, Socket.IO, WebSocket, and HTTP, to diversify communication with external systems. For example, if it's an IoT platform and device interface, the third-party client platform (access party) is the smart device / device management system to be connected to the IoT platform, and the local server (interface party) is the IoT platform. If it's an intelligent diagnostic platform and a doctor's workstation interface, the third-party client platform (access party) is the doctor's workstation to be connected to the intelligent diagnostic platform, and the local server (interface party) is the intelligent diagnostic platform.

[0058] In this embodiment, the third-party client platform 102 does not need to create multi-protocol support itself; it only needs to adapt to a basic communication protocol provided by the local server according to its own business scenario to determine the matching target communication protocol. The matching method for the target communication protocol includes:

[0059] (1) Obtain the original communication protocols supported by the third-party customer platform and determine the type of the original communication protocols.

[0060] (2) If the original communication protocol is of the first preset protocol type, then the original communication protocol shall be used as the target communication protocol.

[0061] (3) If the type of the original communication protocol belongs to the second preset protocol type, then obtain the network indicator data and data volume identification data of the third-party customer platform to determine the target communication protocol; wherein, the network indicator data includes network latency data and network bandwidth data.

[0062] In this embodiment, the local server 1011 first establishes an initial communication link with the third-party client platform 102, receives the original communication protocols and communication requests (such as single requests, long connection polling, etc.) supported by the third-party client platform 102, and determines the type of the original communication protocol. If the type of the original communication protocol belongs to a first preset protocol type, such as HTTP, Socket.IO, etc., then the original communication protocol supported by the third-party client platform 102 is used as the target communication protocol.

[0063] In this embodiment, if the original communication protocol belongs to a second preset protocol type, such as TCP or WebSocket, the local server will perform network condition analysis and provide a recommended communication protocol to determine the target communication protocol. The principle is that the Network module in the local server 1011 actively collects network latency data and network bandwidth data from the third-party client platform 102, and extracts data volume identification data from the communication connection request header initiated by the third-party client platform 102. By parsing the data volume identification data, the service data volume is determined to assess whether the current network environment and the service data volume are compatible with the original communication protocol, thereby determining the target communication protocol. Specifically, if the network latency data is less than a preset latency threshold (e.g., 100ms) and the network bandwidth data is greater than a preset bandwidth threshold (e.g., 1Mbps), the local server 1011 will recommend WebSocket as the target communication protocol. If the service data volume is greater than a preset data volume threshold (e.g., 10MB) and the network bandwidth data is less than a preset bandwidth threshold (e.g., 1Mbps), the local server 1011 will recommend TCP as the target communication protocol. If neither the WebSocket recommendation condition of "network latency data less than < preset latency threshold (e.g., 100ms) and network bandwidth data > preset bandwidth threshold (e.g., 1Mbps)" nor the TCP recommendation condition of "business data volume > preset data volume threshold (e.g., 10MB) and network bandwidth data < preset bandwidth threshold (e.g., 1Mbps)" is met, then HTTP long polling is recommended as the target communication protocol as a fallback. In this way, by equipping the system with protocol detection and adaptive functions, the optimal communication strategy can be automatically adapted to complex network environments, enhancing the system's adaptability and stability in different network scenarios and ensuring the smoothness and real-time nature of data interaction.

[0064] In this embodiment, as Figure 2 The diagram illustrates a process for generating a dynamic two-factor feature token in an embodiment of the present invention. The local service platform 101 includes a local server 1011. The local server 1011, in response to a successful login signal from a third-party client platform 102, generates a dynamic two-factor feature token based on the login ID of the third-party client platform 102 and a first preset combination rule. The method includes:

[0065] S201: Generate raw key data based on the login ID of the third-party customer platform and the first preset combination rule.

[0066] In this embodiment, the local server 1011 concatenates the login ID of the third-party client platform 102 into a string according to the first preset combination rule of "login ID + multiple random numbers (e.g., 6 digits) + current timestamp". This string is the original key data (Key value).

[0067] S202: Perform a first encryption operation on the original key data according to a preset cryptographic algorithm to generate a dynamic credential token.

[0068] In this embodiment, the local server 1011 combines the preset cryptographic algorithms (such as SM2 and SM4) in the national cryptographic algorithm library (gm-crypto) to perform the first encryption operation on the original key data to generate a dynamic credential token (Token1). The generation of the dynamic credential token (Token1) relies on the national cryptographic algorithm, which not only meets the domestic information security compliance requirements, but also has the characteristic of dynamic change because the original key data contains random values ​​and timestamps, making it difficult to be forged.

[0069] S203: Perform a second encryption operation on the login ID of the third-party customer platform according to a preset hash algorithm to generate a static credential token.

[0070] In this embodiment, the local server 1011 calls the built-in Crypto native encryption module and uses a preset hash algorithm (such as HMAC-SHA256) to perform a second encryption operation on the login ID of the third-party client platform 102 to generate a static credential token (Token2). The generation of the static credential token (Token2) is only associated with the login ID of the third-party client platform 102, does not contain random values ​​or timestamps, and is a static feature value used to identify the basic identity of the third-party client platform 102, which can be used as a fallback credential for identity verification.

[0071] S204: Establish a mapping relationship between the dynamic credential token and the static credential token, and cache the mapping relationship between the dynamic credential token and the static credential token in a pre-built mapping table.

[0072] In this embodiment, after generating the dynamic credential token (Token1) and the static credential token (Token2), the local server 1011 establishes a mapping relationship between the dynamic credential token and the static credential token, and caches this mapping relationship in a pre-built mapping table. The purpose of caching is to provide a fast matching basis for subsequent two-factor authentication operations. When the third-party client platform 102 sends a Token request, the local server 1011 can quickly find the corresponding dynamic credential token (Token1) through the static credential token (Token2) to complete the two-factor authentication.

[0073] S205: Perform a concatenation operation on the dynamic credential token and the static credential token to generate a dynamic two-factor feature token.

[0074] In this embodiment, the local server 1011 concatenates the dynamic credential token (Token1) and the static credential token (Token2) into a complete string using a space as a separator, forming a dynamic two-factor feature token with two-factor characteristics, in the format Token1+space+Token2. This dynamic two-factor feature token is then used as the response data after successful login and returned to the third-party client platform 102 through the target communication protocol.

[0075] In this embodiment, the third-party client platform 102 encrypts business data based on a dynamic two-factor signature token and a national cryptographic algorithm library (gm-crypto) to generate a request data packet, and then returns the request data packet to the local server 1011 via the target communication protocol. The request data packet is a standardized data carrier that encapsulates core information when the third-party client platform 102 initiates a communication request to the local server 1011. It is a structured data set that integrates the dynamic two-factor signature token, encrypted business data, hash checksum of the business data, and request metadata (including request type, data packet generation timestamp, and data volume identifier) ​​according to a preset format, and is finally transmitted to the local server 1011 via the target communication protocol.

[0076] In this embodiment, as Figure 3 The diagram illustrates a flowchart of the two-factor validation operation in an embodiment of the present invention. The local server is further configured to perform the two-factor validation operation based on the request data packet, wherein the method includes:

[0077] S301: Extract the two-factor feature token to be verified from the request data packet, and perform a segmentation operation on the two-factor feature token to be verified to generate a dynamic token to be verified and a static token to be verified.

[0078] In this embodiment, after receiving the request data packet, the local server 1011 performs a two-factor authentication operation to prevent tampering and forgery. First, the extracted two-factor feature tokens to be verified are split according to the space rule to obtain dynamic and static tokens to be verified, thus completing the splitting of the two-factor tokens and preparing for subsequent verification.

[0079] S302: Traverse and query the pre-built mapping table to lock the static credential token that matches the static credential token to be verified, and obtain the dynamic credential token that has a mapping relationship with the static credential token.

[0080] In this embodiment, after the local server 1011 completes the segmentation of the two-factor feature token to be verified, it retrieves a pre-built mapping table. This mapping table caches the mapping relationship between dynamic credential tokens and static credential tokens. Then, by traversing and querying the mapping table, it searches line by line for static credential token records stored in the table to locate the static credential token entry that matches the segmented static token to be verified, providing baseline data for subsequent consistency verification. After a complete search, if no static credential token entry matching the segmented static token to be verified is found, the local server 1011 determines that the static identity credential of the third-party client platform 102 is invalid and immediately performs an interruption operation: refusing to process the current request data packet.

[0081] S303: Determine whether the dynamic token to be verified is the same as the dynamic credential token.

[0082] S304: If the dynamic token to be verified is the same as the dynamic credential token, then the two-factor verification operation is determined to be successful.

[0083] S305: If the dynamic token to be verified is not the same as the dynamic credential token, the two-factor verification operation is determined to fail, and an interrupt operation is performed.

[0084] In this embodiment, if the dynamic token to be verified matches the retrieved dynamic credential token, the local server 1011 determines that the two-factor authentication operation for the current request from the third-party client platform has passed, and then initiates the subsequent business data parsing and response process. If the dynamic token to be verified does not match the retrieved dynamic credential token, the local server 1011 determines that the two-factor authentication operation has failed, immediately performs an interruption operation, terminates the processing flow of the current request, closes the corresponding communication link with the third-party client platform 102, and records relevant exception information.

[0085] In this embodiment, when the third-party client platform 102 fails the two-factor authentication operation more than 5 times in a day, the third-party client platform 102 will be added to the blacklist to block the possibility of brute-force attacks.

[0086] In this embodiment, after the two-factor authentication operation passes, the encrypted business data in the request data packet is decrypted. If decryption fails due to abnormal ciphertext format or mismatched decryption keys, the business data is deemed incomplete, and the request is rejected. If decryption is successful, an integrity verification operation is performed on the decrypted business data. After the integrity verification passes, the local server extracts the decrypted business data, executes the corresponding business logic processing according to preset business rules, generates business response data that meets the format requirements, and configures the corresponding first real-time message event name according to the type of the business response data.

[0087] In this embodiment, the local server 1011 is further configured to generate a bus feature token according to a second preset combination rule, and perform a third encryption operation on the first real-time message event name according to the bus feature token to generate a first encrypted message event name, and encapsulate the first encrypted message event name with the business response data and initiate a first bus call request.

[0088] In this embodiment, the local server 1011 generates a bus feature token according to a second preset combination rule of "multiple random values ​​(e.g., 8 bits) + current timestamp". Then, using this bus feature token as the encryption key, a third encryption operation is performed on a pre-configured first real-time message event name using a national cryptographic algorithm to generate a first encrypted message event name. Subsequently, the local server 1011 encapsulates the first encrypted message event name and business response data in a formatted manner, and after encapsulation, initiates a first bus call request to the middleware 1012. The bus feature token, the first encrypted message event name, and the business response data are synchronized to the module shared process object exposed by the local server 1011. The middleware 1012 creates a data receiving callback method based on this module shared process object to achieve bidirectional data sharing with the local server 1011. When bridging the communication channel between the local server 1011 and the local client 1013, the bus feature token is included in the bus message publishing process as a credential for local internal communication.

[0089] In this embodiment, as Figure 4 The diagram illustrates a flowchart of the first authentication operation performed in an embodiment of the present invention. The local service platform 101 further includes middleware 1012, which is used to perform the first authentication operation based on the first real-time message event name, in the following manner:

[0090] S401: Intercept the first bus call request to extract the second encrypted message event name.

[0091] In this embodiment, middleware 1012 first initializes and creates a bus instance through a closure. This bus instance exists only within the closure and cannot be directly accessed by external systems. The closure exposes a proxy object, which serves as the sole entry point for external systems to access the bus instance. Operations that call the bus must be completed through this proxy object.

[0092] In this embodiment, when the local server 1011 initiates the first bus call request, the proxy object of the middleware 1012, as the sole entry point, intercepts the first bus call request immediately, extracts the second encrypted message event name from the first bus call request, and performs token authentication of the message event name, as well as token encryption and decryption of the transmitted data.

[0093] S402: Perform a first decryption operation on the second encrypted message event name according to the bus feature token to generate a third real-time message event name.

[0094] In this embodiment, the middleware 1012 uses a shared bus feature token to perform a first decryption operation on the second encrypted message event name, generating a readable plaintext event name, i.e., the third real-time message event name. If decryption fails, an interrupt operation is triggered directly.

[0095] S403: Determine whether the name of the third real-time message event is the same as the name of the first real-time message event.

[0096] S404: If the name of the third real-time message event is the same as the name of the first real-time message event, then the first authentication operation is determined to be successful.

[0097] S405: If the name of the third real-time message event is different from the name of the first real-time message event, then the first authentication operation is determined to have failed, and an interruption operation is performed.

[0098] In this embodiment, the middleware 1012 performs a consistency comparison between the third real-time message event name and the first real-time message event name. If the third real-time message event name is the same as the first real-time message event name, the middleware determines that the first authentication operation has passed. At this time, the proxy object forwards the first bus call request to the bus instance within the closure, completing the secure push of business response data to the local client 1013.

[0099] In this embodiment, if the name of the third real-time message event is different from the name of the first real-time message event, the middleware 1012 determines that the first authentication operation has failed. At this time, an interrupt operation is immediately performed, refusing to forward the first bus call request to the bus instance within the closure, terminating the current call process, and triggering a platform security alarm to ensure that the bus instance cannot be accessed by unauthorized calls.

[0100] In this embodiment, the local service platform 101 further includes a local client 1013, which is used to perform local processing on the business response data to generate response result data, and configure a corresponding second real-time message event name for the response result data; according to the bus feature token, it performs a fourth encryption operation on the second real-time message event name to generate a third encrypted message event name, and encapsulates the third encrypted message event name with the response result data to initiate a second bus call request.

[0101] In this embodiment, the local client 1013 pre-introduces the middleware 1012, obtains the bus feature token and bus instance, and subscribes to and receives the business response data pushed by the middleware 1012 according to the publish-subscribe rule of "encrypting bus event names based on bus feature tokens".

[0102] In this embodiment, the local client 1013 first performs local processing on the received service response data to generate response result data, and configures a corresponding second real-time message event name for the response result data. Then, based on the bus feature token, it performs a fourth encryption operation on the second real-time message event name to generate a third encrypted message event name. The third encrypted message event name and the response result data are then encapsulated together, and a second bus call request is initiated. After the middleware 1012 intercepts the second bus call request, it performs a second authentication operation. Upon successful authentication, the response result data is pushed to the local server 1011.

[0103] In this embodiment, as Figure 5 The diagram illustrates a flowchart of the second authentication operation in an embodiment of the present invention. The middleware 1012 is further configured to perform the second authentication operation based on the second real-time message event name, the method of which includes:

[0104] S501: Intercept the second bus call request to extract the fourth encrypted message event name.

[0105] In this embodiment, when the local client 1013 initiates a second bus call request, the proxy object of the middleware 1012 acts as the sole entry point to intercept the second bus call request and extract the fourth encrypted message event name from the second bus call request for subsequent second authentication operations.

[0106] S502: Perform a second decryption operation on the fourth encrypted message event name according to the bus feature token to generate a fourth real-time message event name.

[0107] In this embodiment, the middleware 1012 uses the same bus feature token to perform a second decryption operation on the fourth encrypted message event name to generate a fourth real-time message event name. If decryption fails, an interrupt operation is triggered directly.

[0108] S503: Determine whether the name of the fourth real-time message event is the same as the name of the second real-time message event.

[0109] S504: If the name of the fourth real-time message event is the same as the name of the second real-time message event, then the second authentication operation is determined to be successful.

[0110] S505: If the name of the fourth real-time message event is different from the name of the second real-time message event, then the second authentication operation is determined to have failed, and an interruption operation is performed.

[0111] In this embodiment, the middleware 1012 performs a consistency comparison between the fourth real-time message event name and the second real-time message event name. If the fourth real-time message event name is the same as the second real-time message event name, the middleware 1012 determines that the second authentication operation has passed. At this time, the proxy object forwards the second bus call request to the bus instance within the closure, completing the secure push of the response result data to the local server 1011.

[0112] In this embodiment, if the name of the fourth real-time message event is different from the name of the second real-time message event, the middleware 1012 determines that the second authentication operation has failed. At this time, an interrupt operation is immediately performed, refusing to forward the second bus call request to the bus instance within the closure, terminating the current call process, and triggering a platform security alarm to ensure that the bus instance cannot be accessed by unauthorized calls.

[0113] In this embodiment, after the second authentication operation is passed, the local server 1011 performs a reasonableness verification operation on the received response result data. The reasonableness verification operation is based on the user requirement parameters that the third-party client platform 102 has pre-synchronized to the local server. It compares the matching degree between the core fields in the response result data and the user requirement parameters. If the field content of the response result data completely matches the user requirement parameters, it can be determined that it is the result data that the user wants to see. The local server 1011 then completes the reasonableness verification operation, encrypts the response result data that has passed the reasonableness verification operation, and returns it to the third-party client platform 102 through the target communication protocol.

[0114] In this embodiment, for example, the local server 1011 extracts core fields such as patient identity identifier, examination item code, and report generation time from the response result data, and compares them one by one with user requirement parameters such as target patient identity information, requested examination item type, and report query time range synchronized with the third-party client platform 102. If the field content of the response result data completely matches the user requirement parameters, it can be determined that it is the result data that the user wants to see. The local server 1011 then completes the rationality verification operation, encrypts the verified response result data, and returns it to the third-party client platform 102.

[0115] It is worth noting that the multi-protocol communication system of the present invention has the following advantages:

[0116] (1) The local service platform has multiple built-in basic communication protocols to match with third-party customer platforms and achieve bidirectional data interaction with third-party customer platforms based on the pre-matched target communication protocol. There is no need to develop a complex protocol adaptation layer, which reduces the difficulty of connecting cross-protocol heterogeneous systems and the development investment, while simplifying the overall system architecture complexity.

[0117] (2) The introduction of two-factor authentication to prevent tampering and forgery is used to achieve secure authentication of access identity and to encrypt and protect transmitted data, thereby improving the security of data transmission. At the same time, combined with the authentication operation of the middleware, the validity of event names and data integrity of business response data and response result data are verified, which effectively prevents the risk of data being stolen, tampered or forged during transmission, reduces the risk of data leakage, and improves the security and reliability of the communication process.

[0118] (3) The local service platform builds a communication channel between the local server and the local client through middleware, opens up the data interaction link between the local server and the local client, reduces the intermediate links of data interaction, and improves the efficiency of data transmission and processing.

[0119] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with essentially the same function and purpose. For example, the first real-time message event name and the second real-time message event name are merely used to distinguish different real-time message event names and do not limit their order. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that terms such as "first" and "second" do not necessarily imply that they are different.

[0120] It should be noted that, in the embodiments of this application, the words "exemplary" or "for example" indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0121] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0122] Figure 6 This is a flowchart illustrating a multi-protocol communication method provided in an embodiment of this application. For example... Figure 6 As shown, this multi-protocol communication method is applied to a local service platform in a multi-protocol communication system as described above. The multi-protocol communication method includes:

[0123] S601: In response to a successful login signal from a third-party client platform, generate a dynamic two-factor feature token based on the login ID of the third-party client platform and a first preset combination rule.

[0124] S602: Return the dynamic two-factor feature token to the third-party client platform, so that the third-party client platform generates a request data packet based on the dynamic two-factor feature token and returns the request data packet to the local service platform.

[0125] S603: Based on the request data packet, perform a two-factor authentication operation, and after the two-factor authentication operation passes, perform business logic processing on the request data packet to generate business response data, and configure a corresponding first real-time message event name for the business response data.

[0126] S604: Based on the first real-time message event name, perform a first authentication operation, so that after the first authentication operation is successful, perform local processing on the business response data to generate response result data, and configure a corresponding second real-time message event name for the response result data.

[0127] S605: Based on the second real-time message event name, perform a second authentication operation, so that after the second authentication operation passes, perform a reasonableness verification operation on the response result data, and return the response result data that has passed the reasonableness verification operation to the third-party client platform.

[0128] It should be understood that the specific process of each module performing the above-mentioned corresponding steps has been described in detail in the above system embodiments, and will not be repeated here for the sake of brevity.

[0129] It should also be understood that the module division in the embodiments of this application is illustrative and only represents a logical functional division; in actual implementation, there may be other division methods. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0130] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the multi-protocol communication method described above.

[0131] As used in this specification, the terms "component," "module," "system," etc., are used to refer to computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. As illustrated, applications running on computing devices and computing devices can both be components. One or more components may reside in a process and / or an execution thread, and components may be located on a single computer and / or distributed among two or more computers. Furthermore, these components can be executed from various computer-readable media on which various data structures are stored. Components can communicate, for example, via local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, and / or a network, such as the Internet interacting with other systems via signals).

[0132] Those skilled in the art will recognize that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0133] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0135] The units described as separate components may or may not be physically separate. The components shown as units 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] In addition, the functional units in the various embodiments of this application 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.

[0137] In the above embodiments, the functions of each functional unit can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. A computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs, DVDs), or semiconductor media (e.g., solid-state disks, SSDs, etc.).

[0138] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0140] In summary, this application provides a multi-protocol communication system, method, and medium. The local service platform achieves bidirectional data interaction with third-party client platforms by incorporating multiple basic communication protocols, eliminating the need for developing additional protocol adaptation layers, reducing the difficulty and cost of interfacing with heterogeneous cross-protocol systems, and simplifying the system architecture. Simultaneously, it introduces two-factor authentication, data encryption protection, and middleware authentication operations to perform multi-layered verification of identity legitimacy and data integrity, effectively preventing the risk of data theft, tampering, or forgery, and improving communication security and reliability. Furthermore, it utilizes middleware to establish a communication channel between the local server and the local client, opening up internal data interaction links, reducing intermediate steps in data interaction, and improving data transmission and processing efficiency. Therefore, this application effectively overcomes the various shortcomings of existing technologies and has high industrial applicability.

[0141] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A communication system supporting multiple protocols, characterized in that, This includes creating a local service platform with multiple basic communication protocols and a third-party client platform in a pre-defined operating environment; The local service platform interacts bidirectionally with the third-party client platform based on a pre-matched target communication protocol, and the methods include: In response to a successful login signal from a third-party client platform, a dynamic two-factor feature token is generated based on the login ID of the third-party client platform and a first preset combination rule. The dynamic two-factor feature token is returned to the third-party client platform, so that the third-party client platform generates a request data packet based on the dynamic two-factor feature token and returns the request data packet to the local service platform; Based on the request data packet, a two-factor authentication operation is performed, and after the two-factor authentication operation passes, business logic processing is performed on the request data packet to generate business response data and configure the corresponding first real-time message event name for the business response data. Based on the first real-time message event name, a first authentication operation is performed, so that after the first authentication operation is passed, the business response data is processed locally to generate response result data, and a corresponding second real-time message event name is configured for the response result data; Based on the second real-time message event name, a second authentication operation is performed. After the second authentication operation passes, a reasonableness verification operation is performed on the response result data, and the response result data that passes the reasonableness verification operation is returned to the third-party client platform.

2. The multi-protocol communication system according to claim 1, characterized in that, The local service platform includes a local server, which, in response to a successful login signal from a third-party client platform, generates a dynamic two-factor feature token based on the login ID of the third-party client platform and a first preset combination rule. The method includes: Based on the login ID of the third-party customer platform and according to the first preset combination rule, the original key data is generated; According to a preset cryptographic algorithm, the original key data is subjected to a first encryption operation to generate a dynamic credential token; According to a preset hash algorithm, a second encryption operation is performed on the login ID of the third-party customer platform to generate a static credential token; Establish a mapping relationship between the dynamic credential token and the static credential token, and cache the mapping relationship between the dynamic credential token and the static credential token in a pre-built mapping table; A concatenation operation is performed on the dynamic credential token and the static credential token to generate a dynamic two-factor feature token.

3. The multi-protocol communication system according to claim 2, characterized in that, The local server is also used to perform a two-factor authentication operation based on the request data packet, the method of which includes: Extract the two-factor feature token to be verified from the request data packet, and perform a segmentation operation on the two-factor feature token to be verified to generate a dynamic token to be verified and a static token to be verified. Traverse and query the pre-built mapping table to lock the static credential token that matches the static token to be verified, and obtain the dynamic credential token that has a mapping relationship with the static credential token. Determine whether the dynamic token to be verified is the same as the dynamic credential token; If the dynamic token to be verified is the same as the dynamic credential token, then the two-factor verification operation is deemed to have passed. If the dynamic token to be verified is different from the dynamic credential token, the two-factor verification operation is determined to have failed, and an interrupt operation is performed.

4. The multi-protocol communication system according to claim 2, characterized in that, The local server is also used to generate a bus feature token according to a second preset combination rule, and to perform a third encryption operation on the first real-time message event name according to the bus feature token to generate a first encrypted message event name, and to encapsulate the first encrypted message event name with the business response data and then initiate a first bus call request.

5. The multi-protocol communication system according to claim 4, characterized in that, The local service platform further includes middleware, which is used to perform a first authentication operation based on the first real-time message event name, in the following manner: Intercept the first bus call request to extract the second encrypted message event name; A first decryption operation is performed on the second encrypted message event name based on the bus feature token to generate a third real-time message event name; Determine whether the name of the third real-time message event is the same as the name of the first real-time message event; If the name of the third real-time message event is the same as the name of the first real-time message event, then the first authentication operation is determined to be successful. If the name of the third real-time message event is different from the name of the first real-time message event, then the first authentication operation is determined to have failed, and an interruption operation is performed.

6. The multi-protocol communication system according to claim 4, characterized in that, The local service platform also includes a local client, which is used to perform local processing on the business response data, generate response result data, and configure a corresponding second real-time message event name for the response result data; Based on the bus feature token, a fourth encryption operation is performed on the second real-time message event name to generate a third encrypted message event name. The third encrypted message event name and the response result data are then encapsulated, and a second bus call request is initiated.

7. The multi-protocol communication system according to claim 6, characterized in that, The middleware is also used to perform a second authentication operation based on the second real-time message event name, the method of which includes: Intercept the second bus call request to extract the fourth encrypted message event name; A second decryption operation is performed on the fourth encrypted message event name based on the bus feature token to generate a fourth real-time message event name; Determine whether the name of the fourth real-time message event is the same as the name of the second real-time message event; If the name of the fourth real-time message event is the same as the name of the second real-time message event, then the second authentication operation is determined to be successful. If the name of the fourth real-time message event is different from the name of the second real-time message event, the second authentication operation is determined to have failed, and an interruption operation is performed.

8. The multi-protocol communication system according to claim 1, characterized in that, The matching methods for the target communication protocol include: Obtain the original communication protocols supported by the third-party client platform and determine the type of the original communication protocol; If the original communication protocol belongs to the first preset protocol type, then the original communication protocol is used as the target communication protocol. If the original communication protocol is of the second preset protocol type, then network indicator data and data volume identification data of the third-party customer platform are obtained to determine the target communication protocol; wherein, the network indicator data includes network latency data and network bandwidth data.

9. A communication method supporting multiple protocols, characterized in that, A local service platform applied in a multi-protocol communication system as described in any one of claims 1-8, wherein the multi-protocol communication method comprises: In response to a successful login signal from a third-party client platform, a dynamic two-factor feature token is generated based on the login ID of the third-party client platform and a first preset combination rule. The dynamic two-factor feature token is returned to the third-party client platform, so that the third-party client platform generates a request data packet based on the dynamic two-factor feature token and returns the request data packet to the local service platform; Based on the request data packet, a two-factor authentication operation is performed, and after the two-factor authentication operation passes, business logic processing is performed on the request data packet to generate business response data and configure the corresponding first real-time message event name for the business response data. Based on the first real-time message event name, a first authentication operation is performed, so that after the first authentication operation is passed, the business response data is processed locally to generate response result data, and a corresponding second real-time message event name is configured for the response result data; Based on the second real-time message event name, a second authentication operation is performed. After the second authentication operation passes, a reasonableness verification operation is performed on the response result data, and the response result data that passes the reasonableness verification operation is returned to the third-party client platform.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-protocol communication method as described in claim 9.

Images