A USB device virtualization sharing method, device, equipment and medium

Abstract

The present application relates to the technical field of external device sharing, and in particular to a USB device virtualization sharing method, apparatus, device and medium. The present application first deploys a simulated USB device driver in the client system, making it a resident system as a virtual container; then deploys a physical USB device on the server side and starts a service program; when a client application access request is detected, the request is forwarded to the server through the network, and the result is returned after being processed by the physical device, which not only solves the problem of device disconnection in traditional remote sharing, but also enables users to operate remote USB devices like local devices through the resident mechanism of simulated devices, while avoiding the problem of invalid occupation of devices, and significantly improving the efficiency of USB devices.

Description

Technical Field

[0001] The present application relates to the technical field of external device sharing, and in particular, to a method, device, equipment and medium for virtualizing and sharing USB devices. Background Art

[0002] With the continuous improvement of enterprise informatization, various USB devices such as USB tokens, USB-Keys, and dongles play important roles in enterprise office work. These devices usually carry important security functions such as enterprise identity authentication and data encryption, and are key devices to ensure enterprise information security. However, these devices are often scattered in individuals' hands, which not only makes management difficult, but also causes the problem of low device utilization efficiency.

[0003] In the prior art, through the USB device network redirection technology, remote sharing and use of USB devices can be realized. This technology deploys USB devices on the server side, and the client accesses the USB devices on the server through a network connection to achieve centralized management and remote access of device resources.

[0004] However, when the user finishes using the USB device, since the device is not local, it is easily forgotten and not disconnected in time, resulting in the device being occupied invalidly, and other users cannot use it in time, reducing the utilization efficiency of the device and causing resource waste. At the same time, the connection status of the remote device is unstable, and the device often drops offline, affecting the user experience and work efficiency. This situation needs to be further improved. Summary of the Invention

[0005] In order to solve the problems of low utilization efficiency and unstable connection existing in the existing remote sharing of USB devices, the present application provides a method, device, equipment and medium for virtualizing and sharing USB devices, and adopts the following technical solutions:

[0006] In a first aspect, the present application provides a method for virtualizing and sharing USB devices, including the following steps:

[0007] Deploy a driver for simulating a USB device in the client system, so that the system recognizes the driver of the simulated USB device as a permanently online USB device;

[0008] Deploy a driver for the physical USB device on the server side, and start the server program to receive client requests;

[0009] When it is detected that the client application accesses the simulated USB device, forward the data request to the server side through the network;

[0010] Receive the data request from the client, pass the data request to the physical USB device for processing, and return the processing result to the client;

[0011] Receive response data by simulating a USB device and transfer the data to the client application.

[0012] By adopting the above technical solution, to solve the problem of low usage efficiency caused by decentralized management of enterprise USB devices. Especially in industries such as banking and securities, a large number of USB devices such as USB tokens and dongles are scattered among employees, resulting in the dilemma of device idleness or inability to be retrieved in time. For example, a financial staff member of an enterprise needs to operate multiple USB tokens of different banks, but these USB tokens may be held by different people or placed in different offices, resulting in low business handling efficiency. This application first deploys a simulated USB device driver in the client system to make it a virtual container resident in the system. Then, deploy an entity USB device on the server side and start the service program. When a client application access request is detected, forward the request to the server through the network, and return the result after being processed by the entity device. This not only solves the problem of device disconnection in traditional remote sharing, but also through the resident mechanism of the simulated device, enables users to operate remote USB devices as if using local devices, while avoiding the problem of devices being invalidly occupied, significantly improving the usage efficiency of USB devices.

[0013] Optionally, the method further includes the following steps:

[0014] Receive access requests from multiple clients;

[0015] Set a request timeout threshold according to the response time characteristics of the USB device;

[0016] Dynamically adjust the request priority according to the order of request arrival and the request timeout threshold.

[0017] By adopting the above technical solution, to solve the resource competition problem when multiple clients simultaneously request access to the same USB device. Especially in an enterprise environment, multiple users may need to use the same USB device in a similar time period. If a simple first-come-first-served policy is adopted, some important or time-sensitive operations may be delayed. This application first receives access requests from multiple clients, then sets a request timeout threshold based on the actual response time characteristics of the USB device, and finally dynamically adjusts the processing priority according to the order of request arrival and the timeout threshold, not only ensuring the fair use of device resources, but also enabling intelligent scheduling according to the time-sensitive characteristics of requests.

[0018] Optionally, setting the request timeout threshold according to the response time characteristics of the USB device specifically includes the following steps:

[0019] Obtain the transfer type and endpoint descriptor of the USB device, and set the corresponding baseline timeout threshold according to different transfer types;

[0020] Collect device request response time samples according to the response time characteristics of the USB device, and calculate the average response time of the valid samples;

[0021] Compare the average response time with the reference timeout threshold, and dynamically adjust the actually used timeout threshold.

[0022] By adopting the above technical solution, some USB dongles may require a long processing time for data encryption and decryption, while operations such as status queries require quick responses. If a unified timeout threshold is used, either time-consuming operations will be frequently timed out and interrupted, or simple operation responses will be delayed. This application first obtains the transfer type and endpoint descriptor information of the USB device, and sets a reference timeout threshold for different transfer types; then continuously collects response time samples during the device operation, and calculates the average response time of the valid samples through statistical analysis; finally, compares the calculated average response time with the preset reference timeout threshold, and dynamically adjusts the actually used timeout threshold, realizing precise control and adaptive adjustment of the timeout threshold, avoiding both operations being interrupted due to too low timeout threshold settings and resource occupation caused by too high thresholds, and improving the stability and efficiency of device sharing.

[0023] Optionally, deploy a driver that simulates a USB device in the client system, which specifically includes the following steps:

[0024] Obtain the device descriptor, configuration descriptor, and interface descriptor of the physical USB device;

[0025] Generate a general USB device simulation driver according to the descriptor information;

[0026] Register the simulation driver as a system device, so that the simulation driver remains resident in the system.

[0027] By adopting the above technical solution, this application first obtains the device descriptor, configuration descriptor, and interface descriptor of the target USB device, and these descriptors contain the complete feature information of the device; then based on these standardized descriptor information, dynamically generates a general driver program that can simulate the behavior of the target device; finally, registers the simulation driver as a system device and sets it to the resident state to ensure that the application can continuously and stably access. Through the descriptor mechanism in the standard USB protocol, the automatic adaptation and generalization of the driver are realized, which not only greatly reduces the development and maintenance costs, but also improves the compatibility of the system with different types of USB devices.

[0028] Optionally, when it is detected that the client application accesses the simulated USB device, it specifically includes the following steps:

[0029] Intercept the initialization request of the client application for the USB device;

[0030] Configure the response parameters of the simulated USB device according to the device feature parameters in the initialization request;

[0031] Establish a data channel between the application and the simulated USB device.

[0032] By adopting the above technical solution, the present application first intercepts the USB device initialization request initiated by the application through the system underlying driver to obtain the device feature parameter requirements included in the request; then, according to these parameter requirements, dynamically configure the response parameters of the simulated USB device to make it exactly match the device features expected by the application; finally, establish a data channel between the application and the simulated USB device to ensure the normal progress of subsequent data interaction, realizing the precise adaptation of the simulated device and the application, and improving the compatibility of the system with various applications.

[0033] Optionally, forward the data request to the server end through the network, which specifically includes the following steps:

[0034] Obtain the transfer type and transfer direction of the USB request packet;

[0035] After adding a session identifier to the USB request packet, encapsulate it into a network data packet;

[0036] Establish a mapping relationship between the session identifier and the corresponding response data;

[0037] Send the network data packet to the server end through the network connection.

[0038] By adopting the above technical solution, the present application first identifies the transfer type and transfer direction of the USB request packet to provide targeted processing for different types of transfers; then generates a unique session identifier for each request packet and encapsulates it into the network data packet; at the same time, maintain a mapping relationship between the session identifier and the expected response data on the client side; finally, send the encapsulated data packet to the server through the network connection, realizing the precise correspondence between requests and responses, solving the data chaos problem during concurrent access, and keeping the USB device virtualization system running stably and reliably.

[0039] Optionally, receive the data request from the client and pass the data request to the physical USB device for processing, which specifically includes the following steps:

[0040] Parse the received network data packet, extract the session identifier and USB request information;

[0041] Send the USB request information to the physical USB device through the system interface;

[0042] Receive the response data from the physical USB device;

[0043] Return the response data to the corresponding client according to the session identifier.

[0044] By adopting the above technical solution, the present application first parses the received network data packet, extracts the session identifier and specific USB request information to ensure the traceability of the request source; then accurately transfers the USB request to the physical device for processing through the system standard interface to ensure the effective execution of the request; when the response data of the physical device is obtained, the system immediately returns the response data to the corresponding client according to the original session identifier. Through the session management mechanism of the entire request process, precise control of server-side data processing is achieved, making the entire virtualization system exhibit better reliability in high-concurrency scenarios.

[0045] In a second aspect, the present application provides a USB device virtualization sharing device, including:

[0046] A client simulation module, used to deploy a driver for simulating a USB device in the client system, so that the system recognizes the driver of the simulated USB device as a permanently online USB device;

[0047] A server-side deployment module, used to deploy a driver for the physical USB device on the server side and start the server-side program to receive client requests;

[0048] A data forwarding module, used to forward the data request to the server side through the network when it detects that the client application accesses the simulated USB device;

[0049] A request processing module, used to receive the data request of the client, transfer the data request to the physical USB device for processing, and return the processing result to the client;

[0050] A response transfer module, used to receive the response data through the simulated USB device and transfer the data to the client application.

[0051] In a third aspect, the present application provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps of the above USB device virtualization sharing method are implemented.

[0052] In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above USB device virtualization sharing method are implemented.

[0053] In summary, the present application includes at least one of the following beneficial technical effects:

[0054] 1. This application first deploys a simulated USB device driver in the client system to make it a virtual container resident in the system; then deploys a physical USB device on the server side and starts the service program; when a client application access request is detected, the request is forwarded to the server via the network, and the result is returned after being processed by the physical device. This not only solves the problem of device disconnection in traditional remote sharing, but also, through the resident mechanism of the simulated device, enables users to operate remote USB devices as if they were local devices, while avoiding the problem of invalid occupation of the device, significantly improving the usage efficiency of USB devices;

[0055] 2. Some USB dongles may require a long processing time for data encryption and decryption, while operations such as status query require quick response. If a unified timeout threshold is used, either time-consuming operations will be frequently interrupted due to timeout, or simple operations will have delayed responses; this application first obtains the transfer type and endpoint descriptor information of the USB device to set a baseline timeout threshold for different transfer types; then continuously collects response time samples during the device operation, calculates the average response time of valid samples through statistical analysis; finally compares the calculated average response time with the preset baseline timeout threshold to dynamically adjust the actually used timeout threshold, achieving precise control and adaptive adjustment of the timeout threshold, which not only avoids operations being interrupted due to too low a timeout threshold setting, but also prevents resource occupation caused by too high a threshold, improving the stability and efficiency of device sharing;

[0056] 3. This application first obtains the device descriptor, configuration descriptor, and interface descriptor of the target USB device, and these descriptors contain the complete feature information of the device; then based on this standardized descriptor information, dynamically generates a general driver that can simulate the behavior of the target device; finally registers this simulated driver as a system device and sets it to the resident state to ensure that the application can access continuously and stably. Through the descriptor mechanism in the standard USB protocol, automatic adaptation and generalization of the driver are achieved, which not only greatly reduces the development and maintenance costs, but also improves the compatibility of the system with different types of USB devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 is a flowchart showing a method for virtualizing and sharing USB devices according to an embodiment of this application;

[0058] Figure 2 is a flowchart showing the process of adjusting request priorities in a method for virtualizing and sharing USB devices according to an embodiment of this application;

[0059] Figure 3 is a flowchart showing step S110 in a method for virtualizing and sharing USB devices according to an embodiment of this application;

[0060] Figure 4It is a schematic flowchart of step S130 in a USB device virtualization sharing method according to an embodiment of the present application;

[0061] Figure 5 It is a schematic flowchart of step S140 in a USB device virtualization sharing method according to an embodiment of the present application;

[0062] Figure 6 It is a schematic diagram of modules of a USB device virtualization sharing device according to an embodiment of the present application;

[0063] Figure 7 It is an internal structure diagram of an electronic device according to an embodiment of the present application. Detailed implementation manners

[0064] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. As used in the specification and appended claims of the present application, the singular forms "a", "an", "the", "above-mentioned", "said", and "this" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in the present application refers to any and all possible combinations including one or more of the listed items.

[0065] Hereinafter, the terms "first" and "second" are only used for descriptive purposes, and cannot be understood as implying or suggesting relative importance or implicitly indicating the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present application, unless otherwise stated, the meaning of "a plurality" is two or more.

[0066] The following further describes the embodiments of the present application in detail with reference to the accompanying drawings of the specification.

[0067] In a first aspect, the present application provides a schematic flowchart of a USB device virtualization sharing method. Referring to Figure 1 , the method includes the following steps:

[0068] S110. Deploy a driver for simulating a USB device in the client system, so that the system recognizes the driver of the simulating USB device as a permanently online USB device.

[0069] In this embodiment, a driver for simulating a USB device is deployed in the client system. The main purpose is to build a virtual USB device access point in the client system. This simulated driver appears as a permanently online USB device in the system, enabling the client application to access this virtual device in the same way as accessing a physical USB device. This deployment method of the simulated driver avoids the frequent device plugging and unplugging operations in the traditional USB device sharing solution and improves the stability of the system.

[0070] Specifically, the system administrator deploys the driver of the simulated USB device to the client system through the driver installer. For example, in the Windows system, a new virtual USB device can be added through the Device Manager and configured to be automatically loaded when the system starts up. When the driver is successfully deployed, a new USB device will be displayed in the Device Manager, and this device always remains online, and the application can access this device at any time.

[0071] S120. Deploy the driver of the physical USB device on the server side and start the server program to receive client requests.

[0072] In this embodiment, deploying the driver of the physical USB device on the server side and starting the server program is to establish a service environment capable of receiving and processing client requests. The server program is responsible for managing the access control of the physical USB device and processing concurrent requests from multiple clients.

[0073] Specifically, the system administrator installs the driver program of the physical USB device on the server to ensure that the server can correctly identify and operate this device. For example, for a certain type of USB key device, its official driver program needs to be installed. Subsequently, the server program is started. This program is usually configured as a system service and listens for client connection requests on a specific port. After the server program is started, it will automatically scan and identify the connected physical USB devices and establish a device list for the client to query and access.

[0074] S130. When it is detected that the client application accesses the simulated USB device, forward the data request to the server side through the network.

[0075] In this embodiment, detecting the access request of the client application and forwarding it to the server realizes the data communication bridge between the local application and the remote USB device. The simulated USB device driver intercepts the device access requests of the local application, converts these requests into network requests and sends them to the server, so that the local application can access the remote USB device without any modification.

[0076] Specifically, when a local application attempts to access a USB device, the simulation driver captures these access requests. For example, when an application attempts to read the certificate information in a USB key, the simulation driver receives the corresponding read command. The driver packages these requests into network data packets and sends them to the server through a pre-established network connection to achieve remote forwarding of the requests.

[0077] S140. Receive a data request from a client, pass the data request to the physical USB device for processing, and return the processing result to the client.

[0078] In this embodiment, receiving and processing client requests is the core link of the entire virtualization sharing solution. The server needs to restore the network request to a standard USB request and hand it over to the physical USB device for processing.

[0079] Specifically, after the server program receives a network request from a client, it first performs request parsing. For example, for a request to read a certificate, the server needs to convert it into a corresponding USB device command and then send it to the physical USB device through the system interface. After obtaining the processing result of the device, the server encapsulates the result into a response data packet and sends it back to the corresponding client.

[0080] S150. Receive response data through the simulated USB device and pass the data to the client application.

[0081] In this embodiment, receiving response data through the simulated USB device is the last link of this solution, responsible for passing the processing result returned by the server to the client application. The simulation driver plays a role in protocol conversion in this process to ensure that the application can correctly receive and parse the returned data.

[0082] Specifically, when the simulation driver receives the response data returned by the server, it converts it into a standard USB response format. For example, for the response to a certificate reading operation, the driver program encapsulates the returned certificate data according to the specifications of the USB protocol and then passes it to the application through a pre-established data channel, enabling the application to process this response data as if it were accessing a local USB device.

[0083] In one embodiment, referring to Figure 2 , the method further includes the following steps:

[0084] S210. Receive access requests from multiple clients.

[0085] In this embodiment, receiving access requests from multiple clients is the basic link for realizing USB device sharing and needs to handle concurrent access situations from different clients.

[0086] Specifically, the server - side program will establish a request queue to store the received client requests. For example, when multiple users use a shared dongle device simultaneously, the server will store these requests in the queue in the order of reception. For each request, the server will record key information such as its arrival time and request type, providing a basis for subsequent request scheduling.

[0087] S220. Set the request timeout threshold according to the response - time characteristics of the USB device.

[0088] Among them, the request timeout threshold is a process of dynamic optimization based on the characteristics of the USB device. Different types of USB devices and different transfer types have different response characteristics. Therefore, it is necessary to flexibly adjust the timeout threshold according to the actual situation to avoid wasting system resources caused by ineffective waiting.

[0089] In this embodiment, step S220 includes: obtaining the transfer type and endpoint descriptor of the USB device, setting the corresponding reference timeout threshold according to different transfer types; collecting device - request response - time samples according to the response - time characteristics of the USB device, and calculating the average response time of valid samples; comparing the average response time with the reference timeout threshold, and dynamically adjusting the actually used timeout threshold.

[0090] Specifically, the system will first set the reference timeout value according to the transfer types defined in the USB specification (such as control transfer, interrupt transfer, bulk transfer, etc.). For example, the reference timeout value for control transfer may be set to 500 ms, while for bulk transfer, it may be set to 1000 ms. Then the system will continuously monitor the actual response time of the device, calculate the average response time after collecting a certain number of samples. If the average response time is significantly lower than the reference timeout value, the system will appropriately reduce the timeout threshold to improve processing efficiency; if the average response time is close to the reference timeout value, it may be necessary to appropriately increase the threshold to avoid premature termination of valid requests.

[0091] S230. Dynamically adjust the request priority according to the request arrival order and the request timeout threshold.

[0092] In this embodiment, dynamically adjusting the request priority is the key mechanism for realizing efficient request processing. The system needs to ensure the fairness of request processing while avoiding some requests from timing out due to excessive waiting time.

[0093] Specifically, the system adjusts the processing priority of requests based on the waiting time of the requests in the queue and a preset timeout threshold. For example, assume that the timeout threshold for a certain request is 1000 ms. When its waiting time in the queue reaches 800 ms, the system will increase the priority of this request so that it can be processed preferentially. For different types of requests, the system also considers their importance and urgency. For example, requests for identity authentication may receive a relatively high base priority. Through this dynamic adjustment mechanism, both the timeliness of request processing is ensured, and the starvation phenomenon of request processing is avoided.

[0094] In one embodiment, referring to Figure 3 , in step S110, deploying a driver that simulates a USB device in the client system specifically includes the following steps:

[0095] S111. Obtain the device descriptor, configuration descriptor, and interface descriptor of the physical USB device.

[0096] In this embodiment, obtaining the descriptor information of the physical USB device is the basic work for simulating driver development. The USB device descriptor contains the basic characteristic information of the device, the configuration descriptor defines the working mode of the device, and the interface descriptor describes the functional interfaces provided by the device.

[0097] Specifically, the system administrator can obtain the descriptor information of the target device through a professional USB protocol analysis tool. For example, use the USB Protocol Analyzer tool to connect to the physical USB device and capture the descriptor information during the device enumeration process. For a certain dongle device, key parameters such as its vendor ID (VID), product ID (PID), device type, and endpoint configuration can be obtained, and these parameters will be used for subsequent simulation driver development.

[0098] S112. Generate a general USB device simulation driver according to the descriptor information.

[0099] Specifically, generating a simulation driver according to the descriptor information is the core link of the entire virtualization solution. The general USB device simulation driver needs to be able to accurately simulate the characteristics and behaviors of the physical device, so that the application program cannot perceive the fact that the device is virtualized.

[0100] S113. Register the simulation driver as a system device so that the simulation driver remains resident in the system.

[0101] Specifically, registering the simulation driver as a system device is an important guarantee for ensuring the stable operation of the virtualization solution. The system needs to register the simulation driver as a permanent device so that it is automatically loaded and continuously runs when the system starts, which can avoid the instability problems caused by frequent device plugging and unplugging.

[0102] In one embodiment, with reference to Figure 4 , in step S130, when it is detected that the client application accesses the simulated USB device, the following steps are specifically included:

[0103] S131. Intercept the initialization request of the client application for the USB device.

[0104] Specifically, the simulation driver listens for the device access requests of the application through the device driver interface provided by the system. For example, when the office software first attempts to access the USB key, the driver will capture the device enumeration request, which contains information such as the device type and interface type that the application expects to access. The driver temporarily stores and analyzes these requests to prepare for subsequent parameter configuration.

[0105] S132. Configure the response parameters of the simulated USB device according to the device characteristic parameters in the initialization request.

[0106] Specifically, the system analyzes the device characteristic parameters included in the initialization request, such as the device type and transmission speed. For example, for a certain USB printer, the system will configure corresponding parameters such as the printer class descriptor and data transfer endpoints according to the request. These parameters are written into the configuration space of the simulated device so that it can respond according to the expectations of the application.

[0107] S133. Establish a data channel between the application and the simulated USB device.

[0108] Among them, establishing a data channel is the basis for realizing stable communication between the application and the simulated device. The system needs to create and maintain a reliable data transmission channel to ensure that the requests of the application can be correctly transmitted and the response data can be accurately returned.

[0109] Specifically, the system creates a two-way communication pipeline for connecting the application and the simulated device. For example, for USB devices of the bulk transfer type, the system will create corresponding data buffers and transmission queues and set appropriate synchronization mechanisms. Through this channel, the data sent by the application can be reliably transmitted to the simulated device, and the response data of the device can also be returned to the application in a timely manner.

[0110] Furthermore, forwarding the data request to the server side through the network specifically includes the following steps:

[0111] S134. Obtain the transmission type and transmission direction of the USB request packet.

[0112] S135. Encapsulate the USB request packet into a network data packet after adding a session identifier.

[0113] In this embodiment, the system generates a unique session identifier for each USB request, which can be generated by means of a timestamp, a counter, etc. For example, for a certain file reading request, the system may generate a session identifier containing the request time and a serial number. Then, the USB request data and the session identifier are encapsulated into a network data packet to prepare for network transmission.

[0114] S136. Establish a mapping relationship between the session identifier and the corresponding response data.

[0115] In this embodiment, the system maintains a corresponding relationship between the session identifier and the request context to ensure that the corresponding request handler can be accurately found after receiving the response data.

[0116] Specifically, the system creates a mapping table to store the corresponding relationship between the session identifier and the request information. For example, when sending a request to read the U shield certificate, the system will record information such as the session identifier, the request type, and the sending time in the mapping table. This information will be used for correct routing and timeout processing of the data when the response data is received.

[0117] S137. Send the network data packet to the server side through the network connection.

[0118] Specifically, the system uses a reliable network transmission protocol to send the encapsulated data packet. For example, a connection with the server is established through the TCP protocol, and appropriate sending buffer size and timeout parameters are set. The system will monitor the sending status of the data packet and retransmit or perform flow control when necessary to ensure that the data can reach the server side reliably.

[0119] In one embodiment, referring to Figure 5 , in step S140, receive the data request from the client and pass the data request to the entity USB device for processing, which specifically includes the following steps:

[0120] S141. Analyze the received network data packet and extract the session identifier and the USB request information.

[0121] S142. Send the USB request information to the entity USB device through the system interface.

[0122] S143. Receive the response data from the entity USB device.

[0123] S144. Return the response data to the corresponding client according to the session identifier.

[0124] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0125] Second aspect, the present application provides a USB device virtualization sharing device. The USB device virtualization sharing device of the present application will be described below in combination with the above USB device virtualization sharing method.

[0126] Referring to Figure 6 , a USB device virtualization sharing device includes:

[0127] A client simulation module, configured to deploy a driver for simulating a USB device in a client system, so that the system recognizes the driver of the simulated USB device as a permanently online USB device;

[0128] A server deployment module, configured to deploy a driver of a physical USB device on a server side, and start a server program to receive client requests;

[0129] A data forwarding module, configured to forward a data request to the server side through a network when it detects that a client application accesses the simulated USB device;

[0130] A request processing module, configured to receive a data request from a client, pass the data request to a physical USB device for processing, and return a processing result to the client;

[0131] A response delivery module, configured to receive response data through the simulated USB device and deliver the data to a client application.

[0132] In one embodiment, the present application provides an electronic device, which may be a server, and its internal structure diagram may be as Figure 7 shown. The electronic device includes a processor, a memory, and a network interface connected through a system bus. Among them, the processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the electronic device is used to store data. The network interface of the electronic device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it implements a USB device virtualization sharing method.

[0133] Those skilled in the art can understand that Figure 7 the structure shown in

[0134] In one embodiment, an electronic device is further provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.

[0135] Those of ordinary skill in the art can understand that all or part of the processes in the above method embodiments can be completed by instructing relevant hardware through a computer program. The above computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above method embodiments. Among them, any reference to a memory, storage, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0136] The above are all preferred embodiments of the present application. Without limiting the protection scope of the present application accordingly, therefore: Any equivalent changes made according to the structure, shape, and principle of the present application shall be covered within the protection scope of the present application.

Claims

1. A USB device virtualization sharing method, characterized in that The steps are as follows: Deploy a driver for a simulated USB device in the client system so that the system recognizes the driver of the simulated USB device as a permanently online USB device; Deploy a driver for the physical USB device on the server side and start the server-side program to receive client requests; When it is detected that the client application accesses the simulated USB device, forward the data request to the server side through the network; Receive the data request from the client, pass the data request to the physical USB device for processing, and return the processing result to the client; Receive the response data through the simulated USB device and pass the data to the client application; Receive access requests from multiple clients; Obtain the transfer type and endpoint descriptor of the USB device, and set the corresponding benchmark timeout threshold according to different transfer types; Collect device request response time samples according to the response time characteristics of the USB device, and calculate the average response time of the valid samples; Compare the average response time with the benchmark timeout threshold, and dynamically adjust the actually used request timeout threshold; Dynamically adjust the request priority according to the request arrival order and the request timeout threshold.

2. The USB device virtualization sharing method according to claim 1, wherein Deploy a driver for a simulated USB device in the client system, which specifically includes the following steps: Obtain the device descriptor, configuration descriptor, and interface descriptor of the physical USB device; Generate a general USB device simulation driver according to the descriptor information; Register the simulation driver as a system device so that the simulation driver remains resident in the system.

3. The USB device virtualization sharing method according to claim 1, characterized in that, When it is detected that the client application accesses the simulated USB device, it specifically includes the following steps: Intercept the initialization request of the client application for the USB device; Configure the response parameters of the simulated USB device according to the device characteristic parameters in the initialization request; Establish a data channel between the application and the simulated USB device.

4. The USB device virtualization sharing method according to claim 1, wherein Forward the data request to the server side through the network, which specifically includes the following steps: Obtain the transfer type and transfer direction of the USB request packet; Add a session identifier to the USB request packet and encapsulate it as a network packet; Establish a mapping relationship between the session identifier and the corresponding response data; Send the network packet to the server side through the network connection.

5. The USB device virtualization sharing method according to claim 4, characterized in that Receive the data request from the client and pass the data request to the physical USB device for processing, which specifically includes the following steps: Parse the received network packet, extract the session identifier and USB request information; Send the USB request information to the physical USB device through the system interface; Receive the response data from the physical USB device; Return the response data to the corresponding client according to the session identifier.

6. A USB device virtualization sharing device, characterized in that, It includes: A client simulation module for deploying a driver for a simulated USB device in the client system so that the system recognizes the driver of the simulated USB device as a permanently online USB device; A server-side deployment module for deploying a driver for the physical USB device on the server side and starting the server-side program to receive client requests; A data forwarding module for forwarding the data request to the server side through the network when it is detected that the client application accesses the simulated USB device; A request processing module, configured to receive a data request from a client, transfer the data request to an entity USB device for processing, and return the processing result to the client; A response transfer module, configured to receive response data by simulating a USB device and transfer the data to a client application; The device further performs the following steps: Receive access requests from multiple clients; Obtain the transfer type and endpoint descriptor of the USB device, and set a corresponding reference timeout threshold according to different transfer types; Collect device request response time samples according to the response time characteristics of the USB device, and calculate the average response time of valid samples; Compare the average response time with the reference timeout threshold, and dynamically adjust the actually used request timeout threshold; Dynamically adjust the request priority according to the request arrival order and the request timeout threshold.

7. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps of the USB device virtualization sharing method described in any one of claims 1-5 are implemented.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the steps of the USB device virtualization sharing method described in any one of claims 1-5 are implemented.

Images