A pseudo-terminal remote control system based on master-slave architecture

Abstract

The application discloses a pseudo-terminal remote control system based on a master-slave architecture, and relates to the technical field of computer terminal control.The system comprises a master control terminal and a controlled terminal, wherein the master control terminal comprises an interface self-defining module, a master control communication module and a data rendering module, the controlled terminal comprises a pseudo-terminal creating module, a multi-thread processing module comprising a command issuing thread and a data echoing thread, and a controlled communication module;the application adopts the master-slave architecture and a multi-thread asynchronous processing mechanism, separates command issuing and data echoing to independent threads for parallel operation, completely eliminates single-thread blocking, and the master control terminal supports the font, color, layout of a user-defined command line interface, and various data display formats such as tables and logs, and realizes flexible rendering through dynamically generating ANSI escape sequences or HTML fragments, greatly improves the visual experience of remote operation, and thus provides an efficient, reliable, flexible and adaptable technical solution for remote centralized management and control of network switching chips.

Description

Technical Field

[0001] This invention relates to the field of computer terminal control technology, and in particular to a pseudo-terminal remote control system based on a master-slave architecture. Background Technology

[0002] Network switching chips are core hardware components in data communication equipment, primarily responsible for high-speed forwarding of data packets within a local area network (LAN) or data center, enabling information exchange and routing between different ports. They typically run an embedded operating system and provide a software development kit (SDK) for upper-layer control programs to use. Developers can configure, monitor, and manage the chip through a command-line interface (CLI) or application programming interface (API), such as setting VLANs, viewing port status, and adjusting traffic policies.

[0003] Control of network switching chips typically relies on dedicated hardware terminals or local command-line interface (CLI) tools. These traditional methods suffer from limitations in operational scenarios, lack of remote management capabilities, and low efficiency in multi-terminal collaboration. Dedicated hardware terminals require physical access, resulting in high maintenance costs and hindering large-scale deployment; while local CLI tools are lightweight, they can only operate on a single device, failing to meet the needs of remote debugging and centralized management. Furthermore, existing network switching chips often come with standalone terminal control tools that do not allow users to customize interface display styles (such as fonts, colors, and layouts), and data display formats are limited (only plain text output), making it difficult to adapt to different operating habits or complex data viewing scenarios.

[0004] On the other hand, existing pseudo-terminal remote control solutions have significant flaws in their software architecture. Most solutions use a single thread to sequentially process command issuance and data feedback. When executing time-consuming commands, the entire interaction process is blocked, preventing subsequent commands from being sent in a timely manner and preventing real-time data feedback, severely impacting user experience and response efficiency. Furthermore, these solutions lack robust exception handling mechanisms, such as the inability to automatically reconnect and restore data when the network connection is lost. In multi-threaded environments, they also lack protection for shared resources (such as pseudo-terminal file descriptors), making them prone to data cross-contamination or program crashes. Therefore, this invention proposes a pseudo-terminal remote control system based on a master-slave architecture to address the problems existing in the prior art. Summary of the Invention

[0005] To address the aforementioned problems, the present invention aims to propose a pseudo-terminal remote control system based on a master-slave architecture. Through a master-slave architecture, multi-threaded asynchronous command issuance and data feedback, client-customized interface rendering, and mechanisms such as disconnection and reconnection and mutex locks, remote, flexible, efficient, and stable pseudo-terminal control of network switching chips is achieved.

[0006] To achieve the objectives of this invention, the invention is implemented through the following technical solution: a pseudo-terminal remote control system based on a master-slave architecture, comprising a master control terminal and a controlled terminal. Through this master-slave architecture, the master control terminal is responsible for interface customization and command input, while the controlled terminal utilizes independent threads to handle command issuance and data feedback, thereby realizing remote pseudo-terminal control of a network switching chip and avoiding mutual blocking between commands and feedback. The main control terminal includes: The interface customization module is used to receive the command-line interface (CLI) display style and data display format configured by the user and generate interface configuration parameters; The main control communication module is used to establish a network connection with the controlled terminal, send control commands input by the user, and receive pseudo-terminal output data returned by the controlled terminal. The data rendering module is used to dynamically render and display the received pseudo-terminal output data in the command-line interface according to the interface configuration parameters. The controlled terminal includes: The pseudo-terminal creation module is used to call the operating system interface to create a pseudo-terminal (PTY) and to interface with the software development kit (SDK) control interface of the network switching chip to simulate the local terminal interaction environment. The multi-threaded processing module includes a command issuing thread and a data echoing thread. The command issuing thread is used to listen for control commands from the master control terminal in a loop, parse them, and call the software development kit control interface to write the commands to the pseudo terminal, thereby controlling the network switching chip. The data echoing thread runs independently of the command issuing thread and is used to read the chip status or command execution result data output by the pseudo terminal in a loop, encapsulate it, and send it to the master control terminal through the controlled communication module. The controlled communication module is used to maintain the network connection with the main control unit and handle abnormal situations in data transmission and reception. The master control terminal and the controlled terminal form a master-slave remote control link through the master control communication module and the controlled communication module, realizing remote pseudo-terminal operation of the network switching chip.

[0007] Further improvements include: the interface customization module allows users to configure the command-line interface display style, including font type, font size, foreground color, background color, and window layout; the data display format includes plain text mode, table mode, and log hierarchical display mode, to meet different operating habits.

[0008] A further improvement is that the master communication module and the controlled communication module establish a long connection using the Transmission Control Protocol (TCP) and support an automatic reconnection mechanism after disconnection, and implement a heartbeat detection mechanism. When an abnormal network disconnection is detected, the controlled communication module buffers the unsent echo data and continues to send it after a successful reconnection, ensuring that no data is lost.

[0009] A further improvement is that when creating a pseudo-terminal, the pseudo-terminal creation module simultaneously allocates a pseudo-terminal master (PTY master) and a pseudo-terminal slave (PTY slave), and redirects the standard input and output of the software development kit (SDK) control interface to the pseudo-terminal slave. This allows the controlled terminal to read and write the interactive data of the SSDK through the pseudo-terminal master. The system calls allocate the PTY master and slave, and redirect the SDK input and output to the slave, enabling the controlled terminal to interact with the SDK through the master, simulating local terminal behavior.

[0010] A further improvement is that the multi-threaded processing module also includes a mutex lock mechanism to lock and protect the pseudo-terminal master file descriptor, protecting the command issuing thread and the data echoing thread from concurrent access to the shared resource, namely the pseudo-terminal master file descriptor, preventing data cross-contamination, ensuring that the command issuing thread and the data echoing thread do not read or write the same resource at the same time, and avoiding data chaos.

[0011] Further improvements are made in that: the command issuing thread adopts a non-blocking write method, and returns immediately after writing to continue processing new commands. After writing the command to the pseudo terminal, it does not wait for the chip to return the result, but immediately returns to continue listening for the next command. The data echo thread polls the pseudo-terminal's output buffer at fixed time intervals (e.g., every 10 milliseconds). Once new data is detected, it is read, encapsulated, and sent, improving real-time response.

[0012] A further improvement is that the controlled terminal runs on a Linux operating system, and the pseudo-terminal creation module creates and obtains the pseudo-terminal name by calling the following standard system functions: Call the function posix_openpt() to open the pseudo-terminal master device; Call the grantpt() function to set permissions for the pseudo-terminal slave device; Call the unlockpt() function to unlock the pseudo-terminal master-slave pair; Call the function ptsname() to get the slave device path, which is used to obtain the file path of the slave device associated with the master device; In a Linux environment, following the standard procedure, calling the functions posix_openpt(), grantpt(), unlockpt(), and ptsname() in sequence will yield a usable pseudo-terminal device path. These functions are all defined in the standard library header file.<stdlib.h> and pseudo-terminal header files<pty.h> This is a standard interface for creating pseudo-terminals in the Linux system, which can be directly called by those skilled in the art.

[0013] A further improvement is that the data rendering module maintains a configuration cache to store the interface configuration parameters generated by the interface customization module. When the main control terminal receives pseudo-terminal output data sent by the controlled terminal, the data rendering module reads the currently valid parameters from the configuration cache and dynamically generates ANSI (American National Standards Institute) escape sequences or Hypertext Markup Language (HTML) fragments to complete the real-time redrawing of the terminal interface. The data rendering module caches the interface configuration parameters in memory. After receiving the echo data, it generates ANSI escape sequences or HTML fragments according to the current configuration and sends them to the front end for rendering, thereby realizing the dynamic refresh of the interface style.

[0014] The beneficial effects of this invention are as follows: This invention realizes remote pseudo-terminal control of network switching chips through a master-slave architecture. The controlled end adopts a multi-threaded asynchronous processing mechanism in which command issuance and data feedback are independent, which can completely avoid single-threaded blocking and significantly improve command response and data transmission efficiency. Moreover, the master control end supports user-customizable fonts, colors, layouts, and various data display formats such as tables and logs in the command line interface. The data rendering module dynamically generates ANSI escape sequences or HTML fragments, which greatly enhances the operational flexibility and visualization experience. In addition, the use of a mutex lock mechanism to protect shared resources and prevent data contention, and the automatic reconnection and data caching functions ensure communication stability under network fluctuations. This pseudo-terminal remote control system is flexible, efficient, remotely controllable, and highly reliable, and is suitable for centralized operation and maintenance scenarios of large-scale network switching chips. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the framework structure of the pseudo-terminal remote control system based on the master-slave architecture of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] It should be noted that the technical means not described in detail in the following embodiments are all conventional means in the art, are not the key points of the invention, and will not be elaborated upon.

[0018] according to Figure 1As shown, this embodiment takes the control of a network switching chip under a Linux operating system environment as an example to provide a pseudo-terminal remote control system based on a master-slave architecture. The system consists of a master control terminal and a controlled terminal. The master control terminal runs on the host computer operated by the user (such as a personal computer), and the controlled terminal runs on a server directly connected to the network switching chip. The master control terminal and the controlled terminal establish a long connection via the network using the TCP protocol.

[0019] The main control unit consists of three modules: a user interface customization module, a main control communication module, and a data rendering module.

[0020] The controlled terminal consists of three modules: a pseudo-terminal creation module, a multi-threaded processing module (containing a command issuance thread and a data echo thread), and a controlled communication module.

[0021] The specific implementation of the main control terminal in this embodiment is as follows: Customizable Interface Module Users can set the display style and data display format of the command-line interface (CLI) through the graphical configuration interface or configuration file (such as JSON format) provided by the main control terminal.

[0022] Configurable display styles include: font type (e.g., "Consolas"), font size (12pt), foreground color (#00FF00), background color (#000000), and window layout (single window or split screen). Data display formats include: plain text mode (directly displaying the raw character stream), table mode (displaying structured data with row and column alignment), and log hierarchical display mode (displaying different colors according to log levels such as ERROR, WARN, and INFO).

[0023] The UI customization module saves these configuration parameters as a structure in memory (configuration cache) and passes it to the data rendering module.

[0024] Main control communication module The main control communication module acts as a TCP client, actively connecting to the port (e.g., 8000) being listened to by the controlled terminal. After the connection is established, it sends a heartbeat packet "PING" every 30 seconds to check the connection status. This module is responsible for sending user-input control commands (e.g., "show interface status") to the controlled terminal and receiving pseudo-terminal output data returned by the controlled terminal.

[0025] Data rendering module The data rendering module maintains a configuration cache to store the interface configuration parameters generated by the interface customization module. When the master control communication module receives pseudo-terminal output data (raw byte stream) sent by the controlled terminal, the data rendering module reads the currently valid parameters from the configuration cache, dynamically generates ANSI escape sequences or Hypertext Markup Language (HTML) fragments, and completes real-time redrawing of the terminal interface.

[0026] The specific method for dynamically generating ANSI escape sequences is as follows: If the main control unit runs in a native terminal environment (such as GNOME Terminal), the data rendering module generates ANSI escape sequences based on the configured foreground and background colors. For example, when the foreground color is green, "\033[32m" is added before the output data, and "\033[0m" is added after the data to reset the style. If the data display format is a table, the rendering module first splits the original data into fields according to the delimiter (such as a tab), calculates the maximum width of each column, generates aligned table text, and then adds ANSI color escape sequences. If it is a log hierarchical display mode, it identifies keywords such as "ERROR:" and "WARN:" through regular expression matching and sets different colors for different levels (red for errors, yellow for warnings, and green for information).

[0027] The specific method for dynamically generating HTML fragments is as follows: If the main control unit runs in a web environment (such as an Electron-based desktop application), the data rendering module will convert the configuration parameters into CSS styles and generate HTML fragments. For example: <pre> Command execution result< / pre> .

[0028] Then the fragment is inserted into the DOM tree to complete the rendering.

[0029] The specific implementation of the controlled end in this embodiment is as follows: Pseudo-terminal creation module The controlled terminal runs on the Linux operating system. The pseudo-terminal creation module creates pseudo-terminals (PTYs) by calling the following standard system functions: Call the function posix_openpt() to open the pseudo-terminal master device and open the pseudo-terminal master file descriptor master_fd.

[0030] Call the function grantpt(master_fd) to set permissions for the slave device, granting read and write permissions to the slave device.

[0031] Call the unlock pseudo-terminal function unlockpt(master_fd) to unlock the master-slave device pair.

[0032] Call the function ptsname(master_fd) to get the slave device path (e.g., / dev / pts / 5).

[0033] Call open() to open the slave device file descriptor slave_fd.

[0034] The above functions are all defined in<stdlib.h> and<pty.h> The header file contains the standard interface for creating pseudo-terminals in the Linux system.

[0035] Then, the pseudo-terminal creation module redirects the standard input and standard output of the network switching chip SDK control interface to `slave_fd` via the `dup2()` system call. This allows the controlled terminal to simulate local terminal input by writing commands to `master_fd`, and to obtain the chip status or command execution results returned by the SDK by reading output from `master_fd`. Simultaneously, the pseudo-terminal creation module allocates a pseudo-terminal master (PTY master) and a pseudo-terminal slave (PTY slave), and redirects the standard input and output of the SDK control interface to the pseudo-terminal slave, enabling the controlled terminal to read and write SDK interaction data through the pseudo-terminal master.

[0036] Multi-threaded processing module The multi-threaded processing module creates two independent POSIX threads: a command issuance thread and a data echo thread, wherein: Command issuance thread: The `recv()` function is called repeatedly to receive control command strings from the master terminal via the controlled communication module. After parsing the command, `write(master_fd, cmd_str, len)` is called to write the command to the pseudo-terminal master terminal file descriptor. The write operation is non-blocking (by setting the `O_NONBLOCK` flag or using the `select()` event-driven method), and returns immediately after writing without waiting for the chip to return a result, continuing to listen for the next command.

[0037] Data echo thread: Running independently of the command issuing thread, it repeatedly calls `read(master_fd, buf, sizeof(buf))` to read data output from the pseudo-terminal master. To avoid CPU consumption from idle reads, it uses `select()` to block and wait for readable events, with a timeout of 10 milliseconds. When data is detected, it is read immediately, encapsulated into a message packet with a length field, and sent to the master through the controlled communication module. The data echoing thread polls the pseudo-terminal's output buffer at fixed time intervals (actually controlled by the `select()` timeout), reading, encapsulating, and sending new data as soon as it is detected.

[0038] The multithreaded processing module also includes a mutex mechanism (pthread_mutex_t) to protect concurrent access to shared resources by the command issuing thread and the data echoing thread. These shared resources refer to certain attributes of the pseudo-terminal master file descriptor (such as modification of the non-blocking flag) and statistical counters. For example, a lock is acquired before modifying the file status flags of master_fd, and unlocked after modification to prevent data cross-contamination.

[0039] Controlled communication module The controlled communication module acts as a TCP server, listening on a port and accepting connections from the master control unit. It maintains the network connection with the master control unit and handles abnormal data transmission and reception. Specifically, when a network disconnection is detected (e.g., three consecutive heartbeat timeouts), the controlled communication module buffers any unsent pseudo-terminal output data in a memory queue and automatically reconnects using an exponential backoff strategy (1 second, 2 seconds, 4 seconds... up to a maximum of 60 seconds). Once the reconnection is successful, the buffered data is automatically sent to the master control unit in sequence.

[0040] The complete interaction flow of this embodiment is as follows: Users can enter the command "show version" in the CLI interface on the main control terminal. The interface customization module has been pre-configured with green font and table mode.

[0041] The master communication module sends commands to the controlled terminal.

[0042] The command sending thread on the controlled end receives commands and calls write(master_fd,"show version\n",12) to write them to the pseudo-terminal master end.

[0043] The network switching chip SDK receives commands from the end via a pseudo-terminal, executes them, and returns a version information string.

[0044] The data echo thread reads version information from master_fd, encapsulates it, and sends it back to the master terminal through the controlled communication module.

[0045] The main control communication module receives data and transmits it to the data rendering module.

[0046] The data rendering module aligns the version information according to the green font and table mode parameters in the configuration cache and adds ANSI escape sequences (such as \033[32m), and finally displays it on the main control CLI interface.

[0047] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A pseudo-terminal remote control system based on a master-slave architecture, comprising a master control terminal and a controlled terminal, characterized in that: The main control terminal includes: The interface customization module is used to receive the command-line interface display style and data display format configured by the user and generate interface configuration parameters; The main control communication module establishes a network connection with the controlled end, and is used to send control commands input by the user and receive pseudo-terminal output data returned by the controlled end. The data rendering module is used to dynamically render and display the received pseudo-terminal output data in the command-line interface according to the interface configuration parameters. The controlled terminal includes: The pseudo-terminal creation module is used to call the operating system interface to create a pseudo-terminal and to interface with the software development kit control interface of the network switching chip to simulate the local terminal interaction environment. The multi-threaded processing module includes a command issuing thread and a data echoing thread. The command issuing thread is used to listen for control commands from the master control terminal in a loop, parse them, and call the software development kit control interface to write the commands into the pseudo terminal, thereby controlling the network switching chip. The data echoing thread is used to read the chip status or command execution result data output by the pseudo terminal in a loop, encapsulate it, and send it to the master control terminal through the controlled communication module. The controlled communication module is used to maintain the network connection with the main control unit and handle abnormal situations in data transmission and reception. The master control terminal and the controlled terminal form a master-slave remote control link through the master control communication module and the controlled communication module, realizing remote pseudo-terminal operation of the network switching chip.

2. The pseudo-terminal remote control system based on a master-slave architecture according to claim 1, characterized in that: The interface customization module allows users to configure the command-line interface display style, including font type, font size, foreground color, background color, and window layout. The data display format includes plain text mode, table mode, and log hierarchical display mode.

3. The pseudo-terminal remote control system based on a master-slave architecture according to claim 1, characterized in that: The master communication module and the controlled communication module establish a long connection using the transmission control protocol and support an automatic reconnection mechanism. When a network abnormal disconnection is detected, the controlled communication module buffers the unsent echo data and continues to send it after a successful reconnection.

4. The pseudo-terminal remote control system based on a master-slave architecture according to claim 1, characterized in that: When creating a pseudo-terminal, the pseudo-terminal creation module simultaneously allocates a pseudo-terminal master and a pseudo-terminal slave, and redirects the standard input and output of the software development kit control interface to the pseudo-terminal slave, enabling the controlled terminal to read and write the interactive data of the software development kit through the pseudo-terminal master.

5. A pseudo-terminal remote control system based on a master-slave architecture according to claim 1, characterized in that: The multi-threaded processing module also includes a mutex mechanism to protect the concurrent access of the command issuing thread and the data echoing thread to the shared resource, namely the pseudo-terminal master file descriptor.

6. A pseudo-terminal remote control system based on a master-slave architecture according to claim 1, characterized in that: After writing the command to the pseudo-terminal, the command issuing thread does not wait for the chip to return a result and immediately returns to continue listening for the next command. The data echoing thread polls the output buffer of the pseudo-terminal at fixed time intervals, and reads, encapsulates and sends new data as soon as it is detected.

7. A pseudo-terminal remote control system based on a master-slave architecture according to claim 1, characterized in that: The controlled terminal runs on a Linux operating system environment, and the pseudo-terminal creation module creates and obtains the pseudo-terminal name by calling standard system functions.

8. A pseudo-terminal remote control system based on a master-slave architecture according to claim 1, characterized in that: The data rendering module maintains a configuration cache to store the interface configuration parameters generated by the interface customization module. When the master terminal receives pseudo-terminal output data sent by the controlled terminal, the data rendering module reads the currently valid parameters from the configuration cache and dynamically generates ANSI escape sequences or hypertext markup language fragments to complete the real-time redrawing of the terminal interface.

Images