A remote USB data hardware level processing method suitable for a weak network environment

Abstract

A remote USB data hardware level processing method suitable for weak network environment relates to the technical field of computer network communication and remote device sharing, comprising the following steps: a terminal continuously collects original data of a physically accessed USB input device, and unidirectionally and continuously sends the original data to a target server through an anti-weak network communication protocol; the target server forwards the data to a single-chip microcomputer; the single-chip microcomputer analyzes and converts the original data at the hardware level to generate hardware signals conforming to the USB protocol specification; and the single-chip microcomputer outputs the hardware signals to the target server through a USB interface to simulate the input of a real USB device, so that the target server completes the response to the original data and the like. By introducing a single-chip microcomputer for hardware simulation and matching the anti-weak network communication protocol, the problems of sensitivity of a traditional USB / IP protocol to network delay, performance drop under a weak network and large CPU overhead of a server are solved.

Description

Technical Field

[0001] This invention relates to the field of computer network communication and remote device sharing technology, specifically to a remote USB data hardware-level processing method suitable for weak network environments. Background Technology

[0002] With the rapid popularization of cloud computing, cloud computers, and cloud gaming, low-latency and high-reliability sharing of remote USB input devices (such as USB mice and keyboards) has become a core industry requirement. Traditional local USB devices connect directly to the host via a physical interface, achieving millisecond-level response and ultra-high return on investment.

[0003] Currently, the mainstream solution for remote USB device sharing is the USB / IP (USB over IP) protocol. This technology was first proposed by Koji Takahashi and others in Japan, and related implementations can be found in the open-source project usbip and patent documents, such as the US patent with publication number US20070271219A1. Its core principle is to transparently transmit the request and response data packets of the USB device through a TCP / IP network. The remote host uses software to simulate a USB host controller, parsing and processing the USB data packets from the network. The terminal device, acting as the acquisition end, is responsible for capturing raw data and sending it to the remote server. The remote server needs to wait for the request data packet to arrive, generate a response data packet, and send it back to the terminal. Only after receiving the response packet can the terminal continue to send the next batch of data, forming a synchronous "request-response" interaction mode. However, the existing technology has the following significant drawbacks:

[0004] 1. Extremely high dependence on network quality: The USB / IP protocol strictly adopts a synchronization mechanism. After the client sends a data packet, it must wait for a reply from the remote server before it can continue to send the next batch of data. When there is a network delay of more than 2ms, the polling rate of devices such as mice will drop sharply from 1000Hz to below 500Hz, which will seriously affect the smoothness of operation (such as inaccurate mouse positioning and keyboard lag in FPS games).

[0005] 2. Insufficient resilience to weak network conditions: Based on the general TCP / IP protocol, it is not optimized for USB real-time performance. In scenarios with network jitter and packet loss, packet retransmission will further aggravate the delay, causing device response interruption or drift, which cannot meet the needs of use scenarios with high stability requirements.

[0006] 3. Significant performance loss: The remote server relies on software to simulate the USB host controller, which incurs high overhead in protocol stack parsing, and the synchronization waiting mechanism consumes a large amount of CPU resources. Summary of the Invention

[0007] This invention provides a remote USB data hardware-level processing method suitable for weak network environments. By introducing a microcontroller for hardware simulation and combining it with a weak network-resistant communication protocol, it solves the problems of traditional USB / IP protocols being sensitive to network latency, experiencing a sharp drop in performance under weak network conditions, and incurring high server CPU overhead.

[0008] A remote USB data hardware-level processing method suitable for weak network environments includes the following steps:

[0009] S1, the terminal continuously collects raw data from the physically connected USB input device and continuously sends the raw data unidirectionally to the target server through the anti-weak network communication protocol;

[0010] S2, After receiving the raw data, the target server forwards the data to the microcontroller connected to the target server through the physical interface;

[0011] S3, the microcontroller parses and performs hardware-level conversion on the raw data to generate hardware signals that conform to the USB protocol specification;

[0012] S4, the microcontroller outputs hardware signals to the target server through the USB interface, simulating the input of a real USB device, so that the target server can complete the response to the raw data.

[0013] Furthermore, the establishment and transmission process of the anti-weak network communication protocol in step S1 includes:

[0014] A full-duplex network communication link is constructed based on the UDP protocol and integrated with the KCP algorithm;

[0015] After establishing a connection through a three-way handshake, the data stream is encrypted end-to-end using a proprietary encryption algorithm at the transport layer.

[0016] When the terminal sends raw data, it does not need to wait for the target server's network response confirmation to continue sending the next data packet.

[0017] Furthermore, prior to step S1, a terminal identification and binding step is also included:

[0018] After the terminal detects the physical connection of the USB input device, it extracts the device's manufacturer and product identifiers.

[0019] The terminal encapsulates a binding request message containing the manufacturer's identifier and the product identifier, and sends the request to the target server over the network;

[0020] The target server parses the request message, configures the corresponding USB input device parameters, and returns a binding response message to the terminal.

[0021] Furthermore, after the target server returns the binding response message, it also includes hardware information synchronization and device enumeration steps:

[0022] The terminal sends the device descriptor, configuration descriptor, and HID report descriptor to the target server in sequence.

[0023] After verifying the integrity of the descriptor, the target server forwards it to the microcontroller.

[0024] The microcontroller extracts key parameters and adds a custom private communication interface, independent of the standard USB data interface, to the parsed device descriptor.

[0025] The microcontroller triggers the USB bus reset process and uses the descriptor information containing the private communication interface to complete the enumeration response to the target server.

[0026] Furthermore, in step S2, the process of the target server forwarding data to the microcontroller is as follows:

[0027] The target server performs a fast CRC check on the received network data packets;

[0028] After the verification is successful, the target server forwards the raw data directly to the microcontroller through a custom private communication interface.

[0029] Furthermore, in steps S3 and S4, the hardware-level conversion and handshake of the microcontroller specifically includes:

[0030] The microcontroller extracts the payload from the raw data and generates a USB transmission frame containing a synchronization field, packet identifier, address field, endpoint field, data payload, and CRC check through the built-in USB host controller module.

[0031] The microcontroller uses local timing control and directly performs local link verification and retransmission control with the target server via USB handshake packets, replacing the network-level synchronization waiting mechanism.

[0032] Furthermore, it also includes steps for changing and synchronously writing back USB input device configuration information:

[0033] When the configuration information of the USB input device changes on the target server, the target server will send the configuration modification command to the microcontroller through the USB interface;

[0034] The microcontroller repackages the configuration parameters through a private communication interface and sends them back to the server of the target server.

[0035] The server sends the configuration parameters to the terminal via a weak network communication protocol;

[0036] After receiving and verifying the configuration parameters, the terminal writes the configuration parameters to the locally physically connected USB input device, thus completing bidirectional status synchronization.

[0037] Furthermore, it also includes the device unbinding step:

[0038] When the USB input device is physically removed from the terminal, the terminal immediately sends a device unbinding request to the target server;

[0039] Upon receiving the request, the target server terminates the communication connection with the microcontroller and releases the corresponding device resources.

[0040] A remote USB data hardware-level processing system suitable for weak network environments includes:

[0041] The terminal is used to collect raw data from USB input devices and send it unidirectionally to the target server via a weak network communication protocol.

[0042] The target server is used to receive raw data sent by the terminal and relay it.

[0043] The microcontroller connects to the target server via a physical USB interface. It receives raw data forwarded by the target server, generates hardware-level USB signals, and simulates a real USB device to input data to the target server through local timing control. The target server responds to the command for raw data input.

[0044] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described method.

[0045] The beneficial effects of the above-described technical solutions provided in the embodiments of the present invention include at least the following:

[0046] 1. This invention breaks the traditional synchronous waiting mechanism of the USB / IP protocol. The terminal can send data without waiting for network response packets; the microcontroller uses hardware-level simulation, and performs a local USB handshake with the target server. Even in complex weak network environments with bidirectional network latency of 0-10ms and a 5% packet loss rate, the mouse can still maintain a stable 1000Hz high polling rate, achieving a seamless operating experience indistinguishable from a direct local connection.

[0047] 2. By using microcontroller hardware simulation instead of traditional software simulation of the USB protocol stack, the complex software protocol parsing is eliminated, significantly reducing the CPU overhead of the target server. At the same time, hardware-level timing control eliminates the latency caused by software parsing, improves the overall system response speed, reduces the software simulation overhead of the remote server, and improves overall performance and resource utilization through hardware-level optimization.

[0048] 3. The microcontroller emulates a standard USB device without requiring modifications to the target server's operating system or driver, and is compatible with mainstream systems such as Windows and Linux; the weak network communication protocol is based on UDP encapsulation, which can adapt to various network environments and has a wide range of deployment scenarios.

[0049] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings.

[0050] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0051] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0052] Figure 1 This is a flowchart of a remote USB data hardware-level processing method suitable for weak network environments, as disclosed in an embodiment of the present invention.

[0053] Figure 2 This is a diagram of the overall architecture of the entire system in an embodiment of the present invention;

[0054] Figure 3 This is a timing diagram of device binding and hardware information synchronization disclosed in an embodiment of the present invention;

[0055] Figure 4 This is a flowchart of the operation data transmission and hardware-level processing disclosed in an embodiment of the present invention.

[0056] Figure label:

[0057] 10. USB input device; 20. Terminal; 21. USB acquisition and identification module; 22. Anti-weak network client; 30. Ethernet; 40. Target server; 41. Anti-weak network server; 42. Operating system; 50. Microcontroller. Detailed Implementation

[0058] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0059] A weak network environment specifically refers to the worst acceptable network environment, where the bidirectional network latency from the terminal (such as set-top boxes, mobile terminals, desktop computers and other computer devices) to the computing power (physical devices capable of running operating systems 42, including physical machines, large servers and virtual machines on large servers, etc.) varies within the range of 0~10ms and the packet loss rate is no higher than 5%.

[0060] This invention provides a remote USB data hardware-level processing method suitable for weak network environments. Its core innovation lies in introducing a microcontroller 50 to simulate a real USB device on the target server 40, and combining it with a weak network-resistant communication protocol to construct a fully optimized end-to-end architecture encompassing terminal data acquisition, weak network-resistant transmission, hardware simulation, and computing power interaction. The detailed technical solution is as follows:

[0061] like Figure 2 As shown, the overall system architecture includes:

[0062] 1. USB input device 10: including USB mouse, keyboard, etc., USB input device 10 is directly connected to the terminal through a physical interface.

[0063] 2. Terminal: Responsible for collecting raw data from the USB mouse and keyboard, and sending the data to the target server 40 through the anti-weak network protocol;

[0064] The anti-weak network communication protocol aims to ensure high-speed and reliable data transmission from USB input device 10 in weak network environments. Based on the UDP protocol, it integrates the KCP algorithm for reliability optimization, constructing a full-duplex network communication link that combines the reliable transmission characteristics of TCP with the real-time advantages of UDP. The application layer data transmission logic of this protocol remains consistent with the TCP protocol, eliminating the need for significant modifications to the application layer interfaces of the existing USB input device 10 and the target terminal device. This effectively improves protocol compatibility and ease of implementation, laying the foundation for subsequent reliable connection establishment and data transmission.

[0065] To balance data transmission security and efficiency, this solution encrypts all transmitted data at the transport layer, ensuring greater reliability throughout the entire transmission process. Data encryption employs encryption algorithms to perform end-to-end encryption of the data stream. Through a custom key generation mechanism and private data encryption, it ensures that data is not stolen, cracked, or tampered with during network transmission, guaranteeing the confidentiality and integrity of data transmission.

[0066] After the terminal collects USB data, it transmits it directly, ensuring smooth data transmission with the target server 40 even in a weak network environment. When the microcontroller 50 simulates a USB device, it uses local timing control to strictly match the transmission timing of the real USB device, ensuring that the device data received by the computing unit is identical to the local connection.

[0067] 3. Target server 40, used to receive raw data sent by the terminal and relay it;

[0068] 4. The microcontroller 50 is connected to the target server 40 via a physical USB interface. It is used to receive the raw data forwarded by the target server 40, generate hardware-level USB signals, and simulate a real USB device to input data to the target server 40 through local timing control. The target server 40 responds to the command of raw data input.

[0069] In this system, the microcontroller 50 serves as the core of the hardware simulation. It connects to the target server 40 via a USB interface to simulate the hardware behavior and signal characteristics of a real USB input device 10, such as a USB mouse or keyboard. After receiving raw data from the USB input device 10 at the terminal, the target server 40 forwards the raw data to the microcontroller 50. Upon receiving the raw data, the microcontroller 50 parses and performs hardware-level conversion on the raw data, generating hardware signals that conform to the USB protocol specification. It then sends these signals to the target server 40 via the USB interface, enabling the target server 40 to recognize it as a locally connected, real USB input device 10. This achieves a hardware perception and interaction effect completely consistent with physically inserted USB mice and keyboards.

[0070] Figure 1 The flowchart illustrates a remote USB data hardware-level processing method for weak network environments disclosed in an embodiment of the present invention, including the following steps:

[0071] S1, the terminal continuously collects raw data from the physically connected USB input device 10 and continuously sends the raw data unidirectionally to the target server 40 through the anti-weak network communication protocol.

[0072] The microcontroller 50 has a built-in chip supporting the USB protocol stack, which can directly simulate a real USB device. When the USB data sent by the terminal reaches the target server 40 through the network, the microcontroller 50 immediately parses the data and generates the corresponding hardware USB signal, which is then sent to the computing unit. This process does not require software simulation of the USB device, and the terminal does not need to wait for a response confirmation before sending the next data packet, fundamentally solving the synchronization waiting problem of USB / IP.

[0073] The establishment and transmission process of the weak network communication protocol includes:

[0074] S11, based on the UDP protocol and integrating the KCP algorithm, constructs a full-duplex network communication link;

[0075] S12, after establishing a connection through a three-way handshake, the data stream is encrypted end-to-end using a private encryption algorithm at the transport layer.

[0076] S13, when the terminal sends raw data, it does not need to wait for the network response confirmation from the target server 40 to continue sending the next data packet.

[0077] In a preferred embodiment, the anti-weak network client 22 deployed on the terminal introduces a forward error correction mechanism when encapsulating raw USB data. N consecutive USB data packets are grouped into an error correction group; using an error correction algorithm, an XOR matrix operation is performed on the N data packets to generate M redundant check packets in real time. These N+M data packets are then uniformly appended with consecutive sequence numbers and sent to the target server 40 via a UDP channel. The transmission process is asynchronous and unidirectional, without waiting for ACK. When the anti-weak network server 41 of the target server 40 receives the data, even if ≤M data packets are lost during network transmission, the anti-weak network server 41 does not need to initiate a KCP retransmission request to the terminal. Instead, it directly uses the received remaining packets and the forward error correction algorithm to instantly reverse-engineer the lost USB data packet and send it to the microcontroller 50. This achieves zero retransmission in a weak network environment with a 5% packet loss rate by consuming very little additional bandwidth, ensuring the absolute smoothness of the 1000Hz mouse polling rate.

[0078] In another preferred embodiment, a sending aggregation buffer is set inside the terminal anti-weak network client 22. The aggregation time threshold is set to a very small fixed value, such as 2ms, or a packet number threshold, such as 3 USB data packets. When the terminal collects an 8-byte mouse coordinate message every millisecond, it does not immediately trigger UDP sending, but pushes it into the buffer. When the 2ms threshold is reached, the anti-weak network client 22 merges the multiple raw data in the buffer into an aggregated payload and sends the aggregated packet to the target server 40 via UDP. After receiving the aggregated packet, the anti-weak network server 41 of the target server 40 quickly disassembles it according to the sub-packet length field and forwards it to the microcontroller 50 in the order of timestamps. This significantly reduces the forwarding pressure on network devices in weak network environments. At the same time, the 2ms aggregation delay is completely imperceptible to the human senses, achieving a balance between network transmission efficiency and low latency.

[0079] In another preferred embodiment, during the three-way handshake between the terminal and the target server 40, a lightweight ECDHE algorithm is used to negotiate a 256-bit master key, and both parties synchronize an initial data packet sequence number. While the terminal continuously sends raw USB data, an independent encrypted stream is dynamically generated for each data packet. Specifically, the master key is combined with the sequence number of the current data packet, and a lightweight hash function is input to generate a dynamic key stream of the same length as the current USB data packet. The collected raw USB data payload (such as mouse movement data) is then XORed with the dynamic key stream to obtain the encrypted ciphertext payload. Since the XOR operation is extremely fast and does not change the data length, the processing latency is controlled within microseconds. Finally, the sequence number, ciphertext payload, and CRC32 checksum are concatenated and encapsulated into a UDP / KCP packet for transmission. After receiving the packet, the target server 40 extracts the sequence number. Even if there is packet loss, the server can still generate a completely corresponding dynamic key stream in real time based on the received sequence number and the locally stored master key. By performing an XOR operation again on the dynamic key stream and the ciphertext payload, the original USB data can be restored. Technical benefits: the encryption of each data packet is completely independent, and out-of-order UDP network packets or packet loss will not cause blockage; the computational overhead is extremely low, and both the microcontroller 50 and the target server 40 can complete high-frequency decryption at 1000Hz with extremely low CPU usage.

[0080] Before step S1, a terminal identification and binding step is also included: After the terminal detects the physical access of the USB input device 10, it extracts the manufacturer's identifier and product identifier of the device; the terminal encapsulates a binding request message containing the manufacturer's identifier and product identifier and sends the request to the target server 40 through the network; the target server 40 parses the request message, configures the corresponding USB input device 10 parameters and returns a binding response message to the terminal.

[0081] After the target server 40 returns the binding response message, the process also includes hardware information synchronization and device enumeration steps: the terminal sends the device descriptor, configuration descriptor, and HID report descriptor to the target server 40 in sequence; after verifying the integrity, the target server 40 forwards the descriptor to the microcontroller 50; the microcontroller 50 extracts key parameters and adds a custom private communication interface independent of the standard USB data interface to the parsed device descriptor; the microcontroller 50 triggers the USB bus reset process and uses the descriptor information containing the private communication interface to complete the enumeration response to the target server 40.

[0082] It also includes the steps for changing and synchronizing the configuration information of the USB input device 10:

[0083] When the configuration information of the USB input device 10 changes at the target server 40, the target server 40 sends the configuration modification command to the microcontroller 50 through the USB interface.

[0084] The microcontroller 50 repackages the configuration parameters through a private communication interface and sends them back to the server of the target server 40.

[0085] The server sends the configuration parameters to the terminal via a weak network communication protocol;

[0086] After receiving and verifying the configuration parameters, the terminal writes the configuration parameters to the locally physically connected USB input device 10, completing bidirectional status synchronization.

[0087] S2, after receiving the raw data, the target server 40 forwards the data to the microcontroller 50 that is connected to the target server 40 through the physical interface.

[0088] The process by which the target server 40 forwards data to the microcontroller 50 is as follows:

[0089] S21, Target server 40 performs CRC fast check on the received network data packets;

[0090] S22, after the verification is successful, the target server 40 forwards the raw data directly to the microcontroller 50 through a custom private communication interface.

[0091] S3, the microcontroller 50, parses and performs hardware-level conversion on the raw data to generate hardware signals that conform to the USB protocol specification.

[0092] S4, the microcontroller 50 outputs hardware signals to the target server 40 through the USB interface, simulating the input of a real USB device, so that the target server 40 can complete the response to the raw data.

[0093] In steps S3 and S4, the hardware-level conversion and handshake of the microcontroller 50 specifically includes:

[0094] The microcontroller 50 extracts the payload from the raw data and generates a USB transmission frame containing a synchronization field, packet identifier, address field, endpoint field, data payload, and CRC check through the built-in USB host controller module.

[0095] The microcontroller 50 uses local timing control and directly performs local link verification and retransmission control with the target server 40 via USB handshake packets to replace the network layer synchronization waiting mechanism.

[0096] It also includes a device unbinding step: when the USB input device 10 is physically removed from the terminal, the terminal immediately sends a device unbinding request to the target server 40; after receiving the request, the target server 40 terminates the communication connection with the microcontroller 50 and releases the corresponding device resources.

[0097] Figure 2The diagram shows the overall architecture of the end-to-end system disclosed in an embodiment of the present invention, which includes:

[0098] The terminal is used to collect raw data from the USB input device 10 and send it unidirectionally to the target server 40 via a weak network communication protocol.

[0099] The terminal is equipped with a USB acquisition and identification module 21 and an anti-weak network client 22.

[0100] The USB acquisition and identification module 21 is used to monitor USB hot-plug events of the terminal. When the mouse / keyboard is plugged in, it calls the underlying libusb library to enumerate devices, filter out HID category devices, and extract key identity information such as Vendor Identifier (VID) and Product Identifier (PID) as well as various device descriptors. By setting interrupt transmission callback functions, such as calling libusb_fill_interrupt_transfer(), it captures the underlying raw data generated by user operations in real time and without loss at a very high frequency, such as 1000Hz, such as mouse displacement coordinates, left / right click status, and keyboard key codes. It is also used to call the control transmission interface, such as libusb_fill_control_transfer(), to rewrite the configuration parameters into the local physical USB device when it receives device configuration changes from the target server 40, such as modifying the mouse movement speed.

[0101] The anti-weak network client 22 is used to perform a TCP-like three-way handshake with the target server 40 in the early stages of communication, establish a dedicated and reliable transmission channel based on the UDP protocol + KCP algorithm, and encapsulate the clean raw data captured by the USB acquisition and identification module 21 into a specific private message format, such as [frame header + data length + raw data + checksum]. It also uses a private encryption algorithm to encrypt the data payload at high speed. After the terminal sends a data packet to the target server 40, it can immediately send the next data packet without waiting for the network response confirmation from the target server 40, thus completely immune to the impact of high network latency on the return rate.

[0102] The target server 40 is used to receive raw data sent by the terminal and relay it.

[0103] A weak network protection server 41 and an operating system 42 are deployed on the target server 40.

[0104] The anti-weak network server 41 listens to the bound network port, receives UDP / KCP message streams from the anti-weak network client 22, decrypts the data stream using a private algorithm, and performs CRC integrity verification. If damaged, tampered, or severely out-of-order messages are detected under weak network conditions, the server discards them at this layer or triggers KCP retransmission. It also unpacks verified network messages to extract pure mouse / keyboard operation data, i.e., the payload. Subsequently, through a pre-agreed custom private communication interface with the microcontroller 50, this raw operation data is directly forwarded to the microcontroller 50 plugged into the target server 40. The operating system 42 includes a standard universal USB HID driver.

[0105] The microcontroller 50 is connected to the target server 40 via a physical USB interface. It is used to receive raw data forwarded by the target server 40, generate hardware-level USB signals, and simulate a real USB device to input data to the target server 40 through local timing control. The target server 40 responds to the command of raw data input.

[0106] like Figures 3-4 As shown, the following embodiment illustrates a scheme for remote USB data processing in a weak network environment:

[0107] 1. System Deployment Steps

[0108] Hardware connection: Insert the USB input device (mouse, keyboard) into the USB interface of the terminal; insert the microcontroller 50 into the USB port of the target server 40 via the USB interface; connect the terminal and the target server 40 via Ethernet 30.

[0109] 2. Data flow and workflow

[0110] (1) Initialization of the microcontroller 50

[0111] After the microcontroller 50 is connected to the target server's USB port 40, a power-on reset process is triggered, which is completed sequentially:

[0112] 1. System Initialization: Initialize the microcontroller 50 core, clock, GPIO ports and USB controller module, and load the basic firmware for USB device simulation;

[0113] 2. Default Device Simulation: Based on the USB protocol specification, a generic default USB device instance is simulated, which includes device vendor identifier (VID) and product identifier (PID) information;

[0114] 3. Basic Link Verification: The default device establishes a one-way communication link with the target server 40. The target server 40 sends a link connectivity test command, and the microcontroller 50 returns an ACK response frame, completing the command interaction and link connectivity verification in the initialization phase, and confirming that the physical connection between the microcontroller 50 and the target server 40 is normal.

[0115] (2) Terminal recognizes USB input device 10

[0116] 1. Physical device connection: When USB input device 10 (mouse, keyboard) is plugged into the USB port of the terminal, the terminal triggers a USB device hot-plug event;

[0117] 2. Device Enumeration and Identification: The terminal calls libusb_init() of the libusb library to initialize the USB context, and enumerates all connected USB devices through libusb_get_device_list() to filter out input devices with device class LIBUSB_CLASS_HID;

[0118] 3. Extracting core parameters: Call libusb_get_device_descriptor() to obtain the device's vendor identifier (VID) and product identifier (PID), and store them in the local cache;

[0119] Binding request sending: The terminal encapsulates a binding request message with the format [frame header (2 bytes) + instruction type (1 byte = 0x01) + VID (2 bytes) + PID (2 bytes) + checksum (1 byte)]. This request is sent to the specified port (e.g., 8888) of the target server 40 via a network socket, so that the target server 40 can accurately locate the USB device to be simulated.

[0120] (3) Establish communication connection

[0121] The terminal establishes a dedicated reliable transmission channel with the anti-weak network server 41 deployed on the target server 40 through the anti-weak network client 22. This protocol is based on the UDP protocol, integrates the KCP algorithm to optimize reliability, and adopts a private encryption algorithm. The transmission channel completes the connection through a three-way handshake (similar to the TCP handshake protocol). The transport layer uses a private encryption algorithm to perform end-to-end encryption processing on the data packets, which not only takes into account the transmission efficiency in the weak network environment, but also effectively prevents data from being tampered with or stolen, and ensures the security of data transmission.

[0122] (4) Hardware information synchronization

[0123] 1. Configure USB input device 10 on the target server (40 servers).

[0124] The target server 40 parses the VID / PID in the binding request message and calls the CreateFile() interface to open the USB input device 10. It then configures the device's usage page (e.g., mouse = 0x01, keyboard = 0x07) and usage ID (e.g., left mouse button = 0x01) through the HidD_SetUsageValue() interface.

[0125] 2. Bind response return

[0126] The target server encapsulates a binding response (bind rsp) message with the format [frame header (2 bytes) + instruction type (1 byte = 0x02) + VID (2 bytes) + PID (2 bytes) + Usage Page (2 bytes) + Usage ID (1 byte) + checksum (1 byte)], and sends it to the terminal through the established encrypted channel.

[0127] 3. Terminal transmission descriptor data

[0128] After receiving the binding response and verifying that the parameters are correct, the terminal sends the following to the target server 40 in sequence:

[0129] Device descriptor: 18 bytes in total, containing device category, VID / PID, protocol version, etc.;

[0130] Configuration descriptor: 9 bytes in total, containing configuration values, etc.

[0131] HID report descriptor: length is as needed (64 bytes for mouse, 32 bytes for keyboard), includes data format, input / output report length, etc.

[0132] 4. Target server 40 checksum and forwarding

[0133] After receiving the descriptor data, the target server 40 verifies the data integrity using the CRC algorithm (comparing the check value with the check bit carried in the message). After the verification is successful, the device descriptor, configuration descriptor, HID message descriptor and other data are forwarded to the microcontroller 50 through the serial port to provide parameter support for the microcontroller 50 to simulate the device.

[0134] (5) A single-chip microcomputer simulates a USB device.

[0135] 1. Descriptor parsing: The microcontroller 50 receives descriptor data forwarded by the target server 40 through the serial port, and calls a custom parsing function to extract key parameters such as VID / PID in the device descriptor, number of interfaces in the configuration descriptor, and data field definitions in the HID report descriptor;

[0136] 2. Embedding of private interface: A custom private communication interface is added to the parsed device descriptor. This interface is independent of the standard USB data interface and is only used for instruction interaction, status synchronization and data transmission between the microcontroller 50 and the target server 40. It does not affect the enumeration and identification of the standard USB input device 10.

[0137] 3. USB bus reset and enumeration response

[0138] The microcontroller 50 calls the USB_ResetBus() function to trigger the USB bus reset process and notify the target server 40 to re-enumerate the device. When the target server 40 initiates the device enumeration process, it completes the enumeration response based on the device description information with the embedded private communication interface, so that the target server 40 operating system 42 can recognize the USB device to be simulated containing the private communication interface.

[0139] (6) One-way transmission of input commands

[0140] The terminal collects raw data (such as keyboard key presses, mouse movement, mouse clicks, etc.) generated by the USB input device 10 (mouse, keyboard) in real time through system libraries (such as libusb library, etc.). By calling the callback function set by the libusb_fill_interrupt_transfer() function, the terminal encapsulates the collected raw data into the format of [frame header + data length + raw data + checksum] and continuously sends it to the target server 40 through the anti-weak network protocol.

[0141] (7) Instruction parsing and hardware signal simulation

[0142] 1. Target server 40 resolution forwarding

[0143] After receiving the raw data from the USB input device 10, the target server 40 quickly performs data verification using the CRC algorithm. Once the verification is successful, the data is forwarded directly to the microcontroller 50 via a custom private communication interface.

[0144] 2. Hardware signal conversion for single-chip microcomputer 50

[0145] USB Data Parsing: The microcontroller 50 device parses the received USB data, extracts payloads such as keyboard key presses, mouse movement, and mouse clicks, and generates transmission messages that conform to the USB class specification.

[0146] USB signal generation: The microcontroller 50 device generates a USB transmission frame through its USB host controller module, which includes a synchronization field (SYNC), packet identifier (PID), address field (ADDR), endpoint field (ENDP), data payload (DATA), and CRC check, and then outputs hardware signals through the USB interface to simulate the transmission of a real USB device.

[0147] Hardware handshake: The USB device interface between the microcontroller 50 and the computing unit verifies the link via USB handshake packets (ACK / NAK / STALL). If data transmission is successful, the target server 40 returns an ACK packet, and the microcontroller 50 continues sending the next data packet. If data transmission fails, the target server 40 returns a NAC packet, and the microcontroller 50 triggers a retransmission mechanism (maximum of 3 retransmissions). If the device malfunctions, the target server 40 returns a STALL packet, and the microcontroller 50 stops data transmission and reports the malfunction to the target server 40.

[0148] 3. Operating system 42 response

[0149] The target server 40 operating system 42 receives hardware signals output by the microcontroller 50 and responds as if processing instructions from a local real USB device (such as mouse movement corresponding to screen cursor movement, and keyboard key presses corresponding to character input).

[0150] (8) Changes to the configuration information of USB input device 10

[0151] 1. Configuration change detection and synchronous write-back

[0152] When the configuration information (such as mouse movement speed) of the USB input device 10 changes, the operating system 42 of the target server 40 receives the configuration modification instruction and sends it to the microcontroller 50 through its own USB interface. After receiving the data, the microcontroller 50 performs verification using the CRC algorithm. After verification, it repackages the stored configuration parameters through the embedded private communication interface and sends them back to the server of the target server 40. After receiving the data packet, the server of the target server 40 performs integrity verification and confirms that the configuration parameters have not been tampered with. The server of the target server 40 encapsulates the verified configuration parameters and sends them to the terminal through the encrypted channel established in step (3).

[0153] 2. Terminal update equipment

[0154] After receiving the configuration parameters and verifying them using the CRC algorithm, the terminal calls the libusb_fill_control_transfer() function to write the configuration parameters to the local USB mouse, thus synchronizing the device configuration status between the terminal and the target server 40. At this point, when the user operates the USB mouse on the terminal, the cursor movement speed on the target server 40 changes synchronously.

[0155] (9) Process cycle and termination

[0156] The terminal continuously collects operation commands from the USB input device and repeatedly executes steps 6 to 7 to achieve real-time transmission and response of USB input device operation commands.

[0157] When the USB input device 10 (mouse, keyboard) is physically removed from the terminal, the terminal immediately sends a device unbind request to the target server 40. After receiving the request, the target server 40 terminates the connection with the microcontroller 50 and releases the device resources, thus terminating the entire device interaction process.

[0158] It should be understood that the specific order or hierarchy of steps in the disclosed process is an example of an exemplary method. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process may be rearranged without departing from the scope of this disclosure. The appended method claims provide elements of various steps in an exemplary order and are not intended to limit the scope to the specific order or hierarchy described.

[0159] In the detailed description above, various features are combined together in a single embodiment to simplify this disclosure. This approach to disclosure should not be construed as reflecting an intention that embodiments of the claimed subject matter require more features than are explicitly stated in each claim. Rather, as reflected in the appended claims, the invention is presented with fewer features than all of the features in a single disclosed embodiment. Therefore, the appended claims are hereby explicitly incorporated into the detailed description, with each claim representing a separate preferred embodiment of the invention.

[0160] Those skilled in the art will also understand that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments herein can be implemented as electronic hardware, computer software, or a combination thereof. To clearly illustrate the interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps described above are generally described in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in alternative ways for each specific application; however, such implementation decisions should not be construed as departing from the scope of this disclosure.

[0161] The steps of the methods or algorithms described in conjunction with the embodiments herein can be directly embodied in hardware, software modules executed by a processor, or a combination thereof. The software modules can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is connected to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. The ASIC can reside in a user terminal. Alternatively, the processor and storage medium can exist as discrete components in the user terminal.

[0162] For software implementation, the techniques described in this application can be implemented using modules (e.g., procedures, functions, etc.) that perform the functions described in this application. This software code can be stored in memory units and executed by a processor. The memory units can be implemented within the processor or outside the processor; in the latter case, they are communicatively coupled to the processor via various means, as is well known in the art.

[0163] The foregoing description includes examples of one or more embodiments. It is certainly impossible to describe all possible combinations of components or methods in order to describe the above embodiments, but those skilled in the art will recognize that the various embodiments can be further combined and arranged. Therefore, the embodiments described herein are intended to cover all such changes, modifications, and variations that fall within the scope of the appended claims. Furthermore, the term "comprising" as used in the specification or claims is interpreted in a manner similar to the term "including," as interpreted when used as a conjunction in the claims. Additionally, the use of any term "or" in the specification of the claims is intended to mean "non-exclusive or."

Claims

1. A remote USB data hardware-level processing method suitable for weak network environments, characterized in that, Includes the following steps: S1, the terminal continuously collects raw data from the physically connected USB input device and continuously sends the raw data unidirectionally to the target server through the anti-weak network communication protocol; S2, After receiving the raw data, the target server forwards the data to the microcontroller connected to the target server through the physical interface; S3, the microcontroller parses and performs hardware-level conversion on the raw data to generate hardware signals that conform to the USB protocol specification; S4, the microcontroller outputs hardware signals to the target server through the USB interface, simulating the input of a real USB device, so that the target server can complete the response to the raw data.

2. The method as described in claim 1, characterized in that, The establishment and transmission process of the anti-weak network communication protocol in step S1 includes: A full-duplex network communication link is constructed based on the UDP protocol and integrated with the KCP algorithm; After establishing a connection through a three-way handshake, the data stream is encrypted end-to-end using a proprietary encryption algorithm at the transport layer. When the terminal sends raw data, it does not need to wait for the target server's network response confirmation to continue sending the next data packet.

3. The method as described in claim 1, characterized in that, Before step S1, a terminal identification and binding step is also included: After the terminal detects the physical connection of the USB input device, it extracts the device's manufacturer and product identifiers. The terminal encapsulates a binding request message containing the manufacturer's identifier and the product identifier, and sends the request to the target server over the network; The target server parses the request message, configures the corresponding USB input device parameters, and returns a binding response message to the terminal.

4. The method as described in claim 3, characterized in that, After the target server returns the binding response message, the process also includes hardware information synchronization and device enumeration steps: The terminal sends the device descriptor, configuration descriptor, and HID report descriptor to the target server in sequence. After verifying the integrity of the descriptor, the target server forwards it to the microcontroller. The microcontroller extracts key parameters and adds a custom private communication interface, independent of the standard USB data interface, to the parsed device descriptor. The microcontroller triggers the USB bus reset process and uses the descriptor information containing the private communication interface to complete the enumeration response to the target server.

5. The method as described in claim 4, characterized in that, In step S2, the process of the target server forwarding data to the microcontroller is as follows: The target server performs a fast CRC check on the received network data packets; After the verification is successful, the target server forwards the raw data directly to the microcontroller through a custom private communication interface.

6. The method as described in claim 1, characterized in that, In steps S3 and S4, the hardware-level conversion and handshake of the microcontroller specifically include: The microcontroller extracts the payload from the raw data and generates a USB transmission frame containing a synchronization field, packet identifier, address field, endpoint field, data payload, and CRC check through the built-in USB host controller module. The microcontroller uses local timing control and directly performs local link verification and retransmission control with the target server via USB handshake packets, replacing the network-level synchronization waiting mechanism.

7. The method as described in claim 4, characterized in that, It also includes steps for changing and synchronizing USB input device configuration information: When the configuration information of the USB input device changes on the target server, the target server will send the configuration modification command to the microcontroller through the USB interface; The microcontroller repackages the configuration parameters through a private communication interface and sends them back to the server of the target server. The server sends the configuration parameters to the terminal via a weak network communication protocol; After receiving and verifying the configuration parameters, the terminal writes the configuration parameters to the locally physically connected USB input device, thus completing bidirectional status synchronization.

8. The method as described in claim 1, characterized in that, It also includes the device unbinding steps: When the USB input device is physically removed from the terminal, the terminal immediately sends a device unbinding request to the target server; Upon receiving the request, the target server terminates the communication connection with the microcontroller and releases the corresponding device resources.

9. A remote USB data hardware-level processing system suitable for weak network environments, characterized in that, include: The terminal is used to collect raw data from USB input devices and send it unidirectionally to the target server via a weak network communication protocol. The target server is used to receive raw data sent by the terminal and relay it. The microcontroller connects to the target server via a physical USB interface. It receives raw data forwarded by the target server, generates hardware-level USB signals, and simulates a real USB device to input data to the target server through local timing control. The target server responds to the command for raw data input.

10. A computer-readable storage medium, characterized in that: A computer program is stored on a computer-readable storage medium, which, when executed by a processor, implements the method as described in any one of claims 1 to 8.

Images