Command line interaction system and method for private network protocol

Abstract

The invention discloses a CLI interaction system and method for a private network protocol. The system comprises a CLI server embedded into a background main service process and an independent CLI client, and the CLI server and the independent CLI client carry out local inter-process communication through Unix domain sockets. And the CLI server adopts an I / O multiplexing-based concurrent model, monitors connection and data arrival through a main monitoring thread, and pushes a task to a working thread pool for execution. And the CLI client adopts a non-blocking model in which an input thread and a receiving thread are separated to realize parallel processing of user command input and server message receiving. The client side is provided with an instruction analysis module, and the instruction analysis module converts a command character string input by a user into predefined binary structured command data to be transmitted. The method effectively solves the problems that a private protocol tool chain is missing, interaction is blocked, the concurrency performance of a server side is low, a user is prone to errors, error positioning is difficult, connection is fragile, and real-time event notification is lacked.

Description

Technical Field

[0001] This invention relates to the fields of network device management and embedded system debugging technology, and in particular to a command-line interactive system and method for a private network protocol. Background Technology

[0002] Command-line interactive tools are indispensable components for developers and operations personnel in the management and debugging of network devices and embedded systems. The background service handles the core business logic, while the CLI tool provides a user interface for configuring, controlling, and monitoring that service.

[0003] However, existing general-purpose CLI tools have many technical shortcomings in practical applications, especially when dealing with self-developed proprietary network protocols, as follows: Tight Coupling and Missing Protocols: Existing general-purpose network management tools (such as wpa_cli or hostapd_cli) are deeply bound to standard public protocols (such as WPA / WPA2 / WPA3). When backend services use self-developed protocols with unique mechanisms and private message formats (such as the WIAFA protocol), these standard tools are completely incompatible due to architecture and command set incompatibility, resulting in a serious "toolchain missing" problem. This leaves developers and operations personnel without effective means of interaction to manage and debug services based on proprietary protocols.

[0004] Interactive blocking: Traditional CLI clients typically employ a synchronous blocking model of "read-send-wait-receive-display". This results in the user interface being completely blocked while the client is waiting for a server response, preventing the user from entering new commands. More importantly, when the server has asynchronous events (such as state changes) that need to be actively pushed, the client, being in a blocked waiting state, cannot receive and display these events in a timely manner, leading to a poor user experience and making real-time monitoring impossible.

[0005] Low server-side concurrency performance: Some simple CLI servers use a single-threaded event loop to handle client requests. If a client's command requires a time-consuming operation (such as a complex device scan or large-scale data statistics), the entire server process will be blocked. During this time, the server cannot respond to new connection requests from other clients or other commands from already connected clients, severely limiting the system's concurrency capabilities and availability.

[0006] High user error susceptibility: Most existing general-purpose CLI tools do not provide context-aware command completion. Users must memorize all complex command and parameter names completely and accurately. This not only reduces operational efficiency but also makes command execution prone to failure due to spelling errors or incorrect parameter order, increasing the learning curve and barrier to entry.

[0007] Error localization is difficult: When command execution fails, traditional tools often only return a generic, vague error code (such as "FAIL" or "Invalidargument"). This lack of contextual feedback cannot help users accurately pinpoint the root cause of the problem (e.g., whether it is an incorrect parameter type, an out-of-bounds parameter value, insufficient resources, or an internal logic conflict), greatly increasing the difficulty and time cost of debugging.

[0008] Connection vulnerability: During debugging, background services may restart due to configuration updates, encountering critical errors, or performing routine maintenance. Traditional CLI clients typically exit the process immediately upon detecting a disconnection from the server. Users must manually reopen the terminal, launch the CLI tool, and re-establish the connection, which severely impacts work efficiency and continuity in scenarios requiring frequent debugging and testing.

[0009] Lack of real-time event notification mechanism: Limited by the single-threaded blocking model, existing CLI tools struggle to handle server-initiated communication. If significant state changes occur in the background service (such as device disconnection, sudden signal strength changes, system alarms, etc.), the server cannot proactively and in real-time push these events to the client and display them to the user. Users can only obtain the latest system status by periodically executing query commands, resulting in severe delays in status updates and failing to meet the needs of real-time monitoring.

[0010] In summary, there is an urgent need in this field for a CLI interaction solution that can adapt to proprietary protocols, has high concurrency, non-blocking interaction, high availability, and is user-friendly. Summary of the Invention

[0011] The main objective of this invention is to overcome the shortcomings of existing technologies and provide a high-performance, non-blocking, highly robust CLI interactive system and method specifically designed for proprietary protocols. This invention aims to systematically solve the seven major problems mentioned in the background section, providing a complete and efficient interactive management and debugging toolchain for backend services using proprietary network protocols.

[0012] To address the aforementioned technical problems, embodiments of the present invention provide the following technical solution: a CLI interaction system for a private network protocol, comprising: The CLI server is embedded as a server-side component into the background main business process that uses a private network protocol. The CLI client, as a standalone executable application, is available for users to launch to interact with the CLI server; The CLI server and the CLI client establish a local inter-process communication connection through a Unix domain socket. The CLI server is configured to use a concurrent model based on I / O multiplexing to handle the connections and requests of multiple CLI clients in a non-blocking manner. The CLI client is configured to use a non-blocking model that separates the input thread and the receiving thread to achieve parallel processing of user command input and server message reception.

[0013] Furthermore, the CLI server includes: The initialization module is used to create and bind Unix domain sockets according to configuration parameters and initialize the server runtime context; The main listening thread runs an I / O multiplexing mechanism to listen for client connection requests and data arrival events from connected clients. When a new connection request is received, the connection is accepted and the new client socket is added to the monitoring. When data arrives, the data is read, encapsulated into task units, and pushed to the concurrent task queue. The worker thread pool consists of multiple pre-created worker threads, which are used to continuously monitor the concurrent task queue, retrieve tasks from the queue and execute them. The execution includes: parsing the structured command data sent by the client, finding and executing the corresponding business logic processing function, and replying the execution result to the client through the client socket.

[0014] Furthermore, the CLI client includes: The connection management module is used to initialize the client context according to the configuration information and attempt to connect to the Unix domain socket specified by the CLI server. The sending thread is dedicated to handling user interaction input, providing a user prompt that supports history and command completion; it is used to identify the user input command, and if it is a local internal instruction on the client, it is processed locally; otherwise, the instruction parsing module is called to convert the user input string into a predefined binary structured command format and send it to the CLI server through a socket. The receiving thread is dedicated to receiving data and uses an I / O multiplexing mechanism to block and wait for readable events on the socket. It is used to read data sent by the CLI server, including responses to commands or asynchronous status updates actively pushed by the server, and displays them to the user terminal in real time.

[0015] Furthermore, the CLI client also includes an automatic reconnection module after disconnection; The receiving thread is further configured to: when monitoring I / O, if a connection interruption is detected, close the local socket and set a global "not connected" status flag; The sending thread is further configured to: check the "not connected" status flag before preparing to send command data; if the flag indicates "not connected", automatically trigger reconnection logic to attempt to reconnect to the CLI server; if the reconnection is successful, clear the "not connected" status flag and send the command entered by the user.

[0016] Furthermore, the system also includes an instruction parsing module, which is integrated into the sending thread of the CLI client; The instruction parsing module is used to parse the raw command string input by the user and encapsulate it into binary structured command data for transmission; The binary structured command data includes at least a command frame structure, which contains a command name field, a parameter number field, and a variable-length parameter list area. The parameter list area is filled with multiple command parameter structures, each of which contains a parameter name field, a parameter data type field, and a parameter value field.

[0017] Furthermore, the instruction parsing module is configured to perform parsing as follows: Split the user input string to identify the command name and parameters; Query the internally predefined command definition table to support the parsing of named parameters and positional parameters; Based on the parameter data types defined in the command definition table, convert the text-formatted parameter values ​​into the corresponding binary data types; Data is filled and encapsulated according to the format of the command frame structure and command parameter structure, and the total length is calculated.

[0018] Furthermore, the user prompt provided by the sending thread supports intelligent command completion. By querying the internal command definition table, it provides possible command or parameter completion options based on the partial characters already entered by the user, thereby reducing the user's memory burden and input error rate.

[0019] Furthermore, when executing business logic, the worker threads in the worker thread pool are configured to generate and return descriptive information containing specific error reasons, rather than general error codes, when command execution fails, in order to help users accurately locate the problem.

[0020] This invention also proposes a CLI interaction method for a private network protocol, based on the above system implementation, the method comprising: Server initialization steps: The CLI server initializes in the main business process, creates and binds Unix domain sockets, and starts the main listening thread to listen for connections; Client connection steps: The CLI client starts and connects to the Unix domain socket that the CLI server is listening on. After a successful connection, the sending thread and the receiving thread are started. Command input and sending steps: The CLI client's sending thread receives the command input by the user. If it is not an internal instruction, it is parsed into binary structured command data and sent to the CLI server through a socket. Command reception and processing steps: When the CLI server's main listening thread detects the arrival of client data, it reads and encapsulates it into a task and pushes it into the task queue; the worker thread retrieves the task from the queue, parses the command, and executes the corresponding business logic. Result return and display steps: The CLI server's worker thread sends the command execution result back to the CLI client; the CLI client's receiving thread receives and displays the result to the user terminal in real time.

[0021] Furthermore, the method also includes asynchronous event processing and disconnection reconnection steps: Asynchronous event handling: If a state change event that requires active notification to the client is generated during the execution of business logic by the CLI server, the event data is actively pushed through the client's socket; the CLI client's receiving thread listens for and receives the event data in real time and immediately displays it to the user, realizing non-blocking real-time state monitoring; Disconnection and reconnection: When the CLI client's receiving thread detects that the server connection has been lost, it sets a disconnection flag; the sending thread checks this flag before sending commands, and if it is in a disconnection state, it automatically attempts to reconnect to the server. After a successful reconnection, it continues to send commands.

[0022] The beneficial effects of the above-mentioned technical solution of the present invention are as follows: 1. Solved the problem of missing toolchains for private protocols: Through a self-developed C / S architecture and a custom structured command protocol, this invention provides native support for private protocols such as WIAFA, perfectly solving the problem that standard tools cannot be adapted due to protocol incompatibility, and providing dedicated tools for the development and debugging of private protocol services.

[0023] 2. Extremely high system responsiveness and concurrency: The server-side "I / O and logic decoupling" model, through the collaboration of the main listening thread and the worker thread pool, ensures that time-consuming commands from a single client will not block the server's response to requests from other clients, greatly improving the server's throughput and concurrent processing capabilities. The client-side "input / output thread separation" model ensures that user input and message reception do not interfere with each other. Users can enter new commands at any time and receive asynchronous events at any time, achieving a truly non-blocking and smooth interactive experience.

[0024] 3. Excellent user-friendliness and debugging efficiency: The implemented intelligent tab completion function and command history management greatly reduce the user's memory burden and input error rate, improving operational efficiency. Detailed, context-sensitive error messages returned by the server enable developers to quickly understand the root cause of problems, significantly shortening the debugging cycle.

[0025] 4. High robustness and connection retention: The client's automatic reconnection mechanism ensures that even if the background service restarts frequently for various reasons during debugging, the client can automatically and silently restore the connection. Users can hardly perceive the service interruption, providing a seamless and continuous debugging experience and greatly improving operation and maintenance and development efficiency.

[0026] 5. High-efficiency data transmission and low system overhead: Local communication using Unix domain sockets avoids the processing overhead of the network protocol stack. More importantly, commands are pre-parsed into compact binary structures on the client side before transmission, which significantly reduces the amount of data transmitted and greatly reduces the CPU computational load required for the server to parse command strings, making the overall system operation more efficient.

[0027] 6. Provides real-time status monitoring capabilities: Thanks to the independent design of the client's receiving thread, the client can independently and in real-time listen to and display any messages from the server. This enables the CLI tool of this invention to immediately receive and display asynchronous events (such as status updates, alarms, etc.) actively pushed by the server, even if the user is currently entering commands or not performing any operations. This provides users with real-time status feedback capabilities that are unmatched by traditional single-threaded blocking CLI tools, greatly improving the efficiency of system monitoring and troubleshooting. Attached Figure Description

[0028] Figure 1 This is a flowchart of the event loop processing on the server side.

[0029] Figure 2 Flowchart for server-side task queue distribution and thread pool collaboration.

[0030] Figure 3 A flowchart illustrating the client-side disconnection detection mechanism and automatic reconnection process. Detailed Implementation

[0031] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0032] Example 1

[0033] A CLI interaction system for a proprietary network protocol includes: The CLI server is embedded as a server-side component into the background main business process that uses a private network protocol. The CLI client, as a standalone executable application, is launched by the user to interact with the CLI server; The CLI server and CLI client establish a local inter-process communication connection via Unix domain sockets; The CLI server is configured to use a concurrent model based on I / O multiplexing to handle multiple CLI client connections and requests in a non-blocking manner; The CLI client is configured to use a non-blocking model that separates the input thread and the receiving thread to achieve parallel processing of user command input and server message reception.

[0034] In this embodiment, the CLI server includes: The initialization module is used to create and bind Unix domain sockets according to configuration parameters and initialize the server runtime context; The main listening thread runs an I / O multiplexing mechanism to listen for client connection requests and data arrival events from connected clients. When a new connection request is received, the connection is accepted and the new client socket is added to the monitoring. When data arrives, the data is read, encapsulated into task units, and pushed to the concurrent task queue. The worker thread pool consists of multiple pre-created worker threads, which are used to continuously monitor the concurrent task queue, retrieve tasks from the queue and execute them. The execution includes: parsing the structured command data sent by the client, finding and executing the corresponding business logic processing function, and replying the execution result to the client through the client socket.

[0035] In this embodiment, the CLI client includes: The connection management module is used to initialize the client context based on the configuration information and attempt to connect to the Unix domain socket specified by the CLI server. The sending thread is dedicated to handling user interaction input, providing a user prompt that supports history and command completion; it is used to identify the user input command, and if it is a local internal command on the client, it is processed locally; otherwise, the command parsing module is called to convert the user input string into a predefined binary structured command format and send it to the CLI server through a socket. The receiving thread is dedicated to receiving data and uses an I / O multiplexing mechanism to block and wait for readable events on the socket. It is used to read data sent by the CLI server, including responses to commands or asynchronous status updates actively pushed by the server, and displays them to the user terminal in real time.

[0036] In this embodiment, the CLI client also includes an automatic reconnection module after disconnection; The receiving thread is further configured to: when monitoring I / O, if a connection interruption is detected, close the local socket and set a global "not connected" status flag; The sending thread is further configured to: check the "not connected" status flag before preparing to send command data; if the flag indicates "not connected", automatically trigger the reconnection logic and attempt to reconnect to the CLI server; if the reconnection is successful, clear the "not connected" status flag and send the command entered by the user.

[0037] In this embodiment, the system also includes an instruction parsing module, which is integrated into the sending thread of the CLI client; The instruction parsing module is used to parse the raw command string input by the user and encapsulate it into binary structured command data for transmission; Binary structured command data includes at least a command frame structure, which contains a command name field, a parameter number field, and a variable-length parameter list area. The parameter list area is filled with multiple command parameter structures, each of which contains a parameter name field, a parameter data type field, and a parameter value field.

[0038] In this embodiment, the instruction parsing module is configured to perform parsing as follows: Split the user input string to identify the command name and parameters; Query the internally predefined command definition table to support the parsing of named parameters and positional parameters; Based on the parameter data types defined in the command definition table, convert the text-formatted parameter values ​​into their corresponding binary data types; Data is filled and encapsulated according to the format of the command frame structure and command parameter structure, and the total length is calculated.

[0039] In this embodiment, the user prompt provided by the sending thread supports intelligent command completion. By querying the internal command definition table, it provides possible command or parameter completion options based on the partial characters already entered by the user, thereby reducing the user's memory burden and input error rate.

[0040] In this embodiment, when the worker threads in the worker thread pool execute business logic, they are configured to generate and return descriptive information containing specific error reasons, rather than general error codes, when the command execution fails, in order to help users accurately locate the problem.

[0041] This invention also proposes a CLI interaction method for a private network protocol, based on the above system implementation, the method comprising: Server initialization steps: The CLI server initializes in the main business process, creates and binds Unix domain sockets, and starts the main listening thread to listen for connections; Client connection steps: The CLI client starts and connects to the Unix domain socket that the CLI server is listening on. After a successful connection, the sending thread and the receiving thread are started. Command input and sending steps: The CLI client's sending thread receives the command input by the user. If it is not an internal instruction, it is parsed into binary structured command data and sent to the CLI server through a socket. Command reception and processing steps: When the CLI server's main listening thread detects the arrival of client data, it reads and encapsulates it into a task and pushes it into the task queue; the worker thread retrieves the task from the queue, parses the command, and executes the corresponding business logic. Result return and display steps: The CLI server's worker thread sends the command execution result back to the CLI client; the CLI client's receiving thread receives and displays the result to the user terminal in real time.

[0042] In this embodiment, the method further includes asynchronous event processing and disconnection reconnection steps: Asynchronous event handling: If a state change event that requires active notification to the client is generated during the execution of business logic by the CLI server, the event data is actively pushed through the client's socket; the CLI client's receiving thread listens for and receives the event data in real time and immediately displays it to the user, realizing non-blocking real-time state monitoring; Disconnection and reconnection: When the CLI client's receiving thread detects that the server connection has been lost, it sets a disconnection flag; the sending thread checks this flag before sending commands, and if it is in a disconnection state, it automatically attempts to reconnect to the server. After a successful reconnection, it continues to send commands.

[0043] Example 2

[0044] I. Overall Architecture Implementation This system consists of a server-side component and a client-side component. The server-side component is designed to be embedded in a background main business process and run as a background service. The client-side component is a standalone executable application that users can launch to interact with the system.

[0045] These two components communicate efficiently via Unix domain sockets. Upon startup, the server creates and listens on a Unix domain socket based on its configuration information (such as the specified socket file path and maximum number of client connections). Clients then connect to this socket according to their corresponding configuration information.

[0046] II. Server-side implementation methods 1. Initialization and Startup: The main business process first initializes the server components, providing them with necessary configuration parameters such as socket paths and connection limits. This initialization step is responsible for creating and binding Unix domain sockets and preparing the server's runtime context, including mechanisms for concurrently handling client requests and necessary synchronization. After initialization, the system will start a dedicated main thread to listen for client connection requests.

[0047] 2. Server-side main thread (I / O processing and task distribution): The core function of this main thread is to utilize an efficient I / O multiplexing mechanism to uniformly manage all socket events. This thread continuously waits for events to occur, and its main responsibilities are twofold: Handling new connections: Handling new connections: If the judgment result is "fd is a listening socket" (e.g.) Figure 1 If the connection is accepted, the new client socket will be added to the epoll monitoring list.

[0048] Data reception and distribution: If it is determined that the socket is not a listening socket, then `recv` is called to read the client data. For example... Figure 2 As shown, in order to solve the main thread blocking problem, the main thread does not directly process business logic. Instead, it encapsulates the read data, adds it to the task queue, and performs a tail insertion operation.

[0049] 3. Worker Thread Pool (Business Logic Execution): A pre-created worker thread pool continuously monitors this task queue. For example... Figure 2 As shown on the right, the Threads in the thread pool are in a standby state. When the main thread completes the "tail insertion" operation of a task, it will wake up the thread. The idle worker thread performs "task retrieval," taking a Task from the head of the queue. This process decouples the I / O thread from the business thread, ensuring the server's rapid response to network events in high-concurrency scenarios. The responsibilities of the worker thread include: Parse the structured command data sent by the client.

[0050] The corresponding processing function is searched in the internal registry based on the command name.

[0051] If the command is not found, a detailed error message (such as "unknown command") will be formatted.

[0052] If a command is found, the corresponding business logic is executed.

[0053] Finally, the worker thread replies to the client with the execution result (whether it's success data or detailed error information) through the client's socket.

[0054] 4. Server-side handling of client exit: e.g. Figure 1 As shown, when recv returns 0 bytes, it is determined that "the client has closed the connection". At this time, the main thread executes the cleanup process: closes the client file descriptor, removes the file descriptor from epoll, and finally enters the "end processing" to release related resources, ensuring that the server does not run out of file descriptors due to dead connections.

[0055] III. Client-side Implementation Methods 1. Initialization and Startup: When the client program starts, it initializes its context according to the configuration, including creating an instance for I / O monitoring. Then, it attempts to connect to the Unix domain socket specified by the server. Upon successful connection, the client starts its business processes.

[0056] 2. Sending Thread (User Input and Command Encapsulation): This thread is dedicated to handling user input. It runs in a loop, providing a user prompt that supports history and command completion. When the user enters a command, the thread first checks if it is a client-side internal command (such as "help" or "quit"). If so, it is processed directly locally. If it is not an internal command, the thread calls a command parsing module to convert the user-input string into a predefined binary structured command format. Before sending, the thread checks the current connection status (see Automatic Reconnection Logic). Finally, it sends the encapsulated binary command data to the server via a socket.

[0057] 3. Receive Thread (Asynchronous Event and Response Handling): This thread is dedicated to receiving data. It runs in a loop, using I / O multiplexing to block and wait for readable events on the socket. Once data arrives from the server (whether a response to a command or an asynchronous status update pushed by the server), this thread is awakened. It immediately reads the data from the socket and displays it on the user's terminal. This separation of input and output ensures that the client always receives asynchronous events from the server in real time, even while the user is entering commands.

[0058] 4. Client-side handling of server exit: e.g. Figure 3 As shown in the upper part, if the receiving thread detects that the server-side file descriptor (fd) has triggered an EPOLLHUP event in epoll_wait, or if recv returns 0 / -1, it determines that the server connection has been broken. At this time, the client sequentially executes "close local socket(fd)" and "remove fd from epoll", and sets the internal connection status to "broken". This mechanism ensures that the client can accurately perceive changes in the link status.

[0059] 5. Automatic Client Reconnection: This implementation includes automatic reconnection logic. For example... Figure 3As shown in the lower part, when "the user enters new data," the system first determines "whether the connection is currently established." If the connection is established, data is sent directly; if the connection is broken, an automatic recovery process is initiated: the system attempts to reconnect to the server, i.e., creates a new socket and connects. If the connection fails, the system checks if the maximum number of retries has been reached. If not, it waits and retryes until a successful reconnection or a timeout occurs. This process resolves service interruptions caused by network fluctuations, greatly improving the continuity of the user experience.

[0060] IV. Core Data Structures and Instruction Parsing Implementation 1. Structured Command Communication: To improve efficiency and reduce server load, the client and server do not directly transmit raw text commands. Instead, a binary, structured communication protocol is defined. Commands are parsed and encapsulated into this binary format on the client before being sent.

[0061] Command Parameter Structure: Defines a data structure that contains command parameters. This structure can hold the parameter name, data type (such as integer, floating-point, string), and actual value.

[0062] Command frame structure: Defines a data frame structure containing a complete command. It includes the command name, the total number of parameters, and a variable-length area to store all the parameters.

[0063] 2. Command Parsing Implementation: The client's "sending thread" is responsible for command parsing. Upon receiving the user-input string, the parser splits it into commands and parameters. It first identifies the command name and then iterates through all parameters. The parser queries an internal command definition table to support named parameters and positional (anonymous) parameters. Based on the definition table, it converts the text-formatted parameter values ​​to their corresponding binary data types (integer, floating-point, etc.), fills and encapsulates them according to the command frame structure described above, and finally calculates the total length, ready for transmission.

[0064] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A CLI interaction system for private network protocols, characterized in that, The system comprises: a CLI server embedded into a background main service process running in a private network protocol as a server component; a CLI client as an independent executable application started by a user to interact with the CLI server; a local inter-process communication connection established between the CLI server and the CLI client through a Unix domain socket; the CLI server is configured to use a concurrent model based on I / O multiplexing to handle the connection and requests of multiple CLI clients in a non-blocking manner; the CLI client is configured to use a non-blocking model with separate input threads and receiving threads to achieve parallel processing of user command input and server message reception.

2. The system of claim 1, wherein, The CLI server comprises: an initialization module for creating and binding a Unix domain socket according to configuration parameters, initializing a server runtime context; a main listening thread running an I / O multiplexing mechanism for listening to client connection requests and data arrival events of connected clients; when there is a new connection request, the connection is accepted and the new client socket is added to the monitoring; when data arrives, the data is read and encapsulated as a task unit, which is pushed to a concurrent task queue; a worker thread pool consisting of multiple pre-created worker threads for continuously monitoring the concurrent task queue, obtaining tasks from the queue and executing them, the execution including: parsing structured command data sent by the client, finding and executing corresponding business logic processing functions, and returning the execution results to the client through the client socket.

3. The system of claim 1, wherein, The CLI client comprises: a connection management module for initializing a client context according to configuration information and attempting to connect to the specified Unix domain socket of the CLI server; a sending thread dedicated to handling user interaction input, providing a user prompt with support for history recording and command completion; for identifying user input commands, if it is a local internal instruction, it is processed locally, otherwise, the instruction parsing module is called to convert the user input string into a predefined binary structured command format, and the string is sent to the CLI server through the socket; a receiving thread dedicated to data reception, running an I / O multiplexing mechanism to block and wait for readable events on the socket; for reading data sent by the CLI server, the data includes responses to commands or asynchronous status updates pushed by the server, and displaying them to the user terminal in real time.

4. The system of claim 3, wherein, The CLI client further comprises a broken line automatic reconnection module; the receiving thread is further configured to: when monitoring I / O, if a connection interruption is detected, the local socket is closed and a global "unconnected" status flag is set; the sending thread is further configured to: before preparing to send command data, check the "unconnected" status flag; if the flag indicates "unconnected", automatically trigger the reconnection logic to attempt to reconnect to the CLI server; if the reconnection is successful, clear the "unconnected" status flag and send the user input command.

5. The system of claim 3, wherein, The system further comprises an instruction parsing module integrated in the sending thread of the CLI client; The instruction parsing module is configured to parse and encapsulate the original command string input by the user into binary structured command data for transmission. The binary structured command data at least includes a command frame structure body containing a command name field, a parameter number field and a variable length parameter list area; The parameter list area is filled with a plurality of command parameter structure bodies, each of which contains a parameter name field, a parameter data type field and a parameter value field.

6. The system of claim 5, wherein, The instruction parsing module is configured to: segment the user input string to identify the command name and parameters; query the internal predefined command definition table to support the parsing of named parameters and positional parameters; convert the text format parameter value into the corresponding binary data type according to the parameter data type defined in the command definition table; fill and encapsulate the data according to the format of the command frame structure body and the command parameter structure body, and calculate the total length.

7. The system of claim 3, wherein, The user prompt provided by the sending thread supports intelligent command completion function, which provides possible command or parameter completion options according to the user's input characters by querying the internal command definition table, so as to reduce the user's memory burden and input error rate.

8. The system of claim 2, wherein, When the command execution fails, the working thread in the working thread pool is configured to generate and return descriptive information containing specific error causes instead of general error codes to assist the user in accurately locating the problem. 9.A method for CLI interaction for private network protocol, implemented based on the system of any one of claims 1 to 8, characterized in that, The method comprises: server initialization step: the CLI server is initialized in the main business process, a Unix domain socket is created and bound, and a main listening thread is started to start listening to the connection; client connection step: the CLI client starts and connects to the Unix domain socket listened by the CLI server, and after successful connection, the sending thread and the receiving thread are started; command input and sending step: the sending thread of the CLI client receives the command input by the user, and if it is not an internal instruction, it is parsed into binary structured command data and sent to the CLI server through the socket; command receiving and processing step: the main listening thread of the CLI server listens to the arrival of client data, reads and encapsulates it into a task queue; the working thread gets the task from the queue, parses the command and executes the corresponding business logic; result returning and displaying step: the working thread of the CLI server sends the command execution result back to the CLI client; the receiving thread of the CLI client receives and displays the result to the user terminal in real time.

10. The method of claim 9, wherein, The method further comprises asynchronous event processing and disconnection reconnection steps: asynchronous event processing: if a state change event that needs to be actively notified to the client occurs during the execution of the business logic, the CLI server actively pushes the event data through the socket of the client; the receiving thread of the CLI client listens to and receives the event data in real time, and displays it to the user immediately, realizing non-blocking real-time state monitoring; disconnection reconnection: when the receiving thread of the CLI client detects that the server connection is disconnected, it sets the unconnected flag; The sending thread checks the flag before sending a command, if it is not connected, it will automatically try to reconnect to the server, and continue to send the command after a successful reconnection.

Images