USB equipment virtualization sharing method and device, equipment and medium

Abstract

The invention relates to the technical field of external equipment sharing, in particular to a USB equipment virtualization sharing method and device, equipment and a medium. The method comprises the following steps: firstly, deploying a simulated USB device driver in a client system, and enabling the simulated USB device driver to serve as a virtual container resident system; then deploying entity USB equipment at a server side and starting a service program; when the client application program access request is detected, the request is forwarded to the server through the network, the entity device processes the request and returns a result, the problem of device disconnection in traditional remote sharing is solved, a user can operate a remote USB device like using a local device through a resident mechanism of the simulation device, and the user experience is improved. And meanwhile, the problem that the equipment is ineffectively occupied is avoided, and the use efficiency of the USB equipment is remarkably improved.

Description

Technical Field

[0001] 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. Background Art

[0002] As the degree of enterprise informatization continues to improve, various USB devices such as U shields, USB-Keys and dongles play an important role in enterprise office work. These devices usually carry important security functions such as identity authentication and data encryption, and are key devices to ensure enterprise information security. However, these devices are often scattered in the hands of individuals, which not only makes management difficult, but also causes the problem of low efficiency in device use.

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

[0004] However, after the user has finished using the USB device, because the device is not in the local area, it is easy to be forgotten and not disconnected in time, resulting in the invalid occupation of the device, and other users cannot use it in time, which reduces the efficiency of the device and causes 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 efficiency and unstable connection in the existing remote sharing of USB devices, the present application provides a USB device virtualization sharing method, apparatus, device and medium, which adopts the following technical solutions: In a first aspect, the present application provides a USB device virtualization sharing method, comprising the following steps: Deploy the driver of the 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 the physical USB device driver on the server side and start the server program to receive client requests; When it is detected that the client application is accessing the simulated USB device, the data request is forwarded to the server through the network; Receive a 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 response data by emulating the USB device and pass the data to the client application.

[0006] By adopting the above technical scheme, in order to solve the problem of low efficiency caused by decentralized management of USB devices in enterprises, especially in industries such as banking and securities, a large number of USB devices such as U-shiels and encryption dongles are scattered among employees, resulting in the dilemma of idle devices or inability to access them in time; for example, a financial staff of a certain enterprise needs U-shiels from multiple different banks to operate, but these U-shiels may be held by different people or placed in different offices, resulting in low business efficiency; this application first deploys a simulated USB device driver in the client system to make it a resident system as a virtual container; 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 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, significantly improving the efficiency of USB devices.

[0007] Optionally, the method further comprises the following steps: Receive access requests from multiple clients; Set the request timeout threshold according to the response time characteristics of the USB device; The request priority is dynamically adjusted according to the request arrival order and the request timeout threshold.

[0008] By adopting the above technical solution, in order to solve the resource competition problem when multiple clients simultaneously request to access 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 strategy is adopted, some important or time-sensitive operations may be delayed in processing; the 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 arrival order of the requests and the timeout threshold, which not only ensures the fair use of device resources, but also can perform intelligent scheduling according to the timeliness characteristics of the requests.

[0009] Optionally, setting a request timeout threshold according to a response time characteristic of the USB device specifically includes the following steps: Get 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; The average response time is compared with the reference timeout threshold, and the timeout threshold actually used is dynamically adjusted.

[0010] By adopting the above technical solution, some USB dongles may require a long processing time when performing data encryption and decryption, while operations such as status query require a quick response. If a unified timeout threshold is used, it will either cause frequent timeout interruptions of time-consuming operations or cause delays in the response of simple operations. The present application first sets a benchmark timeout threshold for different transmission types by obtaining the transmission type and endpoint descriptor information of the USB device; then, response time samples are continuously collected during the operation of the device, and the average response time of valid samples is calculated through statistical analysis; finally, the calculated average response time is compared with the preset benchmark timeout threshold, and the timeout threshold actually used is dynamically adjusted, thereby achieving precise control and adaptive adjustment of the timeout threshold, which not only avoids interruptions of operations due to too low a timeout threshold setting, but also prevents resource occupation due to too high a threshold, thereby improving the stability and efficiency of device sharing.

[0011] Optionally, deploy a driver for simulating a USB device in the client system, including the following steps: Get the device descriptor, configuration descriptor and interface descriptor of the physical USB device; Generate a general USB device simulation driver based on the descriptor information; The simulation driver is registered as a system device, so that the simulation driver remains in a resident state in the system.

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

[0013] Optionally, when it is detected that the client application accesses the simulated USB device, the following steps are specifically included: Intercept the client application's initialization request for the USB device; According to the device characteristic parameters in the initialization request, configure the response parameters of the simulated USB device; Establish a data channel between the application and the simulated USB device.

[0014] By adopting the above technical solution, the present application firstly intercepts the USB device initialization request initiated by the application through the system bottom-level driver, and obtains the device characteristic parameter requirements contained in the request; then, according to these parameter requirements, dynamically configures the response parameters of the simulated USB device to make it fully match the device characteristics expected by the application; finally, establishes a data channel between the application and the simulated USB device to ensure the normal subsequent data interaction, realizes the precise adaptation of the simulated device and the application, and improves the compatibility of the system with various applications.

[0015] Optionally, forwarding the data request to the server through the network includes the following steps: Get the transmission type and direction of the USB request packet; Adding a session identifier to the USB request packet and encapsulating it into a network data packet; Establishing a mapping relationship between the session identifier and the corresponding response data; The network data packet is sent to the server via a network connection.

[0016] By adopting the above technical solution, the present application first identifies the transmission type and transmission direction of the USB request packet, and provides targeted processing for different types of transmission; then generates a unique session identifier for each request packet and encapsulates it into a network data packet; at the same time, the mapping relationship between the session identifier and the expected response data is maintained on the client; finally, the encapsulated data packet is sent to the server through the network connection, thereby achieving accurate correspondence between the request and the response, solving the problem of data confusion during concurrent access, and maintaining stable and reliable operation of the USB device virtualization system.

[0017] Optionally, receiving a data request from a client and passing the data request to a physical USB device for processing specifically includes the following steps: Parse the received network data packet and extract the session identifier and USB request information; Sending the USB request information to the physical USB device through the system interface; Receive response data from the physical USB device; The response data is returned to the corresponding client according to the session identifier.

[0018] 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, and ensures the traceability of the request source; then accurately passes 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, and through the session management mechanism of the entire request process, precise control of server-side data processing is achieved, so that the entire virtualization system can show better reliability in high-concurrency scenarios.

[0019] In a second aspect, the present application provides a USB device virtualization sharing device, comprising: The client simulation module is used to deploy the driver of the simulated USB device in the client system so that the system can recognize the driver of the simulated USB device as a permanently online USB device; The server deployment module is used to deploy the driver of the physical USB device on the server and start the server program to receive the client request; The data forwarding module is used to forward the data request to the server through the network when it is detected that the client application accesses the simulated USB device; The request processing module is used to 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; The response delivery module is used to receive response data by simulating a USB device and pass the data to the client application.

[0020] In a third aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above-mentioned USB device virtualization sharing method when executing the computer program.

[0021] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the above-mentioned USB device virtualization sharing method are implemented.

[0022] In summary, the present application includes at least one of the following beneficial technical effects: 1. This 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 physical device returns the result after processing. This 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 device occupation, significantly improving the use efficiency of USB devices; 2. Some USB dongles may require a long processing time when performing data encryption and decryption, while operations such as status query require a quick response. If a unified timeout threshold is used, it will either cause frequent timeout interruptions for time-consuming operations or cause delays in simple operation responses. This application first obtains the transfer type and endpoint descriptor information of the USB device to set a benchmark timeout threshold for different transfer types. Then, during the operation of the device, response time samples are continuously collected, and the average response time of valid samples is calculated through statistical analysis. Finally, the calculated average response time is compared with the preset benchmark timeout threshold, and the timeout threshold actually used is dynamically adjusted, thereby achieving precise control and adaptive adjustment of the timeout threshold, which not only avoids interruptions of operations due to too low a timeout threshold setting, but also prevents resource occupation due to too high a threshold, thereby improving the stability and efficiency of device sharing. 3. This application first obtains the device descriptor, configuration descriptor and interface descriptor of the target USB device, which contain complete feature information of the device; then, based on these standardized descriptor information, dynamically generates a universal driver that can simulate the behavior of the target device; finally, registers the simulated driver as a system device and sets it to a resident state to ensure that the application can access it continuously and stably, and realizes automatic adaptation and generalization of the driver through the descriptor mechanism in the standard USB protocol, which not only greatly reduces the development and maintenance costs, but also improves the system's compatibility with different types of USB devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a flowchart of a USB device virtualization sharing method according to an embodiment of the present application; Figure 2 It is a flow chart of adjusting the request priority in a USB device virtualization sharing method according to an embodiment of the present application; Figure 3 It is a flowchart of step S110 in a USB device virtualization sharing method according to an embodiment of the present application; Figure 4 It is a flowchart of step S130 in a USB device virtualization sharing method according to an embodiment of the present application; Figure 5It is a flowchart of step S140 in a USB device virtualization sharing method according to an embodiment of the present application; Figure 6 This is a module diagram of a USB device virtualization sharing device according to an embodiment of the present application; Figure 7 It is a diagram of the internal structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] 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 be used as limitations to the present application. As used in the specification and appended claims of the present application, the singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to also include plural expressions, unless there is a clear indication to the contrary in the context. It should also be understood that the term "and / or" used in the present application refers to any or all possible combinations comprising one or more listed items.

[0025] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

[0026] The embodiments of the present application are further described in detail below in conjunction with the drawings in the specification.

[0027] In a first aspect, the present application provides a flow chart of a USB device virtualization sharing method, referring to Figure 1 , including the following steps: S110: deploying a driver for simulating a USB device in the client system, so that the system recognizes the driver for simulating the USB device as a permanently online USB device.

[0028] In this embodiment, the driver of the simulated USB device is deployed in the client system, the main purpose of which is to build a virtual USB device access point in the client system. The simulated driver appears as a permanently online USB device in the system, so that the client application can access the virtual device like accessing a physical USB device. This deployment method of the simulated driver avoids the frequent device plug-in and unplug operations in the traditional USB device sharing solution, and improves the stability of the system.

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

[0030] S120: deploy a driver for the physical USB device on the server side, and start a server program to receive a client request.

[0031] In this embodiment, the driver of the physical USB device is deployed on the server side and the server program is started 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.

[0032] Specifically, the system administrator installs the driver of the physical USB device on the server to ensure that the server can correctly identify and operate the device. For example, for a certain USB shield device, its official driver needs to be installed. Then start the server program, which 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 create a device list for client query and access.

[0033] S130: When it is detected that the client application accesses the simulated USB device, the data request is forwarded to the server through the network.

[0034] In this embodiment, the access request of the client application is detected and forwarded to the server, thus realizing a data communication bridge between the local application and the remote USB device. The simulated USB device driver intercepts the device access request 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.

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

[0036] S140, receiving a data request from the client, passing the data request to the physical USB device for processing, and returning the processing result to the client.

[0037] In this embodiment, receiving and processing the client request 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.

[0038] Specifically, after receiving the client's network request, the server program first parses the request. 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 device's processing result, the server encapsulates the result into a response data packet and sends it back to the corresponding client.

[0039] S150, receiving response data by simulating a USB device, and passing the data to a client application.

[0040] In this embodiment, receiving the response data by simulating the USB device is the last step of this solution, which is responsible for passing the processing result returned by the server to the client application. The simulation driver plays the role of protocol conversion in this process, ensuring that the application can correctly receive and parse the returned data.

[0041] 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 the certificate read operation, the driver will encapsulate the returned certificate data according to the USB protocol specification, and then pass it to the application through the pre-established data channel, so that the application can process the response data like accessing a local USB device.

[0042] In one embodiment, referring to Figure 2 , the method further comprises the steps of: S210: Receive access requests from multiple clients.

[0043] In this embodiment, receiving access requests from multiple clients is a basic step in realizing USB device sharing, and it is necessary to handle concurrent access situations from different clients.

[0044] Specifically, the server program will establish a request queue to store received client requests. For example, when multiple users use a shared dongle device at the same time, the server will store these requests in the queue in the order they are received. For each request, the server will record key information such as its arrival time and request type to provide a basis for subsequent request scheduling.

[0045] S220: Set a request timeout threshold according to a response time characteristic of the USB device.

[0046] 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 transmission types have different response characteristics, so it is necessary to flexibly adjust the timeout threshold according to the actual situation to avoid wasting system resources caused by invalid waiting.

[0047] In this embodiment, step S220 includes obtaining the transmission type and endpoint descriptor of the USB device, and setting the corresponding benchmark timeout threshold according to different transmission 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 benchmark timeout threshold, and dynamically adjusting the timeout threshold actually used.

[0048] Specifically, the system will first set a baseline timeout value based on the transfer type defined in the USB specification (such as control transfer, interrupt transfer, bulk transfer, etc.). For example, a baseline timeout value of 500ms may be set for control transfer, while it may be set to 1000ms for bulk transfer. The system will then continue to monitor the actual response time of the device, collect a certain number of samples, and calculate the average response time. If the average response time is significantly lower than the baseline timeout value, the system will appropriately lower the timeout threshold to improve processing efficiency; if the average response time is close to the baseline timeout value, it may be necessary to appropriately increase the threshold to avoid premature termination of valid requests.

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

[0050] In this embodiment, dynamically adjusting the request priority is a key mechanism to achieve efficient request processing. The system needs to ensure fairness in request processing while preventing some requests from timing out due to long waiting times.

[0051] Specifically, the system will adjust the processing priority of the request based on the waiting time of the request in the queue and the preset timeout threshold. For example, assuming that the timeout threshold of a request is 1000ms, when its waiting time in the queue reaches 800ms, the system will increase the priority of the request so that it can be processed first. For different types of requests, the system will also consider their importance and urgency. For example, identity authentication requests may receive a higher basic priority. Through this dynamic adjustment mechanism, the timeliness of request processing is ensured, and the phenomenon of request processing starvation is avoided.

[0052] In one embodiment, referring to Figure 3 In step S110, deploying a driver for simulating a USB device in the client system specifically includes the following steps: S111. Obtain a device descriptor, a configuration descriptor, and an interface descriptor of a physical USB device.

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

[0054] Specifically, system administrators can use professional USB protocol analysis tools to obtain the descriptor information of the target device. For example, use the USB Protocol Analyzer tool to connect to a physical USB device and capture the descriptor information during the device enumeration process. For a certain dongle device, you can obtain its manufacturer ID (VID), product ID (PID), device type, endpoint configuration and other key parameters, which will be used for the subsequent development of simulation drivers.

[0055] S112: Generate a universal USB device simulation driver according to the descriptor information.

[0056] Specifically, generating a simulation driver based on the descriptor information is the core of the entire virtualization solution. The universal USB device simulation driver needs to be able to accurately simulate the characteristics and behaviors of the physical device so that the application cannot detect the fact that the device is virtualized.

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

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

[0059] In one embodiment, referring 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: S131, intercepting a client application's initialization request for a USB device.

[0060] Specifically, the simulation driver listens to the device access request of the application through the device driver interface provided by the system. For example, when the office software tries to access the USB key for the first time, 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.

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

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

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

[0064] Among them, establishing a data channel is the basis for achieving stable communication between the application and the simulation device. The system needs to create and maintain a reliable data transmission channel to ensure that the application's request can be correctly transmitted and the response data can be accurately returned.

[0065] Specifically, the system creates a two-way communication channel to connect the application and the simulated device. For example, for a bulk transfer type USB device, the system will create a corresponding data buffer and transfer queue, and set up an appropriate synchronization mechanism. Through this channel, the data sent by the application can be reliably transmitted to the simulated device, and the device's response data can be returned to the application in a timely manner.

[0066] Further, the data request is forwarded to the server through the network, which specifically includes the following steps: S134: Obtain the transmission type and transmission direction of the USB request packet.

[0067] S135: Add a session identifier to the USB request packet and encapsulate it into a network data packet.

[0068] In this embodiment, the system generates a unique session identifier for each USB request, which can be generated by using a timestamp, a counter, etc. For example, for a file read request, the system may generate a session identifier including the request time and a sequence number. The USB request data and the session identifier are then encapsulated together into a network data packet to prepare for network transmission.

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

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

[0071] Specifically, the system creates a mapping table to store the correspondence between session identifiers and request information. For example, when a request to read a USB-Shield certificate is sent, the system will record the session identifier, request type, sending time and other information in the mapping table. This information will be used for correct data routing and timeout processing when receiving response data.

[0072] S137. Send the network data packet to the server via the network connection.

[0073] Specifically, the system uses a reliable network transmission protocol to send encapsulated data packets. For example, the system uses the TCP protocol to establish a connection with the server and sets an appropriate send buffer size and timeout parameters. The system monitors the sending status of the data packet and performs retransmission or flow control when necessary to ensure that the data can reach the server reliably.

[0074] In one embodiment, referring to Figure 5 In step S140, a data request from the client is received and the data request is passed to the physical USB device for processing, which specifically includes the following steps: S141, parsing the received network data packet, extracting the session identifier and USB request information.

[0075] S142: Send the USB request information to the physical USB device through the system interface.

[0076] S143, receiving response data from the physical USB device.

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

[0078] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0079] In a second aspect, the present application provides a USB device virtualization sharing apparatus. The USB device virtualization sharing apparatus of the present application is described below in conjunction with the above-mentioned USB device virtualization sharing method.

[0080] Reference Figure 6 , a USB device virtualization sharing device, comprising: The client simulation module is used to deploy the driver of the simulated USB device in the client system so that the system can recognize the driver of the simulated USB device as a permanently online USB device; The server deployment module is used to deploy the driver of the physical USB device on the server and start the server program to receive the client request; The data forwarding module is used to forward the data request to the server through the network when it is detected that the client application accesses the simulated USB device; The request processing module is used to 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; The response delivery module is used to receive response data by simulating a USB device and pass the data to the client application.

[0081] In one embodiment, the present application provides an electronic device, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown. The electronic device includes a processor, a memory and a network interface connected via a system bus. 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 via a network connection. When the computer program is executed by the processor, a USB device virtualization sharing method is implemented.

[0082] Those skilled in the art will understand that Figure 7 The structure shown in the figure is merely a block diagram of a partial structure related to the scheme of the present application, and does not constitute a limitation on the electronic device to which the scheme of the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0083] In one embodiment, an electronic device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0084] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the above-mentioned 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 embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), tape, floppy disk, flash memory or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0085] The above are all preferred embodiments of the present application, and the protection scope of the present application is not limited thereto. Therefore, any equivalent changes made according to the structure, shape, and principle of the present application should be included in the protection scope of the present application.

Claims

1. A USB device virtualization sharing method, characterized in that: The steps include: Deploy the driver of the 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 the physical USB device driver on the server side and start the server program to receive client requests; When it is detected that the client application is accessing the simulated USB device, the data request is forwarded to the server through the network; Receive a 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 response data by emulating the USB device and pass the data to the client application.

2. The USB device virtualization sharing method according to claim 1, characterized in that: The method further comprises the steps of: Receive access requests from multiple clients; Set the request timeout threshold according to the response time characteristics of the USB device; The request priority is dynamically adjusted according to the request arrival order and the request timeout threshold.

3. The USB device virtualization sharing method according to claim 2, characterized in that: The request timeout threshold is set according to the response time characteristics of the USB device, specifically including the following steps: Get 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; The average response time is compared with the reference timeout threshold, and the timeout threshold actually used is dynamically adjusted.

4. The USB device virtualization sharing method according to claim 1, characterized in that: Deploy the driver for emulating a USB device in the client system, including the following steps: Get the device descriptor, configuration descriptor and interface descriptor of the physical USB device; Generate a general USB device simulation driver based on the descriptor information; The simulation driver is registered as a system device, so that the simulation driver remains in a resident state in the system.

5. The USB device virtualization sharing method according to claim 1, characterized in that: When a client application is detected accessing a simulated USB device, the following steps are included: Intercept the client application's initialization request for the USB device; According to the device characteristic parameters in the initialization request, configure the response parameters of the simulated USB device; Establish a data channel between the application and the simulated USB device.

6. The USB device virtualization sharing method according to claim 1, characterized in that: Forwarding the data request to the server through the network includes the following steps: Get the transmission type and direction of the USB request packet; Adding a session identifier to the USB request packet and encapsulating it into a network data packet; Establishing a mapping relationship between the session identifier and the corresponding response data; The network data packet is sent to the server via a network connection.

7. The USB device virtualization sharing method according to claim 6, characterized in that: Receiving a data request from a client and passing the data request to a physical USB device for processing, specifically includes the following steps: Parse the received network data packet and extract the session identifier and USB request information; Sending the USB request information to the physical USB device through the system interface; Receive response data from the physical USB device; The response data is returned to the corresponding client according to the session identifier.

8. A USB device virtualization sharing device, characterized in that: include: The client simulation module is used to deploy the driver of the simulated USB device in the client system so that the system can recognize the driver of the simulated USB device as a permanently online USB device; The server deployment module is used to deploy the driver of the physical USB device on the server and start the server program to receive the client request; The data forwarding module is used to forward the data request to the server through the network when it is detected that the client application accesses the simulated USB device; The request processing module is used to 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; The response delivery module is used to receive response data by simulating a USB device and pass the data to the client application.

9. An electronic device, characterized in that: The invention comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the USB device virtualization sharing method according to any one of claims 1 to 7 when executing the computer program.

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

Images