WO2017185952A1 - 一种硬件设备的访问管理方法及系统 - Google Patents

一种硬件设备的访问管理方法及系统 Download PDF

Info

Publication number
WO2017185952A1
WO2017185952A1 PCT/CN2017/079355 CN2017079355W WO2017185952A1 WO 2017185952 A1 WO2017185952 A1 WO 2017185952A1 CN 2017079355 W CN2017079355 W CN 2017079355W WO 2017185952 A1 WO2017185952 A1 WO 2017185952A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
server
connection request
hardware device
data packet
Prior art date
Application number
PCT/CN2017/079355
Other languages
English (en)
French (fr)
Inventor
梁建明
熊飞
陈明宇
张雲瑞
罗忠明
Original Assignee
广州广电运通金融电子股份有限公司
广州广电运通信息科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 广州广电运通金融电子股份有限公司, 广州广电运通信息科技有限公司 filed Critical 广州广电运通金融电子股份有限公司
Publication of WO2017185952A1 publication Critical patent/WO2017185952A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/25—Routing or path finding in a switch fabric
    • H04L49/253—Routing or path finding in a switch fabric using establishment or release of connections between ports
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user

Definitions

  • the present invention relates to the field of self-service terminal technologies, and in particular, to a method and system for access management of a hardware device.
  • an object of the present invention is to provide an access management method and system for a hardware device, which can enable the upper layer application to securely establish a connection with the hardware device without using a non-root authority.
  • the invention provides a method for access management of a hardware device, comprising the following steps:
  • the server establishes a connection with the hardware device when detecting that the hardware device accesses the predetermined interface, and creates a listening thread to listen for a connection request from the client; wherein the server starts with root authority;
  • the listening thread of the server is listening to the connection request from the client, and after verifying the connection request, creating a service thread serving the connection request;
  • the service thread of the server receives the protocol data packet sent by the client, invokes a corresponding function according to the protocol data packet, establishes a connection with the interface, and serializes the output parameter of the function and returns
  • the client is caused to cause the client to deserialize the output parameter of the function, write it to the function parameter table, and return it to the corresponding upper application through the driver.
  • the protocol data packet is serialized by the client after receiving the communication interface of the upper layer application by calling the driver to access itself, and serializing the interface data generated according to the access, and generating the serialization process
  • the binary data stream is packaged and generated.
  • the server is started by the Linux system through the inetd daemon with root privileges;
  • the server automatically starts when the Android system is started with root privileges, wherein an application library based on TCP/IP communication is established in the NDK layer of the Android system, and then built on the bottom layer of Android.
  • the server is generated based on a communication service of TCP/IP.
  • the listening thread of the server is configured to listen to the connection request from the client, and after the connection request is verified, create a service thread that serves the connection request, and specifically includes:
  • the service thread of the server receives the protocol data packet sent by the client, calls a corresponding function according to the protocol data packet, establishes a connection with the interface, and serializes the output parameter of the function. After processing, returning to the client, specifically:
  • serialized output parameters are sent to the client.
  • the invention also provides an access management method for a hardware device, comprising the following steps:
  • the server establishes a connection with the hardware device when detecting that the hardware device accesses the predetermined interface, and creates a listening thread to listen for a connection request from the client; wherein the server starts with root authority;
  • the client initiates a connection request to the server
  • the listening thread of the server is listening to the connection request from the client, and after verifying the connection request, creating a service thread serving the connection request;
  • the service thread of the server establishes a connection with the interface according to the protocol data packet, and serializes the output parameter of the function, and returns the result to the client;
  • the client de-serializes the output parameters of the function, writes them to the function parameter table, and returns them to the corresponding upper-layer application through the driver.
  • the method before the client sends the protocol data packet to the service thread of the server, the method further includes:
  • the client After receiving the communication interface that the upper layer application accesses the driver by calling the driver, the client serializes the interface data generated according to the access, and packages the binary data stream generated by the serialization process to generate protocol data. package. .
  • the listening thread of the server is configured to listen to the connection request from the client, and after the connection request is verified, create a service thread that serves the connection request, and specifically includes:
  • the service thread of the server is configured to establish a connection with the interface according to the protocol data packet, and the output parameter of the function is serialized and returned to the client, which specifically includes:
  • serialized output parameters are sent to the client.
  • the invention also provides an access management system for a hardware device, comprising a client and a server, wherein:
  • the server is configured to establish a connection with the hardware device when detecting that the hardware device accesses the predetermined interface, and create a listening thread to listen for a connection request from the client; wherein the server has root privileges start up;
  • the client is configured to initiate a connection request to the server
  • the server is configured to: when the listening thread listens to a connection request from the client, and after the connection request is verified, create a service thread that serves the connection request;
  • the client is configured to serialize the interface data generated according to the access after receiving the communication interface of the upper layer application by calling the corresponding driver, and package the binary data stream generated by the serialization process into protocol data. a service thread sent by the package to the server;
  • the server is configured to establish a connection with the interface by calling the corresponding function according to the protocol data packet, and serializing the output parameter of the function to return to the client;
  • the client is configured to deserialize the output parameter of the function, write it to the function parameter table, and return it to the corresponding upper application through the driver.
  • the access management method and system for the hardware device provided by the embodiment of the present invention establish a server that can be started with root authority in a Linux system environment or an Android system environment, and implement connection and access management on the connected hardware device.
  • the upper layer application can securely establish a connection with the hardware device through the server in the case of non-root authority.
  • the server can configure one service thread for each upper layer application, multiple upper layer applications can share one hardware device.
  • FIG. 1 is a schematic diagram of interaction between an access management system of a hardware device and an upper layer application and a hardware device according to an embodiment of the present invention.
  • FIG. 2 is a schematic diagram of the operation of an access management system for a hardware device according to an embodiment of the present invention.
  • FIG. 3 is a data structure diagram of a protocol data packet according to an embodiment of the present invention.
  • FIG. 4 is a schematic flowchart of an access management method of a hardware device according to an embodiment of the present invention.
  • FIG. 5 is a schematic diagram of specific execution steps of a server provided by an embodiment of the present invention.
  • FIG. 6 is a schematic diagram of specific execution steps of a service thread of a server according to an embodiment of the present invention.
  • FIG. 7 is a schematic flowchart of an access management method of a hardware device according to an embodiment of the present invention.
  • FIG. 8 is a schematic flowchart of an access management method of a hardware device according to an embodiment of the present invention.
  • an embodiment of the present invention provides a hardware device access management system 100 for authorizing and managing access and connection of hardware devices in a Linux system environment or an Android system environment.
  • the hardware device access management system 100 includes a client 10 and a server 20.
  • the server 20 is configured to establish a connection with the hardware device when detecting that the hardware device accesses the predetermined interface, and create a monitoring thread to listen for a connection request from the client 10; wherein the server Start with root privileges.
  • the server 20 actively reads the communication configuration after startup, and detects that an external hardware device passes the interface (the interface can be a serial port or a USB interface, such as the serial port 301 in FIG. 1).
  • the interface can be a serial port or a USB interface, such as the serial port 301 in FIG. 1.
  • the server 20 can establish a connection with the hardware device, and the hardware and the hardware will succeed.
  • the connection data that the device establishes the connection is saved to the connection pool, and a listener thread is created to listen for the connection request from the client 10.
  • the server 20 is started with root privileges.
  • the server 20 can be started by the Linux system through the inetd daemon with root privileges; and in the Android system environment.
  • the server 20 automatically starts when the Android system is started with root privileges, wherein the server 20 can establish a client application library based on TCP/IP communication in the NDK layer of the Android system, and then in the Android
  • the underlying layer is built based on a communication service based on TCP/IP.
  • the client 10 is configured to initiate a connection request to the server 20.
  • the upper layer application 200 calls the corresponding driver (such as the driver 201 shown in FIG. 1, and of course, the driver 202, the driver 203... for convenience of description, the following is defined as the driver 201)
  • the client 10 is triggered to initiate a connection request to the server 20.
  • the client 10 can initiate a connection request with the listening thread of the server 20 through TCP/IP.
  • the server 20 is configured to: when the listening thread listens to the connection request from the client 10, and after the connection request is verified, create a service thread that serves the connection request.
  • the listening thread of the server 20 performs a handshake check every time a connection request is received. After the verification succeeds, the listening thread establishes a communication service, and the communication service Actively creating a service thread for servicing the current connection request, and handing the connection descriptor in the connection request to the service thread for management, after the service thread is established, the client 10 can The data channel of the server 20 performs data interaction.
  • the client 10 is configured to serialize the interface data generated according to the access and receive the binary data stream generated by the serialization process after receiving the upper layer application 200 to access the communication interface of the host by calling the corresponding driver 201.
  • the protocol data packet is sent to the service thread of the server 20.
  • the client 10 waits for the upper-layer application 200 to call its own communication interface, that is, waits for the upper-layer application 200 to actively invoke the driver 201, thereby issuing a communication interface that invokes the client 10, when the communication interface is invoked.
  • Corresponding interface data will be generated, and the client 10 serializes the interface data, that is, processes the interface data into a binary data stream, and packages the binary data stream into a protocol data packet.
  • the service thread to the server 20.
  • FIG. 3 is a schematic diagram of the data structure of the protocol data packet.
  • the protocol packet includes the following fields:
  • Synchronization header field (GRGB) D11 for accurately locating the header position of the data packet
  • a check code field (CRC) D12 is used to correct the correctness of each packet header data to improve the accuracy of the data packet.
  • the data used to generate the check code is a CMD field, an ID field, an ERROR field, and a LEN field.
  • CMD Command field D13, used to describe the command description of the current data packet, such as initialization command, initialization response, call function command, call function response and close connection;
  • the session field (ID) D14 is used to describe the session ID of the current command CMD, that is, the integrity of the context of each data interaction is guaranteed;
  • Error code field (ERROR) D15 used to describe the sequence number of the error message during the call. If the call is successful, the disposition is 0, otherwise it is set to a value other than 0.
  • Data length field (LEN) D16 used to describe the actual data length of the DATA field, set to 0 if there is no DATA field, otherwise set to the actual data length;
  • Data body field (DATA) D17 actual data during the interaction (binary data segment), length specified by LEN.
  • the server 20 is configured to establish, by the service thread, a connection with the interface according to the protocol data packet, and serialize the output parameter of the function, and then return the result to the client. 10.
  • the service thread performs necessary initialization operations when starting, and then waits to receive the protocol data packet of the client 10, and after receiving the protocol data packet, the service thread processes the protocol data packet. Perform parsing, deserialize the parsed protocol data, and create a corresponding parameter table. Thereafter, the service thread reads the command ID (included in the CMD field D13) in the protocol data, and calls a function corresponding to the command ID, and then serializes the output parameter data of the function. And sent to the client 10.
  • the client 10 is configured to deserialize the output parameter of the function, write the function parameter table, and drive 201 Return to the corresponding upper application 200.
  • the client 10 deserializes the output parameter of the function, and writes the deserialized output parameter into the function parameter table, and returns it to the corresponding upper application 200 through the driver 201.
  • the upper layer application 200 can securely establish a connection with the hardware device and achieve access to the hardware device in the case of non-root privileges.
  • the access management system 100 for a hardware device establishes a server 20 that can be started with root privileges in a Linux system environment, and implements connection and access management for the connected hardware devices.
  • the upper layer application 200 is enabled to securely establish a connection with the hardware device by the access management system 100 of the hardware device with non-root privileges.
  • the server 20 can configure one service thread for each upper layer application 200, a plurality of upper layer applications can share one hardware device.
  • FIG. 4 is a method for accessing a hardware device according to an embodiment of the present invention.
  • the access management method of the hardware device is described from the server side, and includes the following steps:
  • the server When detecting that the hardware device accesses the predetermined interface, the server establishes a connection with the hardware device, and creates a listening thread to listen for a connection request from the client.
  • the server starts with root privileges.
  • the listening thread of the server listens to a connection request from the client, and after the connection request is verified, creates a service thread that serves the connection request.
  • the service thread of the server receives a protocol data packet sent by the client, invokes a corresponding function according to the protocol data packet, establishes a connection with the interface, and serializes an output parameter of the function. Then, the client returns to the client, so that the client de-serializes the output parameter of the function, writes it to the function parameter table, and returns the driver to the corresponding upper-layer application through the driver.
  • the protocol data packet is serialized by the client after receiving the communication interface of the upper layer application by calling the driver to access itself, and serializing the interface data generated according to the access, and generating the serialization process.
  • the binary data stream is packaged and generated.
  • the access management method of the hardware device establishes a server that can be started with root authority in a Linux system environment, and implements connection and access management on the connected hardware device, so that the upper layer application can be In the case of non-root privileges, a connection is established with the hardware device securely through the server.
  • the server can configure one service thread for each upper layer application, multiple upper layer applications can share one hardware device.
  • FIG. 5 is a schematic diagram of specific execution steps of the server, including:
  • S201 The server actively reads the communication configuration when starting the server, and establishes a connection with the hardware device.
  • S202 The server saves the connection data that successfully establishes a connection with the hardware device to the connection pool, and creates a monitoring thread.
  • S203 The server listens for a connection request of the client.
  • S204 The server determines whether there is a legal connection request, and if it has a legitimate connection, continues to execute S205, otherwise, the process goes to S203.
  • S205 The server locates the handshake packet by using the information of the data packet header in the connection request.
  • S206 The server checks whether the handshake data packet is legal. If the handshake data packet is legal, the process proceeds to S208, otherwise, S207 is performed.
  • S207 Disconnect the connection request with the client, release the resource created when the connection is made, and jump to S203.
  • S208 Create a service thread serving the connection request and the required resources, and allocate connection usage rights to the client, and jump to S203 to continue waiting for the next connection request.
  • FIG. 6 is a schematic diagram of specific execution steps of the service thread of the server, including:
  • S303 Determine whether a protocol data packet is received, if S304 is performed, otherwise jump to S302 to continue to wait for receiving the protocol data packet;
  • S305 Perform deserialization operation on the protocol data obtained by parsing the protocol data packet, and create a corresponding parameter table.
  • S306 Identify the command ID in the protocol data, if the command ID can be identified, then execute S308, otherwise execute S307;
  • S307 returning a communication protocol packet with a wrong command to the client, and then jumping to S302 to continue to wait for receiving the protocol data packet;
  • FIG. 7 is a schematic flowchart of a method for accessing a hardware device according to an embodiment of the present invention. The method is described from the client side, and includes the following steps:
  • the client connects to the server by using a TCP/IP interface through a communication interface.
  • S402 The client determines the connection status. If a legal connection has been established, the process proceeds to S403, otherwise, the process proceeds to S410.
  • S404 The client verifies that the handshake is successful. If the verification succeeds, the process proceeds to S405, otherwise, the process proceeds to S410.
  • S405 The client waits for the upper layer application to call the corresponding communication interface, that is, waits for the upper layer application to actively invoke the driver, thereby accessing the communication interface;
  • the client serializes the interface data generated by the access, that is, processes the interface data into a binary data stream.
  • the client packages the serialized binary data stream into a service thread sent by the protocol data packet to the server;
  • S408 The client waits for a response from the service thread of the server, or waits for the response to time out;
  • S409 The client deserializes the serialized output parameter returned by the server, and backfills the function parameter table, returns to the upper application, and jumps to S405;
  • FIG. 8 is a schematic flowchart of a method for access management of a hardware device according to an embodiment of the present invention.
  • the description of the interaction between the client and the server side includes the following steps:
  • S501 The server establishes a connection with the hardware device when detecting that the hardware device accesses the predetermined interface, and creates a listening thread to listen for a connection request from the client; wherein the server starts with root authority.
  • S502 The client initiates a connection request to the server.
  • S503 The listening thread of the server listens to a connection request from the client, and after the connection request is verified, creates a service thread that serves the connection request.
  • S504 The client protocol data packet is sent to a service thread of the server.
  • the protocol data packet is serialized by the client after receiving the communication interface of the upper layer application by calling the corresponding driver, and serializing the interface data generated according to the access, and serializing the generated binary data.
  • Stream package generation is a technique for generating the protocol data packet.
  • S505 The service thread of the server establishes a connection with the interface according to the protocol data packet, and serializes the output parameter of the function, and returns the result to the client.
  • S506 The client de-serializes the output parameter of the function, and writes the deserialized output parameter into the function parameter table, and returns the driver to the corresponding upper-layer application through the driver.
  • the access management method of the hardware device establishes a server that can be started with root authority in a Linux system environment, and implements connection and access management on the connected hardware device, so that the upper layer application can be In the case of non-root privileges, a connection is established with the hardware device securely through the server.
  • the server can configure one service thread for each upper layer application, multiple upper layer applications can share one hardware device.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Technology Law (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种硬件设备的访问管理方法，包括：服务端在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程；监听线程在监听到来自所述客户端的连接请求，创建服务于所述连接请求的服务线程；服务线程接收来自客户端发送的协议数据包，根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端，以使所述客户端对所述函数的输出参数进行反序列化后写入函数参数表后，并通过驱动返回给对应的上层应用；本发明还公开了一种硬件设备的访问管理系统，可使得上层应用可在非root权限的情况下，安全的与所述硬件设备建立连接。

Description

一种硬件设备的访问管理方法及系统 技术领域
本发明涉及自助终端技术领域，尤其涉及一种硬件设备的访问管理方法及系统。
背景技术
在Linux系统中，访问硬件设备(主要有串口的设备和USB接口的设备)需要root权限，但上层应用的操作不需要root权限也可以进行正常业务流程，并且在Linux系统中不提倡使用root权限直接运行程序，更不提倡使用root登陆到桌面，这样就会存在安全风险，导致系统不稳定现象。在Android的环境(Android也是基于Linux内核的嵌入式小型系统)中是不允许直接访问硬件设备(主要有串口的设备和USB接口的设备)，原因是因为Android系统会在启动应用程序时会自动创建一个临时用户运行程序，并在经过裁剪后的C++环境下运行的，但与硬件设备建立通信必须要使用root权限，并且需要比较全面的Linux环境的函数集。
由上述可知，在Linux系统或Android系统中，若需要直接访问硬件设备，则需要使用root权限，但是使用root权限又可能存在安全风险和隐患，因而开发一套能够对硬件设备的连接进行管理和授权的设备管理系统对Linux系统显得尤为重要。
发明内容
针对上述问题，本发明的目的在于提供一种硬件设备的访问管理方法及系统，可使得所述上层应用可在非root权限的情况下，安全的与所述硬件设备建立连接。
本发明提供了一种硬件设备的访问管理方法，包括如下步骤：
服务端在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程，以监听来自客户端的连接请求；其中，所述服务端以root权限启动；
所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程；
所述服务端的服务线程接收来自所述客户端发送的协议数据包，根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端，以使所述客户端对所述函数的输出参数进行反序列化后写入函数参数表后，并通过驱动返回给对应的上层应用。
优选地，所述协议数据包由所述客户端在接收到所述上层应用通过调用所述驱动访问自身的通信接口后，对根据访问产生的接口数据进行序列化处理，并对序列化处理生成的二进制数据流进行打包生成。
优选地，在Linux系统环境下，所述服务端由Linux系统通过inetd守护进程以root权限启动；
在Android系统环境下，所述服务端以root权限在Android系统启动的时自动启动，其中，通过在Android系统的NDK层建立一个基于TCP/IP通信的客户端的应用库，然后在Android的底层建立基于TCP/IP的一个通信服务来生成所述服务端。
优选地，所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程，具体包括：
监听来自客户端的连接请求；
判断是否有合法的连接请求，若有，则获取所述连接请求中的数据包头的信息定位数据包，读取握手数据包；
检查所述握手数据包是否合法，若合法，则创建服务于所述连接请求的服务线程，并分配连接使用权给所述客户端；若不合法，则拒绝所述客户端的连接请求。
优选地，所述服务端的服务线程接收来自所述客户端发送的协议数据包，根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端，具体包括：
接收所述客户端发送的协议数据包；
对接收的所述协议数据包进行解析，将解析得到的协议数据进行反序列化，并创建相应的函数参数表；
识别所述协议数据中的命令ID，调用所述命令ID所对应的函数建立与所述接口的连接，并对所述函数的输出参数进行序列化处理；
将序列化后的输出参数发送给所述客户端。
本发明还提供一种硬件设备的访问管理方法，包括如下步骤：
服务端在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程，以监听来自客户端的连接请求；其中，所述服务端以root权限启动；
所述客户端向所述服务端发起连接请求；
所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程；
所述客户端将协议数据包发送给所述服务端的服务线程；
所述服务端的服务线程根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端；
所述客户端对所述函数的输出参数进行反序列化后写入函数参数表后，并通过驱动返回给对应的上层应用。
优选地，在所述客户端将协议数据包发送给所述服务端的服务线程之前，还包括：
所述客户端在接收到所述上层应用通过调用所述驱动访问自身的通信接口后，对根据访问产生的接口数据进行序列化处理，并对序列化处理生成的二进制数据流进行打包生成协议数据包。。
优选地，所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程，具体包括：
监听来自客户端的连接请求；
判断是否有合法的连接请求，若有，则获取所述连接请求中的数据包头的信息定位数据包，读取握手数据包；
检查所述握手数据包是否合法，若合法，则创建服务于所述连接请求的服务线程，并分配连接使用权给所述客户端；若不合法，则拒绝所述客户端的连接请求。
优选地，所述服务端的服务线程根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端，具体包括：
解析所述协议数据包，将解析得到的协议数据进行反序列化，并创建相应的函数参数表；
识别所述协议数据中的命令ID，调用所述命令ID所对应的函数建立与所述接口的连接，并对所述函数的输出参数进行序列化处理；
将序列化后的输出参数发送给所述客户端。
本发明还提供一种硬件设备的访问管理系统，包括客户端及服务端，其中：
所述服务端，用于在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程，以监听来自客户端的连接请求；其中，所述服务端以root权限启动；
所述客户端，用于向所述服务端发起连接请求；
所述服务端，用于在所述监听线程监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程；
所述客户端，用于在接收到上层应用通过调用对应的驱动访问自身的通信接口后，对根据访问产生的接口数据进行序列化处理，并将序列化处理生成的二进制数据流打包成协议数据包发送给所述服务端的服务线程；
所述服务端，用于在所述服务线程根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端；
所述客户端，用于对所述函数的输出参数进行反序列化后写入函数参数表后，并通过驱动返回给对应的上层应用。
本发明实施例提供的硬件设备的访问管理方法及系统，通过在Linux系统环境或Android系统环境下建立能够以root权限启动的服务端，并实现对所连接的硬件设备进行连接和访问管理，使得所述上层应用可在非root权限的情况下，通过所述服务端安全的与所述硬件设备建立连接。此外，由于所述服务端可为每个上层应用配置一个服务线程，使得多个上层应用能够共享一个硬件设备。
附图说明
为了更清楚地说明本发明的技术方案，下面将对实施方式中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付 出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的硬件设备的访问管理系统与上层应用和硬件设备的交互示意图。
图2是本发明实施例提供的硬件设备的访问管理系统的工作示意图。
图3是本发明实施例提供的协议数据包的数据结构图。
图4是本发明实施例提供的硬件设备的访问管理方法的流程示意图。
图5是本发明实施例提供的服务端的具体执行步骤示意图。
图6是本发明实施例提供的服务端的服务线程的具体执行步骤示意图。
图7是本发明实施例提供的硬件设备的访问管理方法的流程示意图。
图8是本发明实施例提供的硬件设备的访问管理方法的流程示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
请参阅图1及图2，本发明实施例提供一种硬件设备访问管理系统100，用于在Linux系统环境或Android系统环境下，对硬件设备的访问及连接进行授权管理。其中，所述硬件设备访问管理系统100包括客户端10及服务端20。
所述服务端20，用于在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程，以监听来自客户端10的连接请求；其中，所述服务端以root权限启动。
在本发明实施例中，所述服务端20在启动后将主动读取通信配置，当检测到有外部的硬件设备通过接口(所述接口可为串口或USB接口，如图1中的串口301、串口302、USB303、USB304等)接入到终端(特别地，安装有Linux系统或Android系统的终端)上时，所述服务端20可与所述硬件设备建立连接，将成功与所述硬件设备建立连接的连接数据保存到连接池中，并创建一个监听线程，以监听来自所述客户端10的连接请求。
在本发明实施例中，所述服务端20以root权限启动，具体地，在Linux系统环境下，所述服务端20可由Linux系统通过inetd守护进程以root权限进行启动；而在Android系统环境下，所述服务端20以root权限在Android系统启动的时自动启动，其中，所述服务端20可通过在Android系统的NDK层建立一个基于TCP/IP通信的客户端的应用库，然后在Android的底层建立基于TCP/IP的一个通信服务来生成。
所述客户端10，用于向所述服务端20发起连接请求。
在本发明实施例中，上层应用200通过调用相应的驱动(如图1所示的驱动201，当然也可为是驱动202，驱动203...，为便于描述，以下均定义为驱动201)以间接调用所述客户端10的通信接口，此时触发所述客户端10向所述服务端20发起连接请求。其中，所述客户端10可通过TCP/IP发起与服务端20的监听线程的连接请求。
所述服务端20，用于在所述监听线程监听到来自所述客户端10的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程。
在本发明实施例中，所述服务端20的监听线程在接收到每次连接请求时，都会进行握手校验，校验成功后，所述监听线程会建立一个通信服务，所述通信服务此时主动创建用于服务当前连接请求的服务线程，并将所述连接请求中的连接描述字交予所述服务线程进行管理，所述服务线程建立后，所述客户端10就能与所述服务端20的数据通道进行数据的交互。
所述客户端10，用于在接收到上层应用200通过调用对应的驱动201访问自身的通信接口后，对根据访问产生的接口数据进行序列化处理，并将序列化处理生成的二进制数据流打包成协议数据包发送给所述服务端20的服务线程。
具体地，所述客户端10等待所述上层应用200调用自身的相应的通信接口，也就是等待上层应用200主动调用驱动201，从而发出调用所述客户端10的通信接口，在调用通信接口时，将产生对应的接口数据，所述客户端10对所述接口数据进行序列化处理，也就是将所述接口数据处理成二进制数据流，并将所述二进制数据流打包成协议数据包后发给服务端20的服务线程。
请一并参阅图3，图3是所述协议数据包的数据结构示意图。所述协议数据包包括以下字段：
同步头字段(GRGB)D11，用于准确定位数据包头位置；
校验码字段(CRC)D12，用于对每次包头数据的正确性校对，以提高数据包的准确性，用于生成校验码的数据为CMD字段、ID字段、ERROR字段和LEN字段；
命令字段(CMD)D13，用于描述当前数据包的命令描述，例如初始化命令，初始化应答、调用函数命令，调用函数应答和关闭连接等；
会话字段(ID)D14，用于描述当前命令CMD的会话ID，也就是保证每次数据交互的上下文的完整性；
错误码字段(ERROR)D15，用于描述调用过程中的错误信息序号，如果是调用成功时，此处置为0，否则设置为一个非0的数值；
数据长度字段(LEN)D16，用于描述DATA字段实际的数据长度，如果没有DATA字段时会设置为0，否则设置为实际的数据长度；
数据体字段(DATA)D17，交互过程中的实际数据(二进制的数据段)，长度由LEN指定。
所述服务端20，用于在所述服务线程根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端10。
在本发明实施例中，所述服务线程启动时进行必要的初始化操作，然后等待接收客户端10的协议数据包，在接收到所述协议数据包后，所述服务线程对所述协议数据包进行解析，对解析得到的协议数据进行反序列化操作，并创建相应的参数表。此后，所述服务线程读取所述协议数据中的命令ID(包含于CMD字段D13中)，并调用与所述命令ID对应的函数，然后将所述函数的输出参数数据进行序列化处理后，发送给所述客户端10。
所述客户端10，用于对所述函数的输出参数进行反序列化后写入函数参数表后，并通过驱动201 返回给对应的上层应用200。
在本发明实施例中，所述客户端10对所述函数的输出参数进行反序列化，将反序列化后的输出参数写入函数参数表后，通过驱动201返回给对应的上层应用200，如此，所述上层应用200即可在非root权限的情况下，安全的与所述硬件设备建立连接，并实现对所述硬件设备的访问。
综上所述，本发明实施例提供的硬件设备的访问管理系统100，在Linux系统环境下，建立能够以root权限启动的服务端20，并实现对所连接的硬件设备进行连接和访问管理，使得所述上层应用200可在非root权限的情况下，通过所述硬件设备的访问管理系统100安全的与所述硬件设备建立连接。此外，由于所述服务端20可为每个上层应用200配置一个服务线程，使得多个上层应用能够共享一个硬件设备。
请一并参阅图4，图4是本发明实施例提供的硬件设备的访问管理方法，所述硬件设备的访问管理方法是从服务端一侧进行描述的，其包括如下步骤：
S101，服务端在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程，以监听来自客户端的连接请求；其中，所述服务端以root权限启动。
S102，所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程。
S103，所述服务端的服务线程接收来自所述客户端发送的协议数据包，根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端，以使所述客户端对所述函数的输出参数进行反序列化后写入函数参数表后，并通过驱动返回给对应的上层应用。
其中，所述协议数据包由所述客户端在接收到所述上层应用通过调用所述驱动访问自身的通信接口后，对根据访问产生的接口数据进行序列化处理，并对序列化处理生成的二进制数据流进行打包生成。
本发明实施例提供的硬件设备的访问管理方法，在Linux系统环境下，建立能够以root权限启动的服务端，并实现对所连接的硬件设备进行连接和访问管理，使得所述上层应用可在非root权限的情况下，通过所述服务端安全的与所述硬件设备建立连接。此外，由于所述服务端可为每个上层应用配置一个服务线程，使得多个上层应用能够共享一个硬件设备。
下面将分别对所述服务端和服务端的服务线程的具体执行步骤做进一步的描述。
请一并参阅图5，图5是所述服务端的具体执行步骤示意图，包括：
S201：服务端启动时主动读取通信配置，并与硬件设备建立连接。
S202：服务端将成功与硬件设备建立连接的连接数据保存到连接池，并创建监听线程。
S203：服务端监听客户端的连接请求。
S204：服务端判断是否有合法的连接请求，如果有合法的连接时继续执行S205，否则跳转到S203。
S205：服务端通过所述连接请求中的数据包头的信息定位数据包读取握手数据包。
S206：服务端检查所述握手数据包是否合法，如果所述握手数据包合法则执行S208，否则执行S207。
S207：断开与所述客户端的连接请求，释放连接时所创建的资源，跳转到S203。
S208：创建服务于所述连接请求的服务线程以及所需要的资源，并分配连接使用权给客户端，跳转到S203继续等待下一个连接请求。
请一并参阅图6，图6是所述服务端的服务线程的具体执行步骤示意图，包括：
S301：服务线程启动时进行必要的初始化操作；
S302：等待接收所述客户端的协议数据包；
S303：判断是否接收到协议数据包，如果执行S304，否则跳转到S302继续等待接收协议数据包；
S304：解析所接收的协议数据包，如果解析成功执行S305，否则跳转到S302继续等待接收数据；
S305：对解析所述协议数据包得到的协议数据进行反序列化操作，并创建相应的参数表；
S306：识别所述协议数据中的命令ID，如果命令ID能够识别则执行S308，否则执行S307；
S307：返回命令错误的通信协议包文给客户端，然后跳转到S302继续等待接收协议数据包；
S308：调用命令ID所对应的函数，然后将函数的输出参数进行序列化处理；
S309：将序列化后的输出参数回复给客户端。
请一并参阅图7，图7是本发明实施例提供的硬件设备的访问管理方法的流程示意图，其是从客户端一侧进行描述的，其包括如下步骤：
S401：客户端通过通信接口以TCP/IP的方式连接服务端。
S402：客户端判断连接状态，如果已经建立合法的连接执行S403，否则跳转到S410。
S403：客户端在成功连接后主动发送握手数据包给服务端。
S404：客户端验证握手是否成功，如果验证成功继续执行S405，否则跳转到S410；
S405：客户端等待上层应用调用相应的通信接口，即等待上层应用主动调用驱动，从而对其通信接口进行访问；
S406：客户端对访问产生的接口数据进行序列化处理，也就是将接口数据处理成二进制数据流；
S407：客户端将序列化后的二进制数据流打包成协议数据包发给服务端的服务线程；
S408：客户端等待服务端的服务线程的应答，或者等待应答超时；
S409：客户端对服务端返回的序列化后的输出参数进行反序列化，并回填到函数参数表后，返回给上层应用，跳转到S405；
S410：客户端关闭与服务端的连接。
请一并参阅图8，图8是本发明实施例提供的硬件设备的访问管理方法的流程示意图，其是从客 户端与服务端两侧交互进行描述的，其包括如下步骤：
S501：服务端在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程，以监听来自客户端的连接请求；其中，所述服务端以root权限启动。
S502：所述客户端向所述服务端发起连接请求。
S503：所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程。
S504：所述客户端协议数据包发送给所述服务端的服务线程。
其中，所述协议数据包由所述客户端在接收到上层应用通过调用对应的驱动访问自身的通信接口后，对根据访问产生的接口数据进行序列化处理，并将序列化处理生成的二进制数据流打包生成。
S505：所述服务端的服务线程根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端。
S506：所述客户端对所述函数的输出参数进行反序列化，将反序列化后的输出参数写入函数参数表后，通过驱动返回给对应的上层应用。
本发明实施例提供的硬件设备的访问管理方法，在Linux系统环境下，建立能够以root权限启动的服务端，并实现对所连接的硬件设备进行连接和访问管理，使得所述上层应用可在非root权限的情况下，通过所述服务端安全的与所述硬件设备建立连接。此外，由于所述服务端可为每个上层应用配置一个服务线程，使得多个上层应用能够共享一个硬件设备。
以上所揭露的仅为本发明一种较佳实施例而已，当然不能以此来限定本发明之权利范围，本领域普通技术人员可以理解实现上述实施例的全部或部分流程，并依本发明权利要求所作的等同变化，仍属于发明所涵盖的范围。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

Claims (10)

  1. 一种硬件设备的访问管理方法，其特征在于，包括如下步骤：
    服务端在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程，以监听来自客户端的连接请求；其中，所述服务端以root权限启动；
    所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程；
    所述服务端的服务线程接收来自所述客户端发送的协议数据包，根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端，以使所述客户端对所述函数的输出参数进行反序列化后写入函数参数表，并通过驱动返回给对应的上层应用。
  2. 根据权利要求1所述的硬件设备的访问管理方法，其特征在于，
    所述协议数据包由所述客户端在接收到所述上层应用通过调用所述驱动访问自身的通信接口后，对根据访问产生的接口数据进行序列化处理，并对序列化处理生成的二进制数据流进行打包生成。
  3. 根据权利要求1所述的硬件设备的访问管理方法，其特征在于，
    在Linux系统环境下，所述服务端由Linux系统通过inetd守护进程以root权限启动；
    在Android系统环境下，所述服务端以root权限在Android系统启动的时自动启动，其中，通过在Android系统的NDK层建立一个基于TCP/IP通信的客户端的应用库，然后在Android的底层建立基于TCP/IP的一个通信服务来生成所述服务端。
  4. 根据权利要求1所述的硬件设备的访问管理方法，其特征在于，所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程，具体包括：
    监听来自客户端的连接请求；
    判断是否有合法的连接请求，若有，则获取所述连接请求中的数据包头的信息定位数据包，读取握手数据包；
    检查所述握手数据包是否合法，若合法，则创建服务于所述连接请求的服务线程，并分配连接使用权给所述客户端；若不合法，则拒绝所述客户端的连接请求。
  5. 根据权利要求1所述的硬件设备的访问管理方法，其特征在于，所述服务端的服务线程接收来自所述客户端发送的协议数据包，根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端，具体包括：
    接收所述客户端发送的协议数据包；
    对接收的所述协议数据包进行解析，将解析得到的协议数据进行反序列化，并创建相应的函数参数表；
    识别所述协议数据中的命令ID，调用所述命令ID所对应的函数建立与所述接口的连接，并对所述函数的输出参数进行序列化处理；
    将序列化后的输出参数发送给所述客户端。
  6. 一种硬件设备的访问管理方法，其特征在于，包括如下步骤：
    服务端在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程，以监听来自客户端的连接请求；其中，所述服务端以root权限启动；
    所述客户端向所述服务端发起连接请求；
    所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程；
    所述客户端将协议数据包发送给所述服务端的服务线程；
    所述服务端的服务线程根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端；
    所述客户端对所述函数的输出参数进行反序列化后写入函数参数表后，并通过驱动返回给对应的上层应用。
  7. 根据权利要求6所述的硬件设备的访问管理方法，其特征在于，在所述客户端将协议数据包发送给所述服务端的服务线程之前，还包括：
    所述客户端在接收到所述上层应用通过调用所述驱动访问自身的通信接口后，对根据访问产生的接口数据进行序列化处理，并对序列化处理生成的二进制数据流进行打包生成协议数据包。
  8. 根据权利要求根据权利要求6所述的硬件设备的访问管理方法，其特征在于，所述服务端的监听线程在监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程，具体包括：
    监听来自客户端的连接请求；
    判断是否有合法的连接请求，若有，则获取所述连接请求中的数据包头的信息定位数据包，读取握手数据包；
    检查所述握手数据包是否合法，若合法，则创建服务于所述连接请求的服务线程，并分配连接使用权给所述客户端；若不合法，则拒绝所述客户端的连接请求。
  9. 根据权利要求根据权利要求6所述的硬件设备的访问管理方法，其特征在于，所述服务端的 服务线程根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端，具体包括：
    解析所述协议数据包，将解析得到的协议数据进行反序列化，并创建相应的函数参数表；
    识别所述协议数据中的命令ID，调用所述命令ID所对应的函数建立与所述接口的连接，并对所述函数的输出参数进行序列化处理；
    将序列化后的输出参数发送给所述客户端。
  10. 一种硬件设备的访问管理系统，其特征在于，包括客户端及服务端，其中：
    所述服务端，用于在检测到硬件设备接入预定的接口时，建立与所述硬件设备的连接，并创建监听线程，以监听来自客户端的连接请求；其中，所述服务端以root权限启动；
    所述客户端，用于向所述服务端发起连接请求；
    所述服务端，用于在所述监听线程监听到来自所述客户端的连接请求，且对所述连接请求经过校验后，创建服务于所述连接请求的服务线程；
    所述客户端，用于在接收到上层应用通过调用对应的驱动访问自身的通信接口后，对根据访问产生的接口数据进行序列化处理，并将序列化处理生成的二进制数据流打包成协议数据包发送给所述服务端的服务线程；
    所述服务端，用于在所述服务线程根据所述协议数据包调用相应的函数建立与所述接口的连接，并将所述函数的输出参数进行序列化处理后返回给所述客户端；
    所述客户端，用于对所述函数的输出参数进行反序列化后写入函数参数表后，并通过驱动返回给对应的上层应用。
PCT/CN2017/079355 2016-04-28 2017-04-01 一种硬件设备的访问管理方法及系统 WO2017185952A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610280293.2 2016-04-28
CN201610280293.2A CN106027487B (zh) 2016-04-28 2016-04-28 一种硬件设备的访问管理方法及系统

Publications (1)

Publication Number Publication Date
WO2017185952A1 true WO2017185952A1 (zh) 2017-11-02

Family

ID=57081269

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/079355 WO2017185952A1 (zh) 2016-04-28 2017-04-01 一种硬件设备的访问管理方法及系统

Country Status (2)

Country Link
CN (1) CN106027487B (zh)
WO (1) WO2017185952A1 (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110166313A (zh) * 2019-03-21 2019-08-23 北京华顺信安科技有限公司 一种模拟协议服务端的方法和系统
CN110633163A (zh) * 2019-09-26 2019-12-31 深圳市七星石科技有限公司 一种基于多进程服务器的预防应用程序崩溃的开发方法
CN111562535A (zh) * 2020-04-07 2020-08-21 国网上海市电力公司 一种用于提高电能表检定速度的协调方法及系统
CN112199666A (zh) * 2020-09-30 2021-01-08 江苏恒宝智能系统技术有限公司 设备通信方法、装置、系统和电子设备
CN113489639A (zh) * 2021-06-16 2021-10-08 杭州深渡科技有限公司 一种网关多接口的数据通信方法和系统
CN114201114A (zh) * 2021-12-14 2022-03-18 上海朝阳永续信息技术股份有限公司 一种基于文件的跨互联网数据传输系统
CN115344887A (zh) * 2022-08-05 2022-11-15 广州民航信息技术有限公司 Web前端的跨平台适配系统、方法、装置、电子设备及计算机可读存储介质
CN115373767A (zh) * 2022-10-24 2022-11-22 北京智芯微电子科技有限公司 程序执行方法、装置、电子设备和可读存储介质

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106027487B (zh) * 2016-04-28 2019-07-23 广州广电运通金融电子股份有限公司 一种硬件设备的访问管理方法及系统
CN106897146A (zh) * 2017-02-09 2017-06-27 青岛海信移动通信技术股份有限公司 一种终端的麦克风的数据处理方法和具有麦克风的终端
CN108664799B (zh) * 2017-03-31 2023-03-14 腾讯科技（深圳）有限公司 设备管理应用的权限设置方法及装置
CN109408418B (zh) * 2017-08-17 2022-03-25 深圳市中兴微电子技术有限公司 一种usb模式切换装置及方法、usb设备
CN107945354A (zh) * 2017-11-20 2018-04-20 浪潮金融信息技术有限公司 排队叫号方法及系统、计算机存储介质和终端
CN108494731B (zh) * 2018-02-08 2021-04-02 中国电子科技网络信息安全有限公司 一种基于双向身份认证的抗网络扫描方法
CN110311936B (zh) * 2018-03-27 2022-01-07 卓米私人有限公司 客户端之间的通讯方法、装置、电子设备及存储介质
CN109144579B (zh) * 2018-07-17 2023-09-29 广州睿本信息科技有限公司 一种Web系统读取硬件的方法及计算机可读存储介质
CN109634878A (zh) * 2018-12-07 2019-04-16 用友网络科技股份有限公司 监控方法、监控装置、服务器、终端和可读存储介质
CN109787997B (zh) * 2019-02-26 2021-06-11 上海易点时空网络有限公司 基于php的tcp服务方法及服务器
CN110266477B (zh) * 2019-05-23 2023-03-24 广州河东科技有限公司 一种udp通信实现动态加密方法
CN110730168B (zh) * 2019-09-29 2022-06-14 佛山市兴颂机器人科技有限公司 一种通信控制方法、装置及服务端设备
CN111143085B (zh) * 2019-11-28 2022-08-09 浪潮金融信息技术有限公司 一种实现多应用并发调用硬件的方法
CN112035115B (zh) * 2020-06-17 2022-09-13 厦门盈趣科技股份有限公司 一种基于Android系统平台调用的系统API设置及调用方法及系统
CN112000949B (zh) * 2020-08-26 2023-06-16 中国联合网络通信集团有限公司 程序包调用方法、系统、终端设备及计算机可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1744591A (zh) * 2004-08-31 2006-03-08 中国科学院计算技术研究所 一种终端网络环境中的分布式设备重定向系统及其方法
CN103034811A (zh) * 2011-09-29 2013-04-10 北大方正集团有限公司 一种文件处理的方法、系统及装置
CN103885763A (zh) * 2012-12-21 2014-06-25 腾讯科技（深圳）有限公司 操作系统资源访问方法和系统
CN104714760A (zh) * 2015-03-05 2015-06-17 青岛海信宽带多媒体技术有限公司 一种读写存储设备的方法及装置
CN106027487A (zh) * 2016-04-28 2016-10-12 广州广电运通金融电子股份有限公司 一种硬件设备的访问管理方法及系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101163055A (zh) * 2007-11-21 2008-04-16 浪潮电子信息产业股份有限公司 一种自动探测服务器硬件信息的方法
US9378038B2 (en) * 2013-06-07 2016-06-28 American Megatrends, Inc. Methods, devices and computer readable storage devices for emulating a gyroscope in a guest operating system from a host operating system
CN104866778A (zh) * 2015-01-30 2015-08-26 武汉华工安鼎信息技术有限责任公司 一种基于Linux内核的文档安全访问控制方法和装置
CN105159696A (zh) * 2015-07-09 2015-12-16 北京君正集成电路股份有限公司 一种独立于Linux内核的硬件驱动实现方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1744591A (zh) * 2004-08-31 2006-03-08 中国科学院计算技术研究所 一种终端网络环境中的分布式设备重定向系统及其方法
CN103034811A (zh) * 2011-09-29 2013-04-10 北大方正集团有限公司 一种文件处理的方法、系统及装置
CN103885763A (zh) * 2012-12-21 2014-06-25 腾讯科技（深圳）有限公司 操作系统资源访问方法和系统
CN104714760A (zh) * 2015-03-05 2015-06-17 青岛海信宽带多媒体技术有限公司 一种读写存储设备的方法及装置
CN106027487A (zh) * 2016-04-28 2016-10-12 广州广电运通金融电子股份有限公司 一种硬件设备的访问管理方法及系统

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110166313B (zh) * 2019-03-21 2022-03-18 北京华顺信安科技有限公司 一种模拟协议服务端的方法
CN110166313A (zh) * 2019-03-21 2019-08-23 北京华顺信安科技有限公司 一种模拟协议服务端的方法和系统
CN110633163A (zh) * 2019-09-26 2019-12-31 深圳市七星石科技有限公司 一种基于多进程服务器的预防应用程序崩溃的开发方法
CN110633163B (zh) * 2019-09-26 2022-12-09 深圳市七星石科技有限公司 一种基于多进程服务器的预防应用程序崩溃的开发方法
CN111562535A (zh) * 2020-04-07 2020-08-21 国网上海市电力公司 一种用于提高电能表检定速度的协调方法及系统
CN112199666A (zh) * 2020-09-30 2021-01-08 江苏恒宝智能系统技术有限公司 设备通信方法、装置、系统和电子设备
CN113489639B (zh) * 2021-06-16 2022-12-02 杭州深渡科技有限公司 一种网关多接口的数据通信方法和系统
CN113489639A (zh) * 2021-06-16 2021-10-08 杭州深渡科技有限公司 一种网关多接口的数据通信方法和系统
CN114201114A (zh) * 2021-12-14 2022-03-18 上海朝阳永续信息技术股份有限公司 一种基于文件的跨互联网数据传输系统
CN114201114B (zh) * 2021-12-14 2024-05-10 上海朝阳永续信息技术股份有限公司 一种基于文件的跨互联网数据传输系统
CN115344887A (zh) * 2022-08-05 2022-11-15 广州民航信息技术有限公司 Web前端的跨平台适配系统、方法、装置、电子设备及计算机可读存储介质
CN115373767A (zh) * 2022-10-24 2022-11-22 北京智芯微电子科技有限公司 程序执行方法、装置、电子设备和可读存储介质
CN115373767B (zh) * 2022-10-24 2023-01-20 北京智芯微电子科技有限公司 程序执行方法、装置、电子设备和可读存储介质

Also Published As

Publication number Publication date
CN106027487A (zh) 2016-10-12
CN106027487B (zh) 2019-07-23

Similar Documents

Publication Publication Date Title
WO2017185952A1 (zh) 一种硬件设备的访问管理方法及系统
US7603484B2 (en) Protocol for communication with a user-mode device driver
WO2017143928A1 (zh) 数据传输方法、虚拟机和宿主机
US10404538B1 (en) Remote platform configuration
US10579442B2 (en) Inversion-of-control component service models for virtual environments
CN109491725B (zh) 应用程序可交互多开方法和系统、存储介质、电子设备
US10904238B2 (en) Access token management for state preservation and reuse
CN111818035A (zh) 一种基于api网关的权限验证的方法及设备
CN110896489B (zh) 一种鉴权方法、装置、设备及存储介质
CN115639954A (zh) 一种数据传输方法、装置、设备及介质
US20210132975A1 (en) Automated host attestation for secure run-time environments
US7996524B2 (en) Controlling external communication of embedded device using proxy server
CN115934378A (zh) 业务数据处理方法、装置、电子设备和存储介质
EP2987093B1 (en) Website server request rerouting
WO2023092316A1 (zh) 一种第三方服务登录方法、装置、终端设备及存储介质
US10110683B2 (en) Systems and methods for maintaining ownership of and avoiding orphaning of communication sessions
US20170048219A1 (en) Systems and methods for modifying access credentials using impersonation in computer systems
US10862757B2 (en) Isolating a redirected biometric device to a remote session
WO2020078406A1 (zh) 一种用于为移动设备分配流量资源的方法与设备
US9454413B1 (en) Systems and methods for handling communications between network applications
CN110839070B (zh) 多系统管理装置及方法、远程系统、主系统
CN116361771B (zh) 设备的访问与管理方法、装置、电子设备及存储介质
WO2024001642A1 (zh) Usb设备的管控方法、云端设备、终端设备及存储介质
CN108810087B (zh) 一种存储服务器的连接方法、系统及设备
CN111447120B (zh) 基于Tuxedo的压力测试方法及系统

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17788605

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17788605

Country of ref document: EP

Kind code of ref document: A1