A USB device redirection and data link layer forwarding optimization method, system, device and medium

Abstract

The embodiment of the application discloses a USB device redirection and data link layer forwarding optimization method, system, device and medium, which comprises the following steps: a source end responds to a sharing instruction, manages a target USB device, and sends device information of the target USB device to a destination end; the destination end virtually generates and registers a corresponding virtual USB device according to the device information; the destination end intercepts a USB request initiated by an operating system to the virtual USB device, converts the USB request into a first request message in a custom USB request structure, and sends the first request message to the source end; the source end generates a corresponding first USB request block and sends the first USB request block to the target USB device; the source end receives returned response data, performs differential forwarding processing according to a transmission type, generates a response message, and sends the response message to the destination end; and the destination end completes request response according to the response message. The differential forwarding processing reduces redirection delay, reduces network interaction, and improves user experience. The method improves transmission efficiency and operation fluency of remote sharing of the USB device.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, system, device, and medium for USB device redirection and data link layer forwarding optimization. Background Technology

[0002] With the rapid development of cloud computing and remote work technologies, the demand for remote sharing of USB devices is growing. Universal Serial Bus (USB), as the de facto standard for electronic device connectivity, is widely used in various peripherals such as human-computer interaction devices, storage devices, and audio / video capture devices. However, the traditional USB protocol, based on a local physical connection design, inherently has physical distance limitations and cannot directly achieve device sharing across networks.

[0003] While existing USB redirection technology enables remote access through network encapsulation of the USB protocol, it exposes significant drawbacks in weak network environments. Specifically, the USB protocol uses a serial request-response mechanism, and network latency directly doubles the interval between requests. For latency-sensitive devices such as graphics tablets and game controllers, this severely degrades the user experience. Furthermore, the large number of high-frequency small packets generated by interrupted and isochronous transmissions are transmitted independently in the network link, resulting in low bandwidth utilization and exacerbating network congestion. In scenarios such as cloud desktops, cursor position information relies on network feedback, and latency can cause the cursor to become unresponsive. When using USB redirection, the local system cannot directly obtain coordinate information because the data is forwarded over the network, resulting in a poor cursor display experience. Summary of the Invention

[0004] This application provides a USB device redirection and data link layer forwarding optimization method, system, device, and medium. Through source-end device management, destination-end virtual registration, and bidirectional request message conversion, it enables the sharing of physical USB devices across hosts. At the same time, based on the differentiated forwarding processing of transmission type, it can perform targeted scheduling of response data, thereby reducing redundant small packet transmission, reducing invalid waiting time, and improving response speed and bandwidth utilization in weak network environments.

[0005] In a first aspect, embodiments of this application provide a USB device redirection and data link layer forwarding optimization method, applied to a system including a source end and a destination end, wherein the source end is connected to a physical USB device, and the method includes: The source end responds to the USB device sharing command, manages the target USB device, obtains the device information of the target USB device, and sends the device information to the destination end; The destination device generates a virtual USB device corresponding to the target USB device based on the received device information, and registers the virtual USB device with the operating system of the destination device. The destination intercepts the USB request initiated by the operating system to the virtual USB device, converts the USB request into a first request message, and sends it to the source. The source end generates a corresponding first USB request block based on the received first request message, and sends the first USB request block to the target USB device; The source end receives the response data returned by the target USB device, performs differentiated forwarding processing on the response data according to the transmission type in the first request message corresponding to the response data to obtain a response message, and sends the response message to the destination end; The destination terminal completes the response to the USB request based on the response message; The first request message and the response message adopt a custom USB request structure.

[0006] Furthermore, the differentiated forwarding process includes accelerated forwarding, which includes: After sending the first request message to the source, the destination intercepts subsequent USB requests of the same type as the first request message initiated by the operating system, and temporarily suspends the intercepted subsequent USB requests. After receiving the first request message, the source end saves a copy of the first request message locally. After receiving the response data returned by the target USB device, the source end uses the copy to trigger a new USB request locally, so that the response data of the target USB device continues to be generated.

[0007] Furthermore, the differentiated forwarding process also includes merged forwarding, which includes: The source end merges multiple response data returned by the target USB device within a preset time period into an aggregated response message, and the aggregated response message contains a set of multiple USB response data. The source end sends the aggregated response message to the destination end; After receiving the aggregated response message, the destination device parses out each independent USB response data and completes the response to the corresponding USB request one by one. The preset time period is determined according to the transmission type of the target USB device.

[0008] Furthermore, the management target USB device includes taking over the target USB device, and the taking over the target USB device includes: A hub filter driver is added on top of the USB hub driver layer at the source end. The hub filter driver intercepts the device enumeration request of the source operating system's device enumeration manager for the target USB device. The hub filter driver rewrites the vendor identification code and product identification code of the target USB device into the vendor identification code and product identification code of the takeover driver, so that the device enumeration manager matches the target USB device to the takeover driver; The takeover driver takes over the target USB device, creates a corresponding functional device object, and attaches it to the top layer of the target USB device's device stack.

[0009] Further, the virtual generation of a virtual USB device corresponding to the target USB device at the destination end includes: At the destination, a virtual root bus device, a virtual USB host controller device, and a virtual USB hub device are created sequentially. The destination device enumeration manager enumerates the virtual root bus device, the virtual USB host controller device, and the virtual USB hub device; Based on the received device information, a virtual USB physical device object corresponding to the target USB device is created under the virtual USB hub device; The device enumeration manager at the destination end enumerates the virtual USB physical device object and matches the upper-layer client driver for the virtual USB physical device object.

[0010] Furthermore, the differentiated forwarding processing also includes local cursor echoing, which includes: When the target USB device is a pointer input device that conforms to the human-computer interaction device protocol, the source end parses the human-computer interaction device message in the response data and extracts coordinate information from the human-computer interaction device message according to the human-computer interaction device descriptor of the target USB device; The source end writes the extracted coordinate information into its local cursor, and hides the cursor of the destination end while displaying the local cursor on the source end.

[0011] Furthermore, intercepting subsequent USB requests of the same type as the first request message initiated by the operating system includes: The destination intercepts the device request block initiated by the operating system to the virtual USB device, and parses the request type, endpoint address and transmission direction of the device request block; The device request block whose request type is interrupted transfer or isochronous transfer, and whose transfer direction is from the virtual USB device to the operating system, is marked as a candidate request; When the frequency of candidate requests for the same endpoint address exceeds a frequency threshold within a preset time window, the corresponding candidate request is determined to be a USB request of the same type as the first request message, and subsequent USB requests of the same type are intercepted.

[0012] In a second aspect, embodiments of this application provide a USB device redirection and data link layer forwarding optimization system, including a source end and a destination end, wherein the source end is connected to a physical USB device; The source end includes a USB device management module and a first forwarding module, and the destination end includes a USB virtual device module and a second forwarding module; The USB device management module is connected to the physical USB device and the first forwarding module. The first forwarding module and the second forwarding module are connected via a data link. The second forwarding module is connected to the USB virtual device module. The USB virtual device module is connected to the operating system of the destination end. The system is used to implement the USB device redirection and data link layer forwarding optimization method as described in the first aspect.

[0013] In a third aspect, embodiments of this application provide a computer device, including: a memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the USB device redirection and data link layer forwarding optimization method as described in the first aspect.

[0014] In a fourth aspect, embodiments of this application provide a storage medium for storing computer-executable instructions, which, when executed by a computer processor, are used to perform the USB device redirection and data link layer forwarding optimization method as described in the first aspect.

[0015] This application embodiment intercepts and postpones subsequent USB requests of the same type as the first request message initiated by the operating system at the destination end, while saving a copy of the request at the source end and triggering a new request locally using the copy after receiving a response. This allows the target USB device to continuously generate response data without waiting for network round trips, thus reducing the request-response interval of interrupted transmission and isochronous transmission devices in high-latency network environments and improving the smoothness of use for latency-sensitive devices. Multiple response data returned within a preset time period are merged into an aggregated response message for transmission, and the preset time period and merging strategy are adaptively determined according to different transmission types, reducing the number of small packets in the network, improving bandwidth utilization, and reducing the probability of network congestion. Furthermore, by merging continuously offset return data in batch transmission... Furthermore, it further optimized the performance of continuous small-range read operations on storage devices; when the target USB device is a pointer input device of the human-machine interaction device protocol, by parsing the human-machine interaction device protocol message in the response data and extracting the coordinate information to write to the local cursor at the source end, it realized local cursor echo, avoiding the cursor not following the hand problem caused by network latency, and improving the user experience in cloud desktop and remote control scenarios; it adopted a custom USB request structure and rewrote the device identification code through the hub filter driver at the source end to realize device takeover, and realized device virtualization at the destination end by creating a virtual root bus, host controller and hub device layer by layer, thus building a complete USB device redirection architecture, ensuring the efficiency and reliability of request proxy and data forwarding between physical USB devices and virtual USB devices. Attached Figure Description

[0016] Figure 1 This is a flowchart of a USB device redirection and data link layer forwarding optimization method provided in an embodiment of this application; Figure 2 This is a topology diagram of the physical USB device on the source host device provided in the embodiments of this application; Figure 3 This is an architecture diagram of USB device redirection and data link layer forwarding provided in the embodiments of this application; Figure 4 This is a flowchart of the accelerated forwarding method provided in the embodiments of this application; Figure 5 This is a flowchart of the merging and forwarding method provided in the embodiments of this application; Figure 6 This is a flowchart illustrating the takeover of the target USB device provided in an embodiment of this application; Figure 7 This is a flowchart illustrating the virtual USB device generated at the destination end, corresponding to the target USB device, provided in an embodiment of this application. Figure 8 This is a flowchart of the cursor local echo method provided in the embodiments of this application; Figure 9 This is a flowchart illustrating the interception of a USB request initiated by the operating system that is the same type as the first request message, provided in an embodiment of this application. Figure 10 This is a structural block diagram of a USB device redirection and data link layer forwarding optimization system provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but additional steps not included in the drawings may also be present. The above processes can correspond to methods, functions, procedures, subroutines, subroutines, etc.

[0018] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0019] The USB device redirection and data link layer forwarding optimization method provided in this application is applied to a system including a source end and a destination end, wherein the source end is connected to a physical USB device. This method achieves remote sharing of physical USB devices across hosts through source end management and information acquisition of the physical USB device, destination end generation and registration of virtual USB devices, bidirectional request message conversion and forwarding, and differentiated forwarding processing based on transmission type.

[0020] Figure 1This is a flowchart of a USB device redirection and data link layer forwarding optimization method provided in an embodiment of this application, such as... Figure 1 As shown, the USB device redirection and data link layer forwarding optimization method includes: Step 101: The source end responds to the USB device sharing command, manages the target USB device, obtains the device information of the target USB device, and sends the device information to the destination end.

[0021] In this context, "source end" refers to the host end where the actual physical USB device is inserted. USB device sharing commands can be user-triggered commands triggered through the user interface on the source end, or commands triggered by a preset automatic sharing policy; this embodiment does not limit this. "Target USB device" refers to one or more USB devices selected from the physical USB devices connected to the source end for sharing to the destination end. "Device information" refers to attribute information describing the target USB device, including but not limited to vendor identifier, product identifier, USB device descriptor, USB configuration descriptor, interface descriptor, and endpoint descriptor. The USB device descriptor includes the USB protocol version, device category, device subcategory, device protocol, and maximum data packet size; the USB configuration descriptor includes the number of interfaces, configuration values, configuration string index, bus power supply or self-power supply attributes, and maximum power consumption.

[0022] In one embodiment, when a user or upper-layer application initiates a USB device sharing command, managing the target USB device refers to the source end performing operations on the target USB device to put it into a state that can be remotely shared. This includes monitoring all plugged-in physical USB devices on the source end, filtering USB devices that are not allowed to be shared according to preset rules, selecting the target USB device from the allowed sharing devices, and taking over the target USB device to put it into a ready-to-share state. After obtaining the device information of the target USB device, the source end sends the device information to the destination end via a network or other data link transmission method.

[0023] Step 102: The destination end generates a virtual USB device corresponding to the target USB device based on the received device information, and registers the virtual USB device with the destination end's operating system.

[0024] In this context, the destination refers to the host that remotely receives the shared USB device. A virtual USB device is a logical USB device simulated at the destination and possessing the same device attributes as the target USB device.

[0025] In one embodiment, the destination end creates a virtual USB device corresponding to the target USB device in its operating system based on the received device information, and registers the virtual USB device with the destination end's operating system. This allows the destination end's operating system to recognize and load the corresponding driver, thereby making the virtual USB device available to the user. Registering the virtual USB device with the destination end's operating system involves the destination end using the plug-and-play mechanism provided by the operating system to register the virtual USB device information with the operating system's device manager. This allows the operating system to enumerate the virtual USB device and match and load the corresponding upper-layer client driver based on the device information, thus completing the initialization and activation of the virtual USB device.

[0026] Step 103: The destination intercepts the USB request initiated by the operating system to the virtual USB device, converts the USB request into a first request message, and sends it to the source.

[0027] In this context, a USB request refers to a request sent by the destination operating system to a virtual USB device to obtain device data or control device behavior. In Windows operating systems, a USB request is specifically represented as a USB Request Block (URB), a data structure within the operating system kernel used to uniformly represent and manage all USB requests.

[0028] In one embodiment, the destination end intercepts the USB request initiated by the operating system to the virtual USB device through a virtual USB device module, converts the USB request into a first request message with a custom USB request structure, and sends it to the source end via network or other data link transmission methods. The custom USB request structure is a predefined data structure used for transmitting USB request information over a network, including but not limited to fields such as request identifier, request type, endpoint address, transmission direction, data length, data payload, status code, and timestamp. Using a custom USB request structure for message transmission can mask the differences in the underlying URB implementations of different operating systems, enabling cross-platform USB device redirection.

[0029] Step 104: The source generates a corresponding first USB request block based on the received first request message and sends the first USB request block to the target USB device.

[0030] The first USB request block refers to the USB request block (URB) reconstructed by the source end based on the received first request message and sent to the target USB device. In this embodiment, the source end parses the information of each field in the first request message, generates the corresponding first USB request block according to the parsing result, and sends the first USB request block to the target USB device to drive the target USB device to perform corresponding data reading or control operations.

[0031] Step 105: The source end receives the response data returned by the target USB device, performs differentiated forwarding processing on the response data according to the transmission type in the first request message corresponding to the response data to obtain a response message, and sends the response message to the destination end.

[0032] In one embodiment, the response data is the data returned by the target USB device after receiving the first USB request block and performing corresponding operations based on the request content. The transfer type refers to the four data transfer types defined in the USB protocol: control transfer, bulk transfer, interrupt transfer, and isochronous transfer. Control transfers are used for device configuration and command transmission and have the highest priority; bulk transfers are used for large-scale data transmission, ensuring data integrity but not bandwidth or latency; interrupt transfers are used for small, periodic data transmissions, ensuring a latency ceiling; and isochronous transfers are used for real-time audio and video data transmission, ensuring bandwidth and periodicity but not data integrity. Differentiated forwarding processing involves the source end performing different forwarding strategies on the response data returned by the target USB device according to the transfer type indicated in the first request message. These strategies may include accelerated forwarding, merged forwarding, and local cursor echoing. After performing differentiated forwarding processing, the source end sends the processed response message to the destination end via a network or other data link transmission method.

[0033] Step 106: The destination end completes the response to the USB request based on the response message.

[0034] In one embodiment, after receiving the response message from the source, the destination parses the data content in the response message and completes the response operation for the corresponding USB request based on the parsing result. Specifically, the destination writes the data in the response message into the data buffer of the corresponding URB request, sets the completion status of the URB request, and reports to the upper-layer operating system that the USB request has been completed, thereby enabling the operating system to obtain the data returned by the target USB device and complete the entire USB request and response cycle.

[0035] Figure 2 This is a topology diagram of the physical USB device on the source host device provided in the embodiments of this application, such as... Figure 2As shown, optionally, a USB host controller chip 8013 is mounted on the peripheral component interconnect bus 8014 on the host motherboard. The USB host controller chip 8013 can be an Enhanced Host Controller Interface (EHCI) chip or an eXtensible Host Controller Interface (XHCI) chip. A USB hub 8012 (Root Hub) is connected to the USB host controller chip 8013. The USB hub 8012 provides multiple USB ports for connecting various physical USB devices (1-N), such as USB keyboards, USB mice, USB storage devices, USB cameras, USB microphones, USB graphics tablets, etc.

[0036] Figure 3 This is an architecture diagram of USB device redirection and data link layer forwarding provided in the embodiments of this application, such as... Figure 3 As shown, the USB device redirection scheme is divided into a source end and a destination end. The source end is the local host, where the physical USB device is plugged in. The destination end is a remote host, where the physical USB device plugged in the source end is redirected and forwarded to the destination end. The USB data packets from the source end are forwarded to the destination end via the network or other data link transmission methods, making the local physical USB device appear as if it were plugged into the destination host across multiple hosts.

[0037] In an optional embodiment, managing the target USB device includes taking over the target USB device. Figure 6 This is a flowchart illustrating the takeover of the target USB device provided in an embodiment of this application, such as... Figure 6 As shown, it includes: Step 401: Attach a hub filter driver on top of the source-side USB hub driver layer.

[0038] The USB hub driver layer is the driver layer in the source operating system used to manage USB hub devices. The hub filter driver is a filter driver attached to the USB hub driver layer, used to intercept and monitor input / output request packets related to the USB hub device. Specifically, the hub filter driver attaches to the USB hub driver layer by calling the driver attachment interface provided by the operating system, thereby intercepting all device enumeration requests and responses passing through the USB hub driver layer.

[0039] Step 402: Intercept the device enumeration request of the target USB device by the device enumeration manager of the source operating system through the hub filter driver.

[0040] The device enumeration manager refers to the component in the operating system used to enumerate and manage hardware devices; in Windows, this is specifically the Plug and Play Manager. A device enumeration request is a request sent by the device enumeration manager to the USB hub driver to obtain USB device information, including but not limited to requests to obtain device descriptors, configuration descriptors, and string descriptors. Specifically, the hub filter driver can intercept these device enumeration requests to obtain the raw device information of the target USB device and modify this information.

[0041] Step 403: The hub filter driver rewrites the vendor identification code and product identification code of the target USB device to the vendor identification code and product identification code of the takeover driver, so that the device enumeration manager matches the target USB device to the takeover driver.

[0042] The vendor identifier (VID) is the identifier for the USB device manufacturer, assigned by the USB Implementers Forum. The product identifier (PI) is the identifier assigned by the USB device manufacturer for its product. In this embodiment, when enumerating USB devices, the device enumeration manager matches the corresponding driver based on the device's VID and product identifier. After intercepting a device enumeration request to obtain a device descriptor, the hub filter driver rewrites the original VID and product identifier of the target USB device to the pre-set VID and product identifier of the takeover driver. When the device enumeration manager searches for a matching driver based on the rewritten VID and product identifier, it will find the takeover driver, thus handing over the management of the target USB device to the takeover driver.

[0043] Step 404: The takeover driver takes over the target USB device, creates the corresponding functional device object, and attaches it to the top layer of the target USB device's device stack.

[0044] In this context, the takeover driver refers to a custom driver program pre-developed and installed on the source operating system for taking over the target USB device. The takeover driver has its own unique vendor and product identifiers, used to match the device identifiers rewritten by the hub filter driver. In this embodiment, when the device enumeration manager calls the AddDevice function in the takeover driver's driver extension, it passes the Physical Device Object (PDO) representing the target USB device as a parameter. Inside the AddDevice function, the takeover driver first performs basic checks to confirm whether the passed PDO is a correct USB device and whether it is the type of device the takeover driver should take over. If the check fails, it returns failure directly. After the check passes, the takeover driver obtains the top-level device object in the target USB device's device stack and creates its own Functional Device Object (FDO) based on the type of the top-level device. The FDO represents a specific function of a device; it is not concerned with the physical state of the underlying physical devices, only with their specific functions. The takeover driver attaches the created FDO to the top of the target USB device's PDO device stack. Then, the takeover driver obtains the USB driver interface handle by calling the USBD_CreateHandle function and registers the takeover driver with the underlying USB driver stack. At this point, the target USB device is successfully taken over and enters a ready-to-share state.

[0045] In this embodiment, after the takeover driver takes over the target USB device, the application layer kernel on the source end sends the USB data request to the takeover driver by calling the WriteFile function. The takeover driver constructs different USB Request Blocks (URBs) according to different request types, and then sends the URBs to the lower-level PDO. For control transfers, the takeover driver will wait until the URB is successfully completed before returning to the application layer. For bulk transfers, interrupted transfers, and isochronous transfers, the takeover driver puts the request into a global wait queue, sets the completion function, sends the URB, and returns immediately. In the completion function, the takeover driver determines whether the application layer has a read request. If not, it puts the request into the global completion queue, waiting for the application layer kernel to retrieve the result and data returned by the completed URB request; if there is a read request, it writes the completed USB data into the read buffer. The application layer core uses the `ReadFile` function to read the return results and data of the USB requests previously sent to the takeover driver. The takeover driver first checks the global completion queue. If there are no completed USB requests in the queue, it directly returns `STATUS_PENDING` to the application layer (a status code defined by the Windows operating system kernel, indicating that the operation is still in progress and has not yet been completed). If there is a completed USB request, it removes the completed USB request from the global queue and then writes the completed USB data into the read buffer. If the length read by the application layer is less than the actual USB data length, it records the actual offset read by the application layer. The next time the application layer reads, it continues reading from the previous offset until all USB data has been read.

[0046] In another alternative embodiment, the destination end virtually generates a virtual USB device corresponding to the target USB device. Figure 7 This is a flowchart illustrating the virtual USB device generated at the destination end, corresponding to the target USB device, provided in an embodiment of this application. Figure 7 As shown, it includes: Step 501: Create a virtual root bus device, a virtual USB host controller device, and a virtual USB hub device sequentially on the destination end.

[0047] In this context, the virtual root bus device refers to a root bus device object simulated and created in the destination operating system, serving as the root node of the entire virtual USB device tree. The virtual USB host controller device refers to a USB host controller device object simulated and created under the virtual root bus device, used to simulate the functionality of a USB host controller chip. The virtual USB hub device refers to a USB hub device object simulated and created under the virtual USB host controller device, used to simulate the functionality of a USB hub. Specifically, the application layer kernel on the destination end installs the corresponding drivers for the virtual root bus device, virtual USB host controller device, and virtual USB hub device by calling the Setup application programming interface (API), and then notifies the PNP manager to create the physical device object (PDO) for the virtual root bus device through the Setup API.

[0048] Step 502: The device enumeration manager at the destination end enumerates the virtual root bus device, the virtual USB host controller device, and the virtual USB hub device.

[0049] In this embodiment, after receiving a notification to create a virtual root bus device (PDO), the Device Enumeration Manager (PNP Manager) calls the AddDevice function of the corresponding driver object of the virtual root bus device, passing in the PDO. Internally, the AddDevice function creates the corresponding FDO device for the virtual root bus device and appends it to the top of the PDO stack, then creates the PDO for the virtual USB host controller device. The PNP Manager then queries the virtual root bus device about its device relationships. The virtual root bus device informs the PNP Manager that it has a child device (i.e., the virtual USB host controller device) and passes the PDO of the virtual USB host controller device to the PNP Manager. In this embodiment, the PNP Manager begins initializing the PDO of the virtual USB host controller device, querying information such as the device's friendly name, instance identifier, hardware identifier, and compatibility identifier. The friendly name is used to include the most specific description of the device for easy reading; the instance identifier is used to globally and uniquely identify the device and cannot be duplicated; the hardware identifier and compatibility identifier are used by the PNP Manager to find a matching driver for the device. The PNP manager also inquires whether the PDO supports locking or popping, whether it supports certain interfaces, and the resources required by the device, including input / output port addresses, interrupt vectors, and bus-relative memory address blocks. After completing all initialization tasks, the PNP manager sends an IRP_MN_DEVICE_ENUMERATED notification (a command sent by the PNP manager to the device driver in Windows operating systems, indicating that the device enumeration process is complete) to the PDO, informing it that the PDO device has been successfully enumerated by the PNP manager.

[0050] In this embodiment, after the virtual USB host controller device PDO is successfully enumerated, the PNP manager calls the AddDevice function of the driver matching the PDO. The AddDevice function internally creates the FDO device corresponding to the PDO and attaches it to the top of the PDO's stack, then creates the PDO of the virtual USB hub device. The PNP manager queries the virtual USB host controller device for device relationships. The virtual USB host controller device informs the PNP manager that it has a child device (i.e., the virtual USB hub device) and passes its PDO to the PNP manager. The PNP manager performs the same initialization work on the virtual USB hub device's PDO as it does on the virtual USB host controller device's PDO. After the virtual USB hub device PDO is successfully enumerated, the PNP manager calls the AddDevice function of the driver matching the PDO. The AddDevice function internally creates the FDO device corresponding to the PDO and attaches it to the top of the PDO's stack. At this point, no USB device is plugged into the virtual USB hub device, and the virtual USB hub device returns an empty device relationship queue, informing the PNP manager that it has no child device. The initialization work of the virtual USB device driver is thus completed.

[0051] Step 503: Based on the received device information, create a virtual USB physical device object corresponding to the target USB device under the virtual USB hub device.

[0052] Specifically, the source end informs the destination end via network or other data link methods to begin forwarding the specified USB device, and sends the target USB device's device information to the destination end. This device information includes the target USB device's vendor identifier, product identifier, USB device descriptor, and USB configuration descriptor. Upon receiving the new USB device insertion request, the application layer kernel at the destination end sends a Device I / O Control Request to the virtual USB hub device, requesting that the target USB device be inserted into the virtual USB hub device. Upon receiving the DeviceIoControl (device I / O control function provided by the Windows operating system) request, the virtual USB hub device creates a new virtual USB physical device object (PDO) and then notifies the PNP manager that its sub-device has changed.

[0053] Step 504: The device enumeration manager at the destination end enumerates the virtual USB physical device object and matches the upper-layer client driver for the virtual USB physical device object.

[0054] Specifically, after the PNP manager learns that a sub-device of the virtual USB hub device has changed, it queries the virtual USB hub device for its device relationships. At this point, the virtual USB hub device informs the PNP manager that it has a newly added sub-device, namely the virtual USB physical device object corresponding to the target USB device. The PNP manager begins initializing the PDO of the virtual USB physical device object, querying information such as the friendly name, instance identifier, hardware identifier, and compatibility identifier of the PDO. Based on the hardware identifier and compatibility identifier of the PDO, the PNP manager searches for the upper-level client driver that matches the virtual USB device, and then calls the AddDevice function of that client driver. This client driver is not the virtual USB device driver itself, but a standard USB client driver provided by the operating system or device manufacturer, located above the virtual USB device driver. Internally, the client driver creates an FDO according to the operating system specifications and attaches it to the PDO device stack of the virtual USB physical device object. After performing custom operations, the AddDevice function returns successfully. The PNP manager sends an IRP_MN_START_DEVICE request (a command sent by the Plug and Play Manager to the device driver in Windows, indicating that the device should be started) to the top of the virtual USB physical device object's device stack, notifying all devices in the stack that the virtual USB device PDO has been enabled. After the virtual USB physical device object is successfully enabled, the upper-layer client driver sends various USB input and output requests to the lower-layer PDO in the form of URB requests. The PDO places these URB requests into a global queue and an unretrieved queue, waiting for the application layer kernel to retrieve them via read requests. When the application layer kernel reads data using the ReadFile method, the virtual USB device driver converts the URB request into a custom USB request structure and returns it to the application layer, removing the URB from the unretrieved queue and placing it into the retrieved queue. When the application layer kernel writes input using the WriteFile method, the virtual USB device driver, after verifying the validity of the written data, completes the corresponding URB request (write status and data) based on the written USB request and removes it from all global queues.

[0055] Figure 4 This is a flowchart of the accelerated forwarding method provided in the embodiments of this application, such as... Figure 4 As shown, the USB device redirection and data link layer forwarding optimization method includes: Step 201: After sending the first request message to the source, the destination intercepts subsequent USB requests of the same type as the first request message initiated by the operating system, and temporarily suspends the processing of the intercepted subsequent USB requests.

[0056] In this context, "same type USB requests" refers to USB requests with the same request type, endpoint address, and transmission direction. In USB redirection scenarios, for interruptible and isochronous transfer devices, the operating system periodically initiates the same type of USB requests to the device to obtain device data. For example, HID (Human Interface Device) devices such as mice and keyboards periodically initiate interruptible transfer requests to obtain input data, while USB cameras and microphones periodically initiate isochronous transfer requests to obtain audio and video data. When network latency increases, the time interval between consecutive requests increases accordingly, leading to a decrease in the frequency of device data acquisition and a degraded user experience. Accelerated forwarding intercepts subsequent USB requests of the same type at the destination, avoiding redundant network transmissions and thus reducing the impact of latency.

[0057] In one embodiment, the destination intercepts a Device Request Block (URB) initiated by the operating system to the virtual USB device and parses the request type, endpoint address, and transmission direction of the URB. URBs with request types of interrupted or isochronous transfers and transmission directions from the virtual USB device to the operating system are marked as candidate requests. When the frequency of candidate requests with the same endpoint address within a preset time window exceeds a frequency threshold, the candidate request is determined to be a USB request of the same type as the first request message. For subsequent USB requests determined to be of the same type, the destination intercepts them and places them in a deferred queue for deferred processing. Instead of sending them to the source over the network, the destination waits for response data from the source to complete the response to these deferred USB requests.

[0058] Step 202: After receiving the first request message, the source end saves a copy of the first request message locally. After receiving the response data returned by the target USB device, the source end uses the copy to trigger a new USB request locally, so that the response data of the target USB device continues to be generated.

[0059] In one embodiment, after receiving a first request message, the source end parses the content of the first request message and saves a copy of the first request message in its local memory. The source end generates a corresponding first USB request block based on the first request message and sends it to the target USB device. The target USB device performs the corresponding operation and returns response data. After receiving the response data returned by the target USB device, the source end determines whether the response data is a response to the request corresponding to the locally saved copy. If it is a response to the request corresponding to the locally saved copy, the source end processes the response data and sends it to the destination end. Simultaneously, it triggers a new USB request locally using the locally saved copy. That is, the source end does not need to wait for the destination end to send another request; it directly uses the copy to construct a new USB request block and sends it to the target USB device. After receiving the new USB request block, the target USB device continues to return response data. This cycle repeats, allowing the target USB device to continuously generate response data without waiting for network round-trip latency. The source continuously sends response data from the target USB device to the destination. The destination then completes the response to the temporarily suspended USB request based on the received response data, thereby accelerating forwarding. Through this accelerated forwarding strategy, the original request and response mode, which relied on network round trips, is transformed into a source-side local loop mode. For example, when the network latency is 50ms, in the traditional method, the difference between two requests is 100ms (50ms request + 50ms response). However, with accelerated forwarding, the interval of the source-side local loop depends only on the response speed of the USB device itself, and can usually be shortened to less than 10ms, improving the smoothness of using latency-sensitive devices.

[0060] As mentioned above, accelerated forwarding is achieved by using local proxy requests, saving a copy of the request locally at the source end, and triggering new requests in a loop. This eliminates the limitation of network round-trip latency on the request frequency, allowing latency-sensitive devices (such as drawing tablets, game controllers, etc.) to maintain a high data refresh rate even in high-latency network environments, thus improving the user experience.

[0061] Figure 5 This is a flowchart of the merging and forwarding method provided in the embodiments of this application, such as... Figure 5 As shown, the USB device redirection and data link layer forwarding optimization method includes: Step 301: The source end merges multiple response data returned by the target USB device within a preset time period into an aggregated response message, which contains a collection of multiple USB response data.

[0062] In this context, an aggregated response message refers to a single network message formed by combining multiple independent USB response data packets. In USB redirection scenarios, interrupted transmissions and isochronous transfers generate a large number of high-frequency small data packets. If each packet is transmitted independently, it will result in significant network header overhead, reduced bandwidth utilization, and exacerbated network congestion. Merging and forwarding reduces the number of packets in the network and improves bandwidth utilization by combining multiple small data packets into a single large packet for transmission.

[0063] In one embodiment, after receiving response data from the target USB device, the source determines whether the response data is a response generated by a local proxy request in accelerated forwarding. If it is a response generated by a local proxy request, the response data is placed into a pending response queue one by one. The source determines a preset time period based on the transmission type of the target USB device, and decides whether to package and send the data in the pending response queue based on the preset time period. Optionally, for interrupt transmission devices with high requirements for low latency (mainly HID human interface devices, such as keyboards, mice, game controllers, graphics tablets, etc.), the source starts a timer before putting USB data into the queue. The timer's time is set much lower than human reaction time. Once the timer reaches the set time, regardless of whether there is new data in the queue, the source packages all data in the current queue into a large aggregated response message. For isochronous transmission devices with high latency requirements (such as USB microphones and USB cameras), the source end simultaneously sets the maximum capacity of the queue and starts a timer with a shorter duration. When the USB data reaches the maximum queue capacity or the timer reaches the set time, the source end packages all data in the current queue into a large aggregated response message, thus ensuring smooth video or audio transmission. For batch transmission devices that are not sensitive to latency, the source end starts a timer before adding USB data to the queue, and the timer duration is set to a relatively long duration. Simultaneously, the source end merges consecutively offset return data, combining multiple consecutive return data into a single return data, further reducing network data volume. This optimization effect is more significant for continuous and intensive small-scale read operations.

[0064] Step 302: The source end sends the aggregated response message to the destination end.

[0065] In one embodiment, the source sends the generated aggregated response message to the destination via a network or other data link. The aggregated response message contains a collection of multiple USB response data, each of which is identified by the corresponding original request information so that the destination can correctly parse and distribute it.

[0066] Step 303: After receiving the aggregated response message, the destination end parses out the individual USB response data and completes the response to the corresponding USB request one by one.

[0067] In one embodiment, after receiving the aggregated response message, the destination first determines whether the response message is a merged large request packet. If it is a merged aggregated response message, the destination parses the aggregated response message and splits it into individual USB response data. The destination sends each of the parsed individual USB response data to the virtual USB device one by one. The virtual USB device then notifies the operating system that new USB data has been generated, thereby completing the response to the corresponding USB request one by one. For USB requests that are intercepted and temporarily deferred during accelerated forwarding, the destination uses the parsed USB response data to complete the response to these requests sequentially, enabling the operating system to obtain the data returned by the target USB device. Through the above-described merged forwarding strategy, the number of small packets in the network is significantly reduced. For example, for a graphics tablet device, assuming 100 interrupted data transmissions are generated per second, each data is 8 bytes, and 100 network packets need to be sent in the traditional way; after adopting merged forwarding, packets are packed every 50ms, and only 20 aggregated messages need to be sent per second, each aggregated message is about 40 bytes, reducing the number of network packets and lowering network overhead.

[0068] As mentioned above, merging and forwarding further improves network utilization on the basis of accelerated forwarding. It combines multiple dense small packets into one large packet for transmission, reducing the number of small packets in the network and lowering the probability of network congestion. At the same time, it adaptively determines the preset time period and merging strategy according to different transmission types, taking into account the different needs of latency-sensitive and bandwidth-sensitive devices.

[0069] Figure 8 This is a flowchart of the cursor local echo method provided in the embodiments of this application, such as... Figure 8 As shown, the USB device redirection and data link layer forwarding optimization method includes: Step 601: When the target USB device is a pointer input device that conforms to the human-machine interaction device protocol, the source end parses the human-machine interaction device message in the response data and extracts the coordinate information from the human-machine interaction device message according to the human-machine interaction device descriptor of the target USB device.

[0070] The Human Interface Device (HID) protocol is a type of device protocol defined in the USB protocol, used to standardize the data format and communication methods of input devices such as keyboards, mice, game controllers, and graphics tablets. Pointer input devices refer to input devices capable of generating pointer position information, such as mice, graphics tablets, and touchscreens. An HID descriptor is a mandatory descriptor for HID devices, used to describe information such as the HID device's report type, report length, purpose page, and intended use. HID messages are input data messages reported by HID devices according to the format defined by the HID descriptor, containing device input status information such as button status and coordinate position.

[0071] In one embodiment, when the target USB device is a pointer input device conforming to the HID protocol, the source device parses the HID message content in the response data after receiving it from the target USB device. The source device extracts the pointer coordinate information from the HID message based on the purpose page and purpose information defined in the target USB device's HID descriptor. Specifically, the HID descriptor defines the purpose pages and purpose identifiers for the X and Y axes, and the source device extracts the X-axis and Y-axis coordinate values ​​from the corresponding data fields of the HID message based on these identifiers. For pressure-sensitive tablet devices, pressure-sensitive information can also be extracted from the HID message based on the pressure-sensitive purpose identifier defined in the HID descriptor.

[0072] Step 602: The source end writes the extracted coordinate information into the local cursor of the source end, and hides the cursor of the destination end while displaying the local cursor on the source end.

[0073] In one embodiment, the source device writes the extracted coordinate information to its local cursor position via an application programming interface provided by the operating system. This causes the source device's local cursor to move along with the pointer input device. Simultaneously, the source device sends a cursor hiding command to the destination device over the network, instructing the destination device to hide its local cursor. Alternatively, the destination device automatically hides its cursor when it detects that the currently used USB device is a pointer input device. This allows the user to directly see the cursor movement on the source device when operating it, without waiting for network latency to cause the cursor to echo on the destination device.

[0074] As mentioned above, in cloud desktop and remote control scenarios, cursor display typically employs two basic schemes. Optionally, Scheme 1 displays the cursor on the source end and hides the cursor on the destination end, sending the source end cursor information to the destination end and injecting it into the destination end via a system interface; Scheme 2 displays the cursor on the destination end and hides the source end cursor, sending the source end cursor information to the destination end and injecting it into the destination end via a system interface, then capturing and displaying the destination end cursor information back to the source end. Due to network latency, there is a delay in image display, and Scheme 2 can result in the cursor not following the hand movement. Therefore, Scheme 1 offers a better user experience than Scheme 2. However, Scheme 1 cannot be used when using a USB redirection drawing tablet because the position information is forwarded to the destination end via USB overnet, and the source end cannot obtain this information by capturing operating system messages. Furthermore, the destination end cursor is hidden and cannot be displayed. By using local cursor display technology, the source end directly parses the HID packet to obtain coordinate information and writes it to the local cursor, making Scheme 1 still usable in USB redirection scenarios. This solves the cursor display latency problem, avoids the cursor not following the hand movement phenomenon, and improves the user experience in cloud desktop and remote control scenarios.

[0075] Figure 9 This is a flowchart illustrating the interception of a USB request initiated by the operating system that is the same type as the first request message, as provided in an embodiment of this application. Figure 9 As shown, the USB device redirection and data link layer forwarding optimization method includes: Step 701: The destination intercepts the device request block initiated by the operating system to the virtual USB device, and parses the request type, endpoint address and transmission direction of the device request block.

[0076] The Device Request Block (URB) is a data structure in the operating system kernel used to uniformly represent and manage all USB requests. The URB contains fields such as request type, endpoint address, transfer direction, data buffer pointer, and data length.

[0077] In one embodiment, the destination intercepts all URBs initiated by the operating system to the virtual USB device through the virtual USB device module, and parses the request type, endpoint address, and transmission direction fields of each URB to determine whether the URB belongs to the type that needs to be accelerated for forwarding.

[0078] Step 702: Mark the device request block with the request type of interrupted transfer or isochronous transfer and the transfer direction as virtual USB device to operating system as a candidate request.

[0079] In one embodiment, interrupt transfers and isochronous transfers are two types of periodic transfers in the USB protocol. Interrupt transfers are used for small, periodic data transfers, such as input data reporting from HID devices, and have a fixed polling interval. Isochronous transfers are used for real-time audio and video data transfers, such as audio and video data streams from USB cameras and USB microphones, and have a fixed bandwidth and periodicity. Both transfer types share the characteristic that the device actively reports data to the host periodically, and the host obtains the device data by periodically sending IN requests. A transfer direction from the virtual USB device to the operating system indicates that the URB is an IN request initiated by the operating system to the virtual USB device to read data from the device (indicating data flow from the USB device to the host). The destination marks URBs that meet the above conditions as candidate requests; these candidate requests are the target objects of the accelerated forwarding strategy.

[0080] Step 703: When the frequency of candidate requests for the same endpoint address within a preset time window exceeds the frequency threshold, the corresponding candidate request is determined to be a USB request of the same type as the first request message, and subsequent USB requests of the same type are intercepted.

[0081] In this context, the endpoint address is an identifier used on a USB device to distinguish different transmission channels. Each USB device can have multiple endpoints, each with a unique endpoint address. The preset time window refers to a pre-defined time interval used to statistically analyze the frequency of candidate requests. The frequency threshold is a pre-defined threshold for judging frequency; when the frequency of a candidate request exceeds this threshold, it indicates that the request type is a periodic recurring request, suitable for accelerated forwarding optimization.

[0082] In one embodiment, the destination maintains a candidate request statistics table, recording the number of times a candidate request for each endpoint address appears within a preset time window. When the number of times a candidate request for a certain endpoint address appears within the preset time window exceeds a frequency threshold, the destination determines the candidate request corresponding to that endpoint address as a USB request of the same type as the first request message. For subsequent USB requests of the same type initiated by the operating system to that endpoint address, the destination no longer sends them to the source over the network, but intercepts them and places them in a deferred queue for deferred processing. The destination waits for the response data returned by the source and uses the response data to sequentially complete the responses to the deferred USB requests, thereby accelerating forwarding.

[0083] As mentioned above, the frequency threshold can be adjusted based on the transmission characteristics of the specific device and the network environment. For example, for a standard USB mouse device, the polling interval is typically 8 milliseconds. Within a preset time window of 100 milliseconds, the number of candidate requests appears approximately 12 times, so the frequency threshold can be set to 10 times. When a candidate request for a certain endpoint address is detected to appear more than 10 times within 100 milliseconds, it can be determined that the request corresponding to that endpoint is a periodic repetitive request, and an accelerated forwarding strategy can be initiated.

[0084] Figure 10 This is a structural block diagram of a USB device redirection and data link layer forwarding optimization system provided in an embodiment of this application. The system is configured to execute the USB device redirection and data link layer forwarding optimization method provided in the above embodiment, and has corresponding functional modules for executing the method. Figure 10 As shown, the system specifically includes a source end and a destination end, with the source end connected to a physical USB device 801. The source end includes a USB device management module 802 and a first forwarding module 803, while the destination end includes a USB virtual device module 805 and a second forwarding module 804.

[0085] USB device management module 802 connects to physical USB devices and first forwarding module 803. First forwarding module 803 and second forwarding module 804 are connected via a data link. Second forwarding module 804 is connected to USB virtual device module 805. USB virtual device module 805 is connected to the operating system of the destination.

[0086] USB device management module 802 is configured to respond to USB device sharing commands, manage target USB devices, obtain device information of target USB devices, and send the device information to the destination. USB virtual device module 805 is configured to generate a virtual USB device corresponding to the target USB device based on the received device information, and register the virtual USB device with the operating system at the destination. The second forwarding module 804 is configured to intercept USB requests initiated by the operating system to the virtual USB device, convert the USB requests into a first request message and send it to the source end; The first forwarding module 803 is configured to generate a corresponding first USB request block based on the received first request message, and send the first USB request block to the target USB device; The first forwarding module 803 is further configured to receive response data returned by the target USB device, perform differentiated forwarding processing on the response data according to the transmission type in the first request message corresponding to the response data to obtain a response message, and send the response message to the destination. The second forwarding module 804 is also configured to complete the response to the USB request based on the response message.

[0087] The above-described process of managing the target USB device and obtaining device information to send to the destination ensures that the source physical USB device enters a state where it can be remotely shared, and provides complete device attribute information for the corresponding virtual USB device generated at the destination. By virtually generating and registering the virtual USB device based on the received device information, the system can deceive the destination operating system into recognizing and loading the corresponding upper-layer client driver, thus presenting the remote physical USB device as a locally usable device. Intercepting USB requests initiated by the operating system to the virtual USB device and converting them into a first request message to be sent to the source, as well as completing the response to the USB request based on the response message, enables bidirectional proxy forwarding of USB requests from the destination operating system. Generating a first USB request block based on the first request message and sending it to the target USB device, and receiving the response data and performing differentiated forwarding processing to obtain a response message to be sent to the destination, allows the actual data read / write operations of the physical USB device to be completed at the source. Furthermore, it adaptively selects forwarding strategies based on different transmission types, reducing network round-trip latency, minimizing small packet transmission overhead, and improving bandwidth utilization. This system enables remote sharing of physical USB devices across hosts, ensuring data integrity while improving transmission efficiency and operational smoothness in weak network environments.

[0088] In one possible embodiment, the second forwarding module 804 is further configured to: After the destination sends the first request message to the source, it intercepts subsequent USB requests of the same type as the first request message initiated by the operating system and temporarily suspends the processing of the intercepted subsequent USB requests.

[0089] In one possible embodiment, the first forwarding module 803 is further configured as follows: After receiving the first request message, the source saves a copy of the first request message locally. After receiving the response data returned by the target USB device, the source uses the copy to trigger a new USB request locally, so that the response data of the target USB device continues to be generated.

[0090] In one possible embodiment, the first forwarding module 803 is further configured as follows: The source end merges multiple response data returned by the target USB device within a preset time period into an aggregated response message, which contains a collection of multiple USB response data. The source sends the aggregated response message to the destination.

[0091] In one possible embodiment, the second forwarding module 804 is further configured to: After receiving the aggregated response message, the destination end parses out each independent USB response data and completes the response to the corresponding USB request one by one. The preset time period is determined according to the transmission type of the target USB device.

[0092] In one possible embodiment, the USB device management module 802 is further configured to: Add a hub filter driver on top of the source-side USB hub driver layer; The hub filter driver intercepts the device enumeration requests of the source operating system's device enumeration manager to the target USB device. The hub filter driver rewrites the vendor identifier and product identifier of the target USB device to the vendor identifier and product identifier of the takeover driver, so that the device enumeration manager matches the target USB device to the takeover driver; The takeover driver takes over the target USB device, creates the corresponding functional device object, and attaches it to the top layer of the target USB device's device stack.

[0093] In one possible embodiment, the USB virtual device module 805 is further configured to: At the destination, create a virtual root bus device, a virtual USB host controller device, and a virtual USB hub device in sequence. The destination device enumeration manager enumerates the virtual root bus device, the virtual USB host controller device, and the virtual USB hub device; Based on the received device information, create a virtual USB physical device object corresponding to the target USB device under the virtual USB hub device; The device enumeration manager at the destination end enumerates virtual USB physical device objects and matches the upper-layer client driver for each virtual USB physical device object.

[0094] In one possible embodiment, the first forwarding module 803 is further configured as follows: When the target USB device is a pointer input device that conforms to the human-machine interaction device protocol, the source end parses the human-machine interaction device message in the response data and extracts the coordinate information from the human-machine interaction device message according to the human-machine interaction device descriptor of the target USB device; The source end writes the extracted coordinate information into its local cursor, and hides the destination end's cursor while displaying the local cursor on the source end.

[0095] In one possible embodiment, the second forwarding module 804 is further configured to: The destination intercepts the device request block sent by the operating system to the virtual USB device, and parses the request type, endpoint address and transmission direction of the device request block; Mark device request blocks with request type interrupted transfer or isochronous transfer and transfer direction from virtual USB device to operating system as candidate requests; When the frequency of candidate requests for the same endpoint address exceeds the frequency threshold within a preset time window, the corresponding candidate request is determined to be a USB request of the same type as the first request message, and subsequent USB requests of the same type are intercepted.

[0096] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application, such as... Figure 11 As shown, the computer device includes a processor 901, a memory 902, an input device 903, and an output device 904.

[0097] The number of processors 901 can be one or more. Figure 11 Taking a processor 901 as an example; the processor 901, memory 902, input device 903, and output device 904 can be connected via a bus or other means. Figure 11 Taking a bus connection as an example, the memory 902, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the USB device redirection and data link layer forwarding optimization method in this embodiment. The processor 901 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory 902, thereby implementing the aforementioned USB device redirection and data link layer forwarding optimization method. The input device 903 can be configured to receive input digital or character information and generate key signal inputs related to user settings and function control of the device. The output device 904 may include a display screen or other display device.

[0098] This application embodiment also provides a non-volatile storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are configured to perform a USB device redirection and data link layer forwarding optimization method described in the above embodiments. The method includes: a source end responding to a USB device sharing instruction, managing a target USB device, obtaining device information of the target USB device, and sending the device information to a destination end; the destination end, based on the received device information, virtually generating a virtual USB device corresponding to the target USB device, and registering the virtual USB device with the destination end's operating system; the destination end intercepting a USB request initiated by the operating system to the virtual USB device, converting the USB request into a first request message, and sending it to the source end; the source end generating a corresponding first USB request block based on the received first request message, and sending the first USB request block to the target USB device; the source end receiving response data returned by the target USB device, performing differentiated forwarding processing on the response data according to the transmission type in the first request message corresponding to the response data to obtain a response message, and sending the response message to the destination end; and the destination end completing the response to the USB request based on the response message; wherein the first request message and the response message adopt a custom USB request structure.

[0099] It is worth noting that in the above embodiments of the USB device redirection and data link layer forwarding optimization system, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not configured to limit the protection scope of the embodiments of this application.

[0100] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments provided herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A USB device redirection and data link layer forwarding optimization method, applied to a system including a source end and a destination end, wherein the source end is connected to a physical USB device, characterized in that, The method includes: The source end responds to the USB device sharing command, manages the target USB device, obtains the device information of the target USB device, and sends the device information to the destination end; The destination device generates a virtual USB device corresponding to the target USB device based on the received device information, and registers the virtual USB device with the operating system of the destination device. The destination intercepts the USB request initiated by the operating system to the virtual USB device, converts the USB request into a first request message, and sends it to the source. The source end generates a corresponding first USB request block based on the received first request message, and sends the first USB request block to the target USB device; The source end receives the response data returned by the target USB device, performs differentiated forwarding processing on the response data according to the transmission type in the first request message corresponding to the response data to obtain a response message, and sends the response message to the destination end; The destination terminal completes the response to the USB request based on the response message; The first request message and the response message adopt a custom USB request structure.

2. The forwarding optimization method according to claim 1, characterized in that, The differentiated forwarding process includes accelerated forwarding, which includes: After sending the first request message to the source, the destination intercepts subsequent USB requests of the same type as the first request message initiated by the operating system, and temporarily suspends the intercepted subsequent USB requests. After receiving the first request message, the source end saves a copy of the first request message locally. After receiving the response data returned by the target USB device, the source end uses the copy to trigger a new USB request locally, so that the response data of the target USB device continues to be generated.

3. The forwarding optimization method according to claim 1, characterized in that, The differentiated forwarding process also includes merged forwarding, which includes: The source end merges multiple response data returned by the target USB device within a preset time period into an aggregated response message, and the aggregated response message contains a set of multiple USB response data. The source end sends the aggregated response message to the destination end; After receiving the aggregated response message, the destination device parses out each independent USB response data and completes the response to the corresponding USB request one by one. The preset time period is determined according to the transmission type of the target USB device.

4. The forwarding optimization method according to claim 1, characterized in that, The managed target USB device includes a takeover target USB device, which includes: A hub filter driver is added on top of the USB hub driver layer at the source end. The hub filter driver intercepts the device enumeration request of the source operating system's device enumeration manager for the target USB device. The hub filter driver rewrites the vendor identification code and product identification code of the target USB device into the vendor identification code and product identification code of the takeover driver, so that the device enumeration manager matches the target USB device to the takeover driver; The takeover driver takes over the target USB device, creates a corresponding functional device object, and attaches it to the top layer of the target USB device's device stack.

5. The forwarding optimization method according to claim 1, characterized in that, The process of virtually generating a virtual USB device corresponding to the target USB device at the destination includes: At the destination, a virtual root bus device, a virtual USB host controller device, and a virtual USB hub device are created sequentially. The destination device enumeration manager enumerates the virtual root bus device, the virtual USB host controller device, and the virtual USB hub device; Based on the received device information, a virtual USB physical device object corresponding to the target USB device is created under the virtual USB hub device; The device enumeration manager at the destination end enumerates the virtual USB physical device object and matches the upper-layer client driver for the virtual USB physical device object.

6. The forwarding optimization method according to claim 1, characterized in that, The differentiated forwarding process also includes local cursor echoing, which includes: When the target USB device is a pointer input device that conforms to the human-computer interaction device protocol, the source end parses the human-computer interaction device message in the response data and extracts coordinate information from the human-computer interaction device message according to the human-computer interaction device descriptor of the target USB device; The source end writes the extracted coordinate information into its local cursor, and hides the cursor of the destination end while displaying the local cursor on the source end.

7. The forwarding optimization method according to claim 2, characterized in that, The interception of subsequent USB requests of the same type as the first request message initiated by the operating system includes: The destination intercepts the device request block initiated by the operating system to the virtual USB device, and parses the request type, endpoint address and transmission direction of the device request block; The device request block whose request type is interrupted transfer or isochronous transfer, and whose transfer direction is from the virtual USB device to the operating system, is marked as a candidate request; When the frequency of candidate requests for the same endpoint address exceeds a frequency threshold within a preset time window, the corresponding candidate request is determined to be a USB request of the same type as the first request message, and subsequent USB requests of the same type are intercepted.

8. A USB device redirection and data link layer forwarding optimization system, characterized in that, It includes a source end and a destination end, wherein the source end is connected to a physical USB device; The source end includes a USB device management module and a first forwarding module, and the destination end includes a USB virtual device module and a second forwarding module; The USB device management module is connected to the physical USB device and the first forwarding module. The first forwarding module and the second forwarding module are connected via a data link. The second forwarding module is connected to the USB virtual device module. The USB virtual device module is connected to the operating system of the destination end. The system is used to implement the USB device redirection and data link layer forwarding optimization method according to any one of claims 1-7.

9. A computer device, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the USB device redirection and data link layer forwarding optimization method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement a USB device redirection and data link layer forwarding optimization method as described in any one of claims 1-7.

Images