Cloud drive-based peripheral device calling method and device, electronic equipment and medium

Abstract

The application provides a cloud drive-based peripheral calling method and device, electronic equipment and medium. The method comprises the following steps: establishing the connection between a service device and a first peripheral, and creating a virtual peripheral corresponding to the first peripheral in the service device. The service device is used for representing a Windows Server-based device, the first peripheral is used for representing a Linux-based peripheral device, and the virtual peripheral has a corresponding virtual identifier. In response to a peripheral calling request, the first peripheral is found and called according to the virtual identifier, and a returned calling result is obtained. The application has the beneficial effect that the peripherals connected to the Linux PC terminal can be called by using the traditional Windows driver, and a large number of peripherals, especially some peripherals that are difficult to be reformed by using the Linux driver, can be used by the Linux PC terminal. Therefore, the migration and reform cost of the application from Windows to Linux is reduced.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a cloud-driven method, apparatus, electronic device, and medium for invoking peripherals. Background Technology

[0002] More and more bank branches are using Linux-based terminal computers as the operational channel for business transactions. However, banking transactions rely on a large number of different types of financial peripherals. Many traditional financial peripherals only provide Windows-based drivers and it is difficult to quickly provide Linux drivers. As a result, a large number of financial peripherals cannot be used by Linux terminal computers, making it impossible to conduct business on Linux.

[0003] Currently, the solution for using Windows drivers on Linux is to use the WINE open-source compatibility layer. The WINE framework is installed on the Linux operating system, allowing DLLs to run directly on the WINE framework, thereby enabling the Windows DLL driver to run on Linux and use peripheral functions.

[0004] WINE is a simulation technology that uses the Linux system interface to mimic the Windows Win32 API interface. At the underlying implementation level, it uses Linux calling methods to functionally replace the Windows implementation. Due to the fundamental differences between the two operating system kernels, the performance of WINE's simulation cannot be 100% identical to that of native Windows. Furthermore, differences in kernel scheduling can cause some Win32 APIs to crash under WINE. Therefore, using WINE to simulate a Windows environment for running peripheral DLL drivers is not a stable solution, especially in financial scenarios where stability requirements are extremely stringent. Thus, using WINE to solve the problem of running peripheral DLL drivers on Linux is not feasible. Summary of the Invention

[0005] The main objective of this invention is to propose a cloud-driven method, device, electronic device, and medium for invoking peripherals, thereby improving the stability and correctness of peripheral invoking.

[0006] One aspect of the present invention provides a cloud-driven peripheral invocation method, comprising:

[0007] Establish a connection between a service device and a first peripheral device, and create a virtual peripheral device on the service device that corresponds to the first peripheral device. The service device is used to represent a Windows Server-based device, the first peripheral device is used to represent a Linux-based peripheral device, and the virtual peripheral device has a corresponding virtual identifier.

[0008] In response to a peripheral device call request, the first peripheral device is located and called based on the virtual identifier, and the returned call result is obtained.

[0009] According to the cloud-driven peripheral invocation method, establishing a connection between a service device and a first peripheral, and creating a virtual peripheral corresponding to the first peripheral on the service device, includes:

[0010] Based on the first peripheral device connected, determine the Linux device connected to the first peripheral device, and determine the binding list between the Linux device and the first peripheral device;

[0011] Obtain the network address and connection identifier of the Linux device;

[0012] The virtual peripheral is generated using the network address and the connection identifier.

[0013] According to the cloud-driven peripheral invocation method, the network address and connection identifier are configured as an IP address and a USB bus identifier, respectively, wherein the USB bus identifier is the USB bus number of the connection between the Linux device and the first peripheral.

[0014] According to the cloud-driven peripheral invocation method, in response to a peripheral invocation request, finding and invoking the first peripheral based on the virtual identifier includes:

[0015] Based on the peripheral device call request, obtain the peripheral device call instruction;

[0016] The peripheral device call command is parsed to obtain USB data, which is then sent to the Linux device.

[0017] The Linux device sends the USB data to the first peripheral device and processes it, obtains return information, and sends the return information back to the service device.

[0018] According to the cloud-driven peripheral invocation method, the method further includes intercepting the peripheral invocation request, searching for the corresponding Linux device and the first peripheral from the binding list according to the peripheral invocation instruction, so as to redirect the peripheral invocation request.

[0019] According to the cloud-driven peripheral invocation method, parsing the peripheral invocation command to obtain USB data includes:

[0020] The peripheral call instructions are parsed using a dynamic link library, and the resulting USB data is USB binary instructions.

[0021] Another aspect of the present invention provides a cloud-driven peripheral invocation device, comprising:

[0022] The cloud driver module is used to establish a connection between the service device and the first peripheral device, and to create a virtual peripheral device on the service device that corresponds to the first peripheral device. The service device is used to represent a Windows Server-based device, the first peripheral device is used to represent a Linux-based peripheral device, and the virtual peripheral device has a corresponding virtual identifier.

[0023] The peripheral device invocation module is used to locate and invoke the first peripheral device according to the virtual identifier based on the peripheral device invocation request, and obtain the returned invocation result.

[0024] Another aspect of the present invention provides an electronic device, including a processor and a memory;

[0025] The memory is used to store programs;

[0026] The processor executes the program to implement the method as described above.

[0027] This invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium and execute the computer instructions, causing the computer device to perform the methods described above.

[0028] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0029] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0030] Figure 1 This is a flowchart illustrating the cloud-driven peripheral invocation method according to an embodiment of the present invention.

[0031] Figure 2 This is a network topology diagram of cloud-driven peripheral device tuning according to an embodiment of the present invention.

[0032] Figure 3 This is a schematic diagram of the cloud-driven construction process according to an embodiment of the present invention.

[0033] Figure 4 This is a schematic diagram of the peripheral redirection process according to an embodiment of the present invention.

[0034] Figure 5This is a diagram of a cloud-driven peripheral calling device according to an embodiment of the present invention. Detailed Implementation

[0035] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings. Throughout the description, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions. In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the purpose of illustrative purposes and have no specific meaning in themselves. Therefore, "module," "part," or "unit" can be used interchangeably. Terms such as "first," "second," etc., are used only to distinguish technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the sequential relationship of the indicated technical features. In the following description, the consecutive reference numerals for method steps are for ease of review and understanding. Adjusting the implementation order of steps, in conjunction with the overall technical solution of the present invention and the logical relationship between the various steps, will not affect the technical effect achieved by the technical solution of the present invention. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0036] Terminology Explanation:

[0037] WINE: Wine Is Not a Emulator, an open-source compatibility layer that emulates the Windows API on Linux systems, enabling Windows programs to run on Linux systems.

[0038] DLL: Dynamic Link Library. A software function module on Windows. Peripheral drivers are generally provided in the form of dynamic link libraries.

[0039] VID:PID: USB vendor identifier and product identifier.

[0040] For example, refer to Figure 1 It discloses a flowchart of a cloud-driven peripheral invocation method, which includes, but is not limited to, steps S100 to S200:

[0041] S100: Establish a connection between the service device and the first peripheral device, and create a virtual peripheral device on the service device that corresponds to the first peripheral device. The service device is used to represent a Windows Server-based device, and the first peripheral device is used to represent a Linux-based peripheral device. The virtual peripheral device has a corresponding virtual identifier.

[0042] In some embodiments, the first peripheral is used to represent a real peripheral device;

[0043] In some embodiments, reference Figure 2 The network topology diagram shown includes a Windows Server service device, a Linux-PC device, and peripheral devices such as card reader 1, card reader 2, and card reader 3, printer 1, printer 2, and printer 3. The Linux-PC device is connected to the peripheral devices via a USB bus.

[0044] In some embodiments, based on Figure 2 Based on the topological relationship, embodiments of the present invention provide a schematic diagram of a cloud-driven construction process, including but not limited to steps S110 to S130:

[0045] S110: Based on the first connected peripheral, determine the Linux device to which the first peripheral is connected, and determine the binding list between the Linux device and the first peripheral.

[0046] In some embodiments, by establishing a network connection between the peripheral device and the Windows Server, the corresponding peripheral device is virtualized on the Windows Server, and the network location of the actual peripheral device can be located through the device identifier;

[0047] For example, a peripheral device is physically connected to a specific Linux terminal device via USB. Using the Linux kernel's USBIP technology, a virtual "USB" device with the same information is established on the Windows Server of the edge service. This device has the same VID:PID information as the actual device connected on the Linux terminal. The Windows Server will consider this "device" to be a real, usable USB device.

[0048] In some embodiments, each Windows Server instance can manage multiple virtual "USB" devices of the same and different models.

[0049] S120, obtain the network address and connection identifier of the Linux device;

[0050] For example, during the network connection establishment process, the Windows Server user specifies the information of the peripheral device to be bound within the local area network. This information includes: the IP address of the Linux PC to which the peripheral device is connected and its corresponding USB bus number, etc.

[0051] S130 generates virtual peripherals using network addresses and connection identifiers.

[0052] For example, Windows Server uses this information to generate a virtual USB device, with the device's instance ID set to the format "IP:BUS" (e.g., "10.8.1.11:1-4.1").

[0053] S200, in response to a peripheral call request, locates and calls the first peripheral based on the virtual identifier, and obtains the returned call result.

[0054] In some embodiments, based on Figure 2 The topology diagram shown, and refer to, as Figure 4 The peripheral redirection process diagram shown includes, but is not limited to, steps S210 to 230:

[0055] S210 redirects the request to a specific virtual USB device based on the peripheral call request.

[0056] For example, a peripheral driver located on the Windows Server can be used for USB peripherals connected to a Linux PC. When an application calls a peripheral, the call request is redirected to the Windows Server.

[0057] In traditional Windows driver design, if several peripherals of the same model are connected to the system, the DLL will only select one to send instructions. However, in this system, since the same type of peripherals are actually connected to different Linux PC terminals, it is necessary to send instructions precisely to a specific peripheral. To solve this problem, this solution provides a method to intercept the instructions before Windows executes the actual USB call and redirect them to the actual "virtual USB device" based on the virtual tag generated when the cloud driver is created. The technical solution in this embodiment intercepts the randomly selected USB handle in the traditional Windows driver mechanism and replaces it with a specified USB handle, thereby enabling the instructions to be accurately transmitted to the specific peripheral.

[0058] S220 parses peripheral call commands, obtains USB data, and sends the USB data to the actual Linux device corresponding to the virtual USB device;

[0059] In some embodiments, Windows Server calls the corresponding method of the peripheral DLL to generate USB binary instructions, which are then transmitted to the corresponding peripheral via USBIP to invoke the peripheral's functions.

[0060] The S230 sends USB data to the first peripheral device via a Linux device, processes it, receives the return information, and sends the return information back to the service device.

[0061] According to the embodiments shown in this invention, the technical solution of this invention has at least the following beneficial effects: it enables peripherals connected to Linux PC terminals to be called using traditional Windows drivers, and a large number of peripherals, especially some peripherals that are difficult to modify for Linux-based drivers, can be used by Linux PC terminals. This reduces the migration and modification costs of applications from Windows to Linux.

[0062] like Figure 5 As shown, this embodiment of the invention also provides a cloud-driven peripheral device invocation device, which includes a cloud-driven module 501 and a peripheral device invocation module 502.

[0063] The cloud-driven module is used to establish a connection between the service device and the first peripheral device, and to create a virtual peripheral device corresponding to the first peripheral device on the service device. The service device is used to represent a Windows Server-based device, and the first peripheral device is used to represent a Linux-based peripheral device. The virtual peripheral device has a corresponding virtual identifier. The peripheral device invocation module is used to find and invoke the first peripheral device according to the virtual identifier based on the peripheral device invocation request, and to obtain the returned invocation result.

[0064] Exemplarily, with the collaboration of the cloud-driven module and the peripheral device invocation module in the device, the embodiment device can implement any of the aforementioned cloud-driven peripheral invocation methods. Specifically, it establishes a connection between a service device and a first peripheral, and creates a virtual peripheral corresponding to the first peripheral on the service device. The service device represents a Windows Server-based device, and the first peripheral represents a Linux-based peripheral device. The virtual peripheral has a corresponding virtual identifier. In response to a peripheral invocation request, the first peripheral is located and invoked based on the virtual identifier, and the returned invocation result is obtained. The beneficial effects of this invention are: introducing Windows Server on the edge server, installing DLLs natively on the Windows server, and having the DLLs run natively on the edge server, thus ensuring operational stability and correctness. The DLL execution generates the actual binary instructions for the peripheral, which are directly executed by the Linux computing terminal, enabling the peripheral to run correctly on the Linux terminal. This solution brings a more stable and correct peripheral DLL driver usage method to Linux computing terminals.

[0065] This invention also provides an electronic device, which includes a processor and a memory;

[0066] The memory stores the program;

[0067] The processor executes the program to perform the aforementioned cloud-driven peripheral invocation method; the electronic device has the function of carrying and running the software system for raw USB data interaction provided in the embodiments of the present invention, such as a personal computer (PC), mobile phone, smartphone, personal digital assistant (PDA), wearable device, handheld computer (PPC), tablet computer, etc.

[0068] This invention also provides a computer-readable storage medium storing a program that is executed by a processor to implement the cloud-driven peripheral invocation method described above.

[0069] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is altered and sub-operations described as part of a larger operation are executed independently.

[0070] This invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium and execute the computer instructions, causing the computer device to perform the aforementioned cloud-driven peripheral invocation method.

[0071] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the described functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0072] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0073] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0074] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0075] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0076] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0077] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0078] The above is a detailed description of the preferred embodiments of the present invention, but the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A cloud-driven peripheral invocation method, characterized in that, include: Establish a connection between a service device and a first peripheral device, and create a virtual peripheral device on the service device that corresponds to the first peripheral device. The service device is used to represent a Windows Server-based device, the first peripheral device is used to represent a Linux-based peripheral device, and the virtual peripheral device has a corresponding virtual identifier. In response to a peripheral device call request, the first peripheral device is located and called based on the virtual identifier, and the returned call result is obtained; The step of establishing a connection between the service device and the first peripheral, and creating a virtual peripheral corresponding to the first peripheral on the service device, includes: Based on the first peripheral device connected, determine the Linux device connected to the first peripheral device, and determine the binding list between the Linux device and the first peripheral device; Obtain the network address and connection identifier of the Linux device; The virtual peripheral is generated using the network address and the connection identifier; The step of responding to a peripheral device call request by locating and calling the first peripheral device based on the virtual identifier includes: Based on the peripheral device call request, obtain the peripheral device call instruction; The peripheral device call command is parsed to obtain USB data, which is then sent to the Linux device. The Linux device sends the USB data to the first peripheral device and processes it, obtains return information, and sends the return information back to the service device. The process of parsing the peripheral device call command to obtain USB data includes: The peripheral call instructions are parsed using a dynamic link library, and the resulting USB data is USB binary instructions.

2. The cloud-driven peripheral invocation method according to claim 1, characterized in that, The network address and connection identifier are configured as an IP address and a USB bus identifier, respectively, whereby the USB bus identifier is the USB bus number used to connect the Linux device to the first peripheral.

3. The cloud-driven peripheral invocation method according to claim 1, characterized in that, The method further includes intercepting the peripheral call request, and searching for the corresponding Linux device and the first peripheral from the binding list according to the peripheral call instruction, so as to redirect the peripheral call request.

4. A cloud-driven peripheral device invocation device, characterized in that, include: The cloud driver module is used to establish a connection between the service device and the first peripheral device, and to create a virtual peripheral device on the service device that corresponds to the first peripheral device. The service device is used to represent a Windows Server-based device, the first peripheral device is used to represent a Linux-based peripheral device, and the virtual peripheral device has a corresponding virtual identifier. The peripheral device invocation module is used to locate and invoke the first peripheral device according to the virtual identifier based on the peripheral device invocation request, and obtain the returned invocation result; The step of establishing a connection between the service device and the first peripheral, and creating a virtual peripheral corresponding to the first peripheral on the service device, includes: Based on the first peripheral device connected, determine the Linux device connected to the first peripheral device, and determine the binding list between the Linux device and the first peripheral device; Obtain the network address and connection identifier of the Linux device; The virtual peripheral is generated using the network address and the connection identifier; The step of locating and invoking the first peripheral device based on the virtual identifier according to the peripheral device call request includes: Based on the peripheral device call request, obtain the peripheral device call instruction; The peripheral device call command is parsed to obtain USB data, which is then sent to the Linux device. The Linux device sends the USB data to the first peripheral device and processes it, obtains return information, and sends the return information back to the service device. The process of parsing the peripheral device call command to obtain USB data includes: The peripheral call instructions are parsed using a dynamic link library, and the resulting USB data is USB binary instructions.

5. An electronic device, characterized in that, Including the processor and memory; The memory is used to store programs; The processor executes the program to implement the cloud-driven peripheral invocation method as described in any one of claims 1-4.

6. A computer-readable storage medium, characterized in that, The storage medium stores a program, which is executed by a processor to implement the cloud-driven peripheral invocation method as described in any one of claims 1-4.

Images