Client-side and server-side communication system adaptive to multiple network protocols

Abstract

The invention provides a client-side and server-side communication system adaptive to multiple network protocols, and belongs to the technical field of computer communication, the system comprises client-side communication middleware, server-side communication middleware and a configuration management center, the client-side communication middleware runs on a Linux terminal, and the server-side communication middleware runs on a server-side terminal; the client communication middleware provides standardized local communication interfaces for all business applications of a local machine, and the client communication middleware is also in communication connection with the server communication middleware; the server-side communication middleware is deployed in a central machine room in a clustering manner, provides an RPC interface for back-end business service, and is also in communication connection with the client-side communication middleware; and the configuration management center is deployed in a central machine room, and provides a server API for defining a communication strategy, managing terminal equipment, issuing a configuration instruction, configuring an interface external calling permission and monitoring a full-link communication flow state in a centralized manner. According to the invention, a series of pain points caused by deep coupling of service logic and communication logic in the existing scheme are solved.

Description

Technical Field

[0001] This invention relates to client-server communication, and more particularly to a client-server communication system adapted to multiple network protocols, belonging to the field of computer communication technology. Background Technology

[0002] In current distributed systems and microservice architectures, client-server communication is an essential foundation. Traditional HTTPS communication interfaces cannot meet the needs of certain network scenarios, such as scenarios with special encryption requirements, or scenarios that must use TCP for communication.

[0003] With the development of the information technology innovation industry, especially in key areas such as finance, higher requirements have been placed on the security, controllability, and auditability of communications. Therefore, how to design a communication system that can flexibly adapt to multiple network protocols and meet the needs of unified governance has become an urgent technical problem to be solved in this field.

[0004] Existing client-server communication schemes have at least the following defects and shortcomings: 1. The protocol is highly coupled, resulting in high integration and maintenance costs. Client-side code is often deeply coupled with specific network communication protocols (such as HTTPS, TCP, WebSocket, etc.). Whenever the server introduces or upgrades a communication protocol, all related clients must be adapted, modified, and redeployed accordingly. This "case-by-case" adaptation approach leads to a significant increase in the workload of development, testing, and maintenance in cross-platform, multi-terminal application ecosystems, greatly increasing the overall cost of the project.

[0005] 2. Poor architectural flexibility, unable to dynamically adapt to network environments. Existing communication architectures lack a unified abstraction layer, meaning clients are fixed to using a particular protocol during initialization and cannot dynamically switch based on real-time network conditions, server policies, or security requirements. For example, in weak network environments, they cannot seamlessly downgrade from HTTPS to a more efficient private TCP protocol, or switch to a protocol with special encryption mechanisms when a higher level of security is required. This rigid design makes the system ill-suited for complex and ever-changing network application scenarios.

[0006] 3. Weak governance capabilities and lack of a unified management framework. Existing technological solutions lack overall oversight and control over communications, especially in industries such as finance, specifically manifested in the following ways: Traffic control is difficult: It is impossible to implement uniform bandwidth limits, flow control policies and priority scheduling for all application requests from the same client that use different protocols.

[0007] Security auditing is difficult because communication links are scattered, and logs and traffic data are difficult to collect and analyze centrally, which cannot meet the strong regulatory requirements of the financial and information technology innovation fields for traceable operations and auditable behavior.

[0008] Status monitoring is difficult: It is impossible to monitor the health status, performance indicators and abnormal conditions of all protocol channels in a real-time and unified manner, resulting in high operational complexity.

[0009] Low technology reusability and lack of common components: Due to the lack of effective abstraction and encapsulation of core communication logic (such as protocol encoding / decoding, connection management, and security authentication), the implementation code of different protocols is independent and repetitive. This results in a large number of "wheels" with similar functions but different implementations in the codebase, which not only reduces code reusability but also places a huge burden on subsequent upgrades and optimizations. Any modification to the underlying communication logic may need to be performed simultaneously in multiple protocol implementations, which can easily introduce errors and inconsistencies.

[0010] In summary, the existing solutions do have many shortcomings. Therefore, a communication layer abstraction framework that adapts to multiple network protocols and provides standard client and server interfaces is imperative. Summary of the Invention

[0011] To address the aforementioned issues, this invention provides a client-server communication system that adapts to multiple network protocols, enabling protocol adaptation, flexible management, and unified governance of client-server communication.

[0012] To achieve the above objectives, the technical solution of the present invention is: a client-server communication system adapted to multiple network protocols, the system comprising a client communication middleware and a server communication middleware for communication connections, wherein, The client communication middleware runs on a Linux terminal and provides a standardized local communication interface for all business applications on the local machine. The client communication middleware also provides a communication module for communication connection with the server communication middleware. The server-side communication middleware is deployed in a cluster in the central computer room, providing RPC interfaces for backend business services. The server-side communication middleware also provides a communication module to communicate with the client-side communication middleware. The server-side communication middleware includes a configuration management center that provides a server-side API for defining communication policies, managing terminal devices, issuing configuration commands, configuring external call permissions for interfaces, and centrally monitoring the status of the entire communication traffic during communication between the server-side and client-side communication middleware.

[0013] Furthermore, the local communication interfaces provided by the client communication middleware include Unix Socket, dbus, or local HTTP interfaces.

[0014] Furthermore, using the system to make client applications call server applications includes the following steps: The S1 client application initiates a request: When a business application on the client needs to call a remote service, it sends a request to the locally deployed client communication middleware. S2 client communication middleware receives application requests: The client communication middleware listens for and receives requests from application clients; S3 Client Communication Middleware Encapsulation and Encryption: The client communication middleware encapsulates the received application requests into a general message structure that is independent of specific network protocols, and encrypts the general message according to a preset security policy. S4 Policy Inspection and Protocol Transmission: Before sending, the client communication middleware queries the local configuration policy and performs application permission verification and traffic policy check. After the verification is successful, the client communication middleware selects a suitable network according to the current optimal policy and sends the encrypted request to the server communication middleware according to priority and permission rate limit through the corresponding network protocol. S5 server communication middleware receives and decrypts: After receiving the encrypted message from the client, the server-side communication middleware first performs a decryption operation to restore the general plaintext request message; S6 Service Addressing and Routing: The server-side communication middleware uses a specific identifier in the decrypted message to locate the corresponding application service and its access endpoint in the service registration and configuration management center. S7 requests are forwarded to the application service: The server-side communication middleware will forward the restored original request information to the target application service in the upper layer for processing through a standard internal communication mechanism. The S8 application service processes and returns a response: The target application service processes the received business request and returns the processing result to the server-side communication middleware. Then, the response will travel in the opposite direction, be encapsulated by the server-side communication middleware, decrypted by the client-side communication middleware, and finally returned to the initial application client.

[0015] Furthermore, step S4 includes permission verification and traffic policy checks, including checking whether the application has the right to access the server and whether it exceeds the traffic quota; network protocols include HTTPS and TCP.

[0016] Furthermore, using the system to proactively send instructions or data from the server application to the client application includes the following steps: S1 application service initiates a distribution request: Application services initiate requests to send instructions or data to specified clients through interfaces provided by server-side communication middleware; S2 server-side communication middleware interface receives requests: The interface layer of the server-side communication middleware receives and parses the requests sent from the application service; S3 server-side communication middleware encapsulation and encryption: The server-side communication middleware encapsulates the issued instructions or data into a general message structure that is independent of the protocol, and encrypts them according to the security policy. S4 commands are entered into the distribution queue: The server-side communication middleware places the encrypted message into the queue of instructions to be sent to the target terminal; S5 client communication middleware subscription and pull: The client communication middleware actively subscribes to or retrieves messages from the server through one or more network channels based on the configuration policy obtained from the server. S6 client communication middleware receives and decrypts: After receiving the message, the client communication middleware performs a decryption operation to restore the plaintext general message; S7 commands are routed to local applications: The client communication middleware locates the corresponding local application client interface based on the identifier carried in the general message, and forwards the decrypted instruction data to the corresponding application client interface. S8 application client processing commands: After receiving the instruction, the client's business application executes the corresponding business logic processing; S9 processing result reporting: After the application client finishes processing, it returns the processing result to the client communication middleware; the client communication middleware updates the result data to the local pending status queue, ready to send feedback to the server.

[0017] Furthermore, in step S5, the client actively subscribes to or retrieves messages from the server through the following mechanisms: HTTP polling, TCP long connection listening, or MQTT topic subscription.

[0018] Furthermore, using the system to periodically or quantitatively report status and command results to the server via client communication middleware includes the following steps: S1 Triggering Condition Judgment: The client communication middleware continuously monitors two conditions that trigger reporting. If either condition is met, the reporting process is immediately started. The conditions that trigger reporting include reaching a preset polling time and the local data to be reported accumulating to a preset threshold. S2 client communication middleware encapsulation and encryption: Once the triggering condition is met, the client communication middleware encapsulates the data to be reported in the queue into a general message structure and encrypts it; the data to be reported includes external command results and internal status and data; S3 strategic network transmission: The client communication middleware dynamically selects the most suitable network protocol based on the currently configured traffic policy and application priority permissions, and takes into account the real-time network conditions, and sends the encrypted reporting data to the server communication middleware. S4 server communication middleware receives and decrypts: After receiving the reported data, the server-side communication middleware performs a decryption operation to restore the plaintext message; S5 processes reports according to their type: The server-side communication middleware performs traffic splitting based on the reporting type identified in the message.

[0019] Furthermore, in step S2, the external instruction result refers to the application instruction actively sent by the server application to the client application, and the result that needs to be fed back after the client executes it; the internal status and data include the status data, synchronization configuration information or heartbeat data generated by the middleware itself during runtime.

[0020] Furthermore, when the reported type in step S5 is an external instruction result, the route is forwarded to the corresponding backend application service that originally issued the instruction, so as to complete the business loop of instruction issuance.

[0021] Furthermore, when the reporting type in step S5 is internal status and data, it is directly received and processed by a specific management module inside the server-side communication middleware for updating terminal configuration, synchronizing status, or performing system monitoring.

[0022] The beneficial effects of the client-server communication system adapted to multiple network protocols of the present invention are as follows: This invention addresses a series of pain points arising from the deep coupling of business logic and communication logic in existing solutions. By introducing a peer-to-peer terminal-server communication middleware architecture, this invention encapsulates complex, multi-protocol communication implementations into a standard, governable "communication service." Compared to existing technologies, this invention not only achieves complete decoupling of business development but, more importantly, provides a centralized management plane. This enables operations and maintenance personnel to implement unified policy distribution, traffic shaping, security auditing, and status monitoring for distributed terminals, thereby achieving standardization, security, and maintainability of communication in complex network environments (such as the financial information technology innovation field). Attached Figure Description

[0023] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0024] Figure 1 This is a system framework diagram of the present invention; Figure 2 This is a flowchart of an embodiment of the present invention; Figure 3 This is a flowchart of another embodiment of the present invention; Figure 4 This is a flowchart of another embodiment of the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0026] The present invention provides a client-server communication system adapted to multiple network protocols, which aims to solve the following specific technical problems: 1. Terminal business applications are tightly coupled with communication protocols: Business programs on terminals usually directly integrate specific communication libraries (such as HTTP clients and TCP sockets). This means that when protocols are switched, encryption methods are upgraded, or server addresses are changed, the business programs must be modified, recompiled, and re-deployed, resulting in extremely high maintenance costs when the number of terminals is large.

[0027] 2. Rigid communication links, unable to intelligently adapt to network changes: The communication protocol between the terminal and the server is usually statically specified during deployment and cannot be dynamically switched based on real-time network quality (such as bandwidth and latency), server load, or security policies. For example, it cannot automatically downgrade from HTTPS to the lighter UDP protocol when the Wi-Fi signal is weak, or force a switch to a custom encrypted TCP connection when high-security transmission is required.

[0028] 3. Lack of unified and two-way management capabilities for the terminal side: The existing architecture struggles to achieve centralized communication management for massive numbers of Linux terminals. Specifically: Configuration distribution is difficult: It is impossible to remotely and uniformly update the communication parameters (such as heartbeat interval, encryption key, protocol priority) of all terminals.

[0029] Difficulty in issuing proactive commands: The server lacks a standardized channel to proactively push commands, configuration files, or alarm information to the terminal.

[0030] Panoramic monitoring is difficult: It is impossible to centrally collect and audit the communication status, traffic data and security events of distributed terminals, making it difficult to meet the requirements of operation and maintenance supervision.

[0031] The basic communication capabilities cannot be reused: Each terminal business program needs to repeatedly implement the underlying logic such as connection management, heartbeat keep-alive, disconnection reconnection, and message serialization, resulting in a waste of development resources and a decrease in the overall stability of the system.

[0032] To address the aforementioned technical problems, this invention constructs a non-intrusive communication middleware system deployed on Linux terminals and servers. This system separates complex multi-protocol communication and governance capabilities from business applications, forming a unified communication enabling plane. The technical solution of this invention will be described in detail below with reference to the accompanying drawings.

[0033] Example 1 Combination Figure 1 As shown, a client-server communication system adapted to multiple network protocols according to the present invention includes a client communication middleware and a server communication middleware for communication connection, wherein, The client communication middleware (i.e., the terminal communication middleware) runs as an independent daemon process on the Linux terminal, serving all local business applications (corresponding to...). Figure 1 The application client in the application provides a standardized local communication interface (such as Unix Socket, dbus, or a local HTTP interface, corresponding to...) Figure 1 The client-side interface is provided by the client communication middleware, which also provides a communication module for communication with the server-side communication middleware. The server-side communication middleware is deployed in a cluster in the central data center, providing services to the backend business (corresponding to...). Figure 1 The application service provides a high-performance RPC interface (corresponding to...). Figure 1 The server-side interface establishes and maintains multiple network protocol connections with a large number of client communication middlewares. In other words, the server-side communication middleware also provides communication modules to communicate with client communication middlewares. The server-side communication middleware includes a configuration management center, which acts as the "brain" of the system. It provides server-side APIs for defining communication policies, managing terminal devices, issuing configuration commands, configuring external call permissions for interfaces, and centrally monitoring the status of the entire communication traffic during communication between the server-side and client-side communication middleware.

[0034] The client communication middleware and server communication middleware encapsulate the communication layer logic for the connected applications. The client application does not need to care about the communication with the server or know the server's address information. It only needs to communicate with the external interface of the client communication middleware to call the application service. The client communication middleware uses the communication module combined with the current terminal application's communication strategy and communication channel to securely send messages to the server communication middleware. At this time, the server communication middleware will find the corresponding configured application service through the message, forward the request to the application service, and return the result along the original request route after obtaining the result.

[0035] The core workflow of the system of this invention includes the following: Business request uplink: Business applications on the terminal do not need to be aware of network details; they only need to send requests to the external interface provided by the local client communication middleware. After receiving the request, the client communication middleware automatically selects the optimal network protocol (such as HTTPS, MQTT, or private TCP protocol) based on the dynamic policy obtained from the configuration management center, completes the encapsulation and encryption of the message, and then sends it at a rate limited according to the traffic configuration policy.

[0036] Requesting server-side routing: After receiving the terminal request, the server-side communication middleware decrypts, unpacks, and converts the protocol, and then delivers the request to the corresponding backend business service for processing through standard RPC calls.

[0037] Downlink commands from the server: Backend business services or administrators can send commands, configuration updates, or custom messages to individual or batches of terminals through the configuration management center or by directly calling the API of the server-side communication middleware. The server-side communication middleware pushes information to the target client-side communication middleware through an active connection channel, and the latter then passes it to the specified business application through its local external interface.

[0038] The entire communication process described above, including protocol selection, connection keep-alive, failover, encryption and decryption, is automatically completed by the middleware system, completely transparent to the business programs at both ends. The configuration management center then implements unified monitoring, auditing, flow control, and security policies for application traffic accessing the middleware.

[0039] Through the above design, this invention realizes the service-oriented, standardized and intelligent nature of terminal communication capabilities, and completely decouples business logic and communication logic.

[0040] Example 2 This embodiment combines Figure 2 As shown, the complete steps of using the system of this invention to call a server application are described in detail. This process begins with the client application initiating a request and ends when the server-side communication middleware routes the request to the target application service. The specific steps are as follows: (1) The client application initiates a request When a business application on the client (hereinafter referred to as "application client") needs to call a remote service, it no longer makes a direct network call, but instead sends a request to the locally deployed client communication middleware.

[0041] (2) The client communication middleware receives application requests. The client-side communication middleware listens for and receives requests from application clients. This step achieves an initial separation between business logic and network communication logic.

[0042] (3) Client communication middleware encapsulation and encryption The client communication middleware encapsulates received application requests into a generic message structure independent of specific network protocols. Subsequently, it encrypts this generic message according to a preset security policy to ensure secure data transmission.

[0043] (4) Policy check and protocol transmission Before sending, the client communication middleware queries the local configuration policy (i.e., the dynamic policy obtained from the configuration management center in Example 1) to perform application permission verification and traffic policy checks (e.g., checking whether the application has the right to access the server and whether it exceeds the traffic quota). After the verification is successful, the client communication middleware selects a suitable network according to the current optimal policy and sends the encrypted request to the server communication middleware according to priority and permission rate limits through the corresponding network protocol (such as HTTPS, TCP, etc.). (5) The server communication middleware receives and decrypts After receiving an encrypted message from the client, the server-side communication middleware first performs a decryption operation to restore the general plaintext request message.

[0044] (6) Service addressing and routing The server-side communication middleware uses a specific identifier in the decrypted message to locate the corresponding application service and its access endpoint in the service registration and configuration management center.

[0045] (7) Request to forward to application service The server-side communication middleware forwards the restored original request information to the target application service at the upper layer for processing through standard internal communication mechanisms (such as RPC calls).

[0046] (8) The application service processes and returns a response. The target application service processes the received business request and returns the processing result to the server-side communication middleware. Subsequently, the response will follow the reverse path, being encapsulated by the server-side communication middleware and decrypted by the client-side communication middleware, before finally being returned to the initial application client. (Note: The response return process is the reverse of this process and is not fully shown in the diagram.)

[0047] Example 3 This embodiment combines Figure 3 The diagram illustrates the complete process of a server-side application actively sending instructions or data to a client-side application using the system of this invention. This process demonstrates the system's bidirectional communication and centralized management capabilities. The specific steps are as follows: (1) The application service initiates a distribution request The server-side business application (hereinafter referred to as "application service") initiates a request to send instructions or data to a specified client through the interface (such as RPC API) provided by the server-side communication middleware.

[0048] (2) The server-side communication middleware interface receives requests. The interface layer of the server-side communication middleware receives and parses the requests sent from the application service.

[0049] (3) Encapsulation and encryption of server-side communication middleware The server-side communication middleware encapsulates the issued instructions or data into a general message structure that is independent of the protocol, and encrypts them according to the security policy.

[0050] (4) The instruction enters the distribution queue. The server-side communication middleware places the encrypted message into a queue of instructions to be sent to the target terminal. This queued management enables the buffering, sorting, and asynchronous transmission of instructions, ensuring the stability and reliability of the system.

[0051] (5) Client communication middleware subscription and pull The client communication middleware actively subscribes to or retrieves messages from the server through one or more network channels based on its configuration strategy obtained from the server. Supported mechanisms include, but are not limited to: HTTP polling, TCP long connection listening, or MQTT topic subscription. When there are instructions waiting to be issued in the server queue, the client communication middleware will receive a notification or directly obtain encrypted messages through the communication channel.

[0052] (6) The client communication middleware receives and decrypts the data. After receiving the message, the client communication middleware performs a decryption operation to restore the plaintext general message.

[0053] (7) Command routing to local application The client communication middleware locates the corresponding local application client interface based on the identifier carried in the message, and forwards the decrypted instruction data to the corresponding application client interface.

[0054] (8) Application client processing instructions After receiving the instruction, the client's business application executes the corresponding business logic processing.

[0055] (9) Reporting of processing results After the application client completes processing, it returns the processing result to the client communication middleware. The client communication middleware updates the result data to its local status queue, preparing to send feedback to the server. The local status queue will be discussed in the following embodiments and... Figure 4 As described in the text.

[0056] Example 4 This embodiment combines Figure 4 As shown, the process of using the system of this invention to periodically or quantitatively report status and command results to the server via client communication middleware is described in detail. This process, through an intelligent dual-trigger mechanism, balances the real-time nature of data reporting with the efficiency of network transmission. The specific steps are as follows: (1) Triggering condition judgment The client communication middleware continuously monitors two conditions that trigger reporting; if either condition is met, the reporting process is immediately initiated: Condition 1 (Time-driven): The preset polling time is reached (e.g., every 1 minute).

[0057] Condition 2 (Event-driven): The local data to be reported accumulates to a preset threshold (e.g., reaching 10 instruction results or status updates).

[0058] The two conditions are related by "OR". Whichever condition is met first will trigger the reporting, thereby achieving the best balance between latency and load.

[0059] (2) Client communication middleware encapsulation and encryption Once the triggering condition is met, the client communication middleware encapsulates the data to be reported in the queue into a general message structure and encrypts it. The reported data is mainly divided into two categories: Category 1: Results of external instructions. That is, results from... Figure 3 The application instructions issued in the process require feedback after execution on the client side.

[0060] The second category: Internal state and data. This refers to the state data, synchronization configuration information, or heartbeat data generated by the middleware itself during runtime.

[0061] (3) Strategic network transmission The client communication middleware dynamically selects the most suitable network protocol based on the currently configured traffic policy and application priority permissions, and takes into account the real-time network conditions, and sends the encrypted reporting data to the server communication middleware.

[0062] (4) The server-side communication middleware receives and decrypts the data. After receiving the reported data, the server-side communication middleware performs a decryption operation to restore the plaintext message.

[0063] (5) Classify and process according to the reporting type The server-side communication middleware performs traffic routing based on the reporting type identified in the message: If it is an "external command result", then it will be routed and forwarded to the corresponding backend application service that originally issued the command, so as to complete the business loop of command issuance.

[0064] If it is "internal status and data", it is directly received and processed by a specific management module inside the server-side communication middleware. It is used to update terminal configuration, synchronize status, or perform system monitoring. This type of data does not involve upper-layer business applications.

[0065] In summary, this invention constructs a non-intrusive client-server communication framework that adapts to multiple network protocols. Specifically, it has the following technical features: 1. The system architecture of this invention is a distributed system architecture composed of client communication middleware, server communication middleware, and configuration management and governance center. 2. This invention implements a multi-protocol dynamic adaptation mechanism. Specifically, this invention implements a multi-network protocol dynamic adaptation mechanism implemented by middleware that is transparent to the business. The protocol adapter component built into the client communication middleware can support the implementation and management of multiple network protocols such as HTTPS, TCP, and WebSocket. This invention also implements a dynamic protocol selection mechanism based on the policy factory pattern. Specifically, the client communication middleware dynamically selects or switches the current optimal network protocol to establish a connection by querying / receiving policy configuration files from the configuration governance center and combining real-time network status detection (such as latency and bandwidth). The entire process is transparent to upper-layer business applications.

[0066] 3. This invention possesses unified communication and governance capabilities, implementing unified communication abstraction and governance functions at the middleware level. Before transmission, the client and server middleware encapsulate business data in a message structure independent of specific protocols and perform unified encryption, achieving standardization of communication messages. The server can proactively send configuration instructions, control commands, or custom messages to designated client communication middleware through the API provided by the server-side communication middleware; after receiving these, the client communication middleware can route them to local business applications or execute them directly, thereby enabling proactive management of clients by the server; the centralized governance functions include, but are not limited to: unified traffic control policies based on clients, permission verification based on application identifiers, collection and auditing of end-to-end communication logs, and real-time monitoring of the health status of all protocol channels.

[0067] 4. This invention features reusable components and autonomous capabilities. To achieve the aforementioned functions, highly reusable core components and the system's autonomous capabilities are abstracted. The abstracted and encapsulated reusable component library includes, but is not limited to: protocol codecs, connection managers, heartbeat keep-alive modules, and disconnection reconnection devices. These components are shared by the client and server middleware to ensure consistent behavior. The client communication middleware can automatically initiate the reporting process based on the first of two conditions: a fixed period or a backlog threshold of data to be reported (such as "every minute" or "10 data entries accumulated"). It encrypts and reports the command execution results or internal status data, demonstrating the system's autonomy and reliability.

[0068] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A client-server communication system adaptable to multiple network protocols, characterized in that, The system includes client-side communication middleware and server-side communication middleware for communication connections, wherein... The client communication middleware runs on a Linux terminal and provides a standardized local communication interface for all business applications on the local machine. The client communication middleware also provides a communication module for communication connection with the server communication middleware. The server-side communication middleware is deployed in a cluster in the central computer room, providing RPC interfaces for backend business services. The server-side communication middleware also provides a communication module to communicate with the client-side communication middleware. The server-side communication middleware includes a configuration management center that provides a server-side API for defining communication policies, managing terminal devices, issuing configuration commands, configuring external call permissions for interfaces, and centrally monitoring the status of the entire communication traffic during communication between the server-side and client-side communication middleware.

2. The system according to claim 1, characterized in that, The local communication interfaces provided by the client communication middleware include Unix Socket, dbus, or local HTTP interfaces.

3. The system according to claim 1 or 2, characterized in that, Using the system to make client applications call server applications includes the following steps: The S1 client application initiates a request: When a business application on the client needs to call a remote service, it sends a request to the locally deployed client communication middleware. S2 client communication middleware receives application requests: The client communication middleware listens for and receives requests from application clients; S3 Client Communication Middleware Encapsulation and Encryption: The client communication middleware encapsulates the received application requests into a general message structure that is independent of specific network protocols, and encrypts the general message according to a preset security policy. S4 Policy Inspection and Protocol Transmission: Before sending, the client communication middleware queries the local configuration policy and performs application permission verification and traffic policy check. After the verification is successful, the client communication middleware selects a suitable network according to the current optimal policy and sends the encrypted request to the server communication middleware according to priority and permission rate limit through the corresponding network protocol. S5 server communication middleware receives and decrypts: After receiving the encrypted message from the client, the server-side communication middleware first performs a decryption operation to restore the general plaintext request message; S6 Service Addressing and Routing: The server-side communication middleware uses a specific identifier in the decrypted message to locate the corresponding application service and its access endpoint in the service registration and configuration management center. S7 requests are forwarded to the application service: The server-side communication middleware will forward the restored original request information to the target application service in the upper layer for processing through a standard internal communication mechanism. The S8 application service processes and returns a response: The target application service processes the received business request and returns the processing result to the server-side communication middleware. Then, the response will travel in the opposite direction, be encapsulated by the server-side communication middleware, decrypted by the client-side communication middleware, and finally returned to the initial application client.

4. The system according to claim 3, characterized in that, Step S4 includes permission verification and traffic policy checks, including checking whether the application has the right to access the server and whether it exceeds the traffic quota; network protocols include HTTPS and TCP.

5. The system according to claim 1 or 2, characterized in that, Using the system to proactively send instructions or data from a server application to a client application includes the following steps: S1 application service initiates a distribution request: Application services initiate requests to send instructions or data to specified clients through interfaces provided by server-side communication middleware; S2 server-side communication middleware interface receives requests: The interface layer of the server-side communication middleware receives and parses the requests sent from the application service; S3 server-side communication middleware encapsulation and encryption: The server-side communication middleware encapsulates the issued instructions or data into a general message structure that is independent of the protocol, and encrypts them according to the security policy. S4 commands are entered into the distribution queue: The server-side communication middleware places the encrypted message into the queue of instructions to be sent to the target terminal; S5 client communication middleware subscription and pull: The client communication middleware actively subscribes to or retrieves messages from the server through one or more network channels based on the configuration policy obtained from the server. S6 client communication middleware receives and decrypts: After receiving the message, the client communication middleware performs a decryption operation to restore the plaintext general message; S7 commands are routed to local applications: The client communication middleware locates the corresponding local application client interface based on the identifier carried in the general message, and forwards the decrypted instruction data to the corresponding application client interface. S8 application client processing commands: After receiving the instruction, the client's business application executes the corresponding business logic processing; S9 processing result reporting: After the application client finishes processing, it returns the processing result to the client communication middleware; the client communication middleware updates the result data to the local pending status queue, ready to send feedback to the server.

6. The system according to claim 5, characterized in that, Step S5: The client actively subscribes to or pulls messages from the server through the following mechanisms: HTTP polling, TCP long connection listening, or MQTT topic subscription.

7. The system according to claim 1 or 2, characterized in that, The system enables client-side communication middleware to periodically or quantitatively report status and command results to the server, including the following steps: S1 Triggering Condition Judgment: The client communication middleware continuously monitors two conditions that trigger reporting. If either condition is met, the reporting process is immediately started. The conditions that trigger reporting include reaching a preset polling time and the local data to be reported accumulating to a preset threshold. S2 client communication middleware encapsulation and encryption: Once the triggering condition is met, the client communication middleware encapsulates the data to be reported in the queue into a general message structure and encrypts it; the data to be reported includes external command results and internal status and data; S3 strategic network transmission: The client communication middleware dynamically selects the most suitable network protocol based on the currently configured traffic policy and application priority permissions, and takes into account the real-time network conditions, and sends the encrypted reporting data to the server communication middleware. S4 server communication middleware receives and decrypts: After receiving the reported data, the server-side communication middleware performs a decryption operation to restore the plaintext message; S5 processes reports according to their type: The server-side communication middleware performs traffic splitting based on the reporting type identified in the message.

8. The system according to claim 7, characterized in that, In step S2, the external command result refers to the application command actively sent by the server application to the client application, and the result that needs to be fed back after the client executes it; the internal status and data include the status data, synchronization configuration information or heartbeat data generated by the middleware itself during runtime.

9. The system according to claim 7, characterized in that, When the reported type in step S5 is an external instruction result, the route is forwarded to the corresponding backend application service that originally issued the instruction, so as to complete the business loop of instruction issuance.

10. The system according to claim 7, characterized in that, When the reported type in step S5 is internal status and data, it is directly received and processed by a specific management module inside the server-side communication middleware for updating terminal configuration, synchronizing status, or performing system monitoring.

Images