Remote procedure calling method and device, equipment, chip and storage medium

Abstract

The invention provides a remote procedure calling method and device, equipment, a chip and a storage medium. The method comprises the following steps: converting calling information defined by a proto file into a remote procedure call (RPC) code of a C language structure; converting the RPC code of the C language structure into a plurality of first tasks of six sub-message protocols based on gRPC, wherein the plurality of first tasks are message sending and / or message reading tasks; adding the plurality of first tasks into a task queue, and scheduling the plurality of first tasks; performing text serialization on the plurality of first tasks according to a queue sequence of the plurality of first tasks, and converting the plurality of first tasks into first communication data in a binary format; packaging the first communication data into a first communication message defined by a first communication protocol; sending the first communication message to a server device, so that the server device executes a remote procedure call (RPC) service in response to the call information to determine an execution result; and receiving an execution result sent by the server-side equipment.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and more specifically, to a remote procedure call method and apparatus, device, chip and storage medium. Background Art

[0002] RTOS is small in size and simple in functions, and is often used in fields such as wearable devices and IoT devices. However, due to factors such as the small size of the software and hardware of such devices, insufficient computing power, and a narrow scope of application, most of the existing remote procedure call methods cannot be adapted to them.

[0003] In the related art, in order to realize the remote call of RTOS devices, most of them use self-built protocols, such as self-built RPC protocols based on protobuf serialization protocol to support RPC calls of RTOS devices; however, this self-built protocol method has a closed ecosystem and poor versatility. It can only run on devices that support the protocol and is not compatible with third-party devices. In addition, in the self-built protocol method, the structures of the initiator and the receiver of the RPC call are exactly the same, and it is impossible to split the various functions. There is also a problem of poor scalability. Summary of the invention

[0004] The present application provides a remote procedure call method and apparatus, device, chip and storage medium. The following introduces various aspects involved in the embodiments of the present application.

[0005] In a first aspect, a remote procedure call method is provided, which is applied to a client device, wherein the client device is a device based on a real-time operating system RTOS, and the client device calls a server device according to the remote procedure call method, and the server device is a device that supports Google's remote procedure call gRPC framework. The method includes: converting the call information defined in a proto file into a remote procedure call RPC code of a C language structure, wherein the call information defined in the proto file includes a message defined in a message field and a method of an RPC service defined in a service field; converting the RPC code of the C language structure into a plurality of first tasks based on six sub-message protocols of gRPC, wherein the plurality of first tasks are message sending and / or message reading tasks; adding the plurality of first tasks to a task queue and scheduling the plurality of first tasks; performing text serialization on the plurality of first tasks according to the queue order of the plurality of first tasks, and converting the plurality of first tasks into first communication data in a binary format; encapsulating the first communication data into a first communication message defined in a first communication protocol; sending the first communication message to a server device, so that the server device executes the remote procedure call RPC service in response to the call information to determine an execution result; and receiving the execution result sent by the server device.

[0006] Optionally, the execution result is encapsulated in a second communication message, and the second communication message is a message defined according to the first communication protocol. The method also includes: performing protocol disassembly and text deserialization on the second communication message to obtain second communication data in binary format; converting the second communication data into multiple second tasks; adding the multiple second tasks to the task queue and scheduling the multiple second tasks; parsing the multiple second tasks according to the queue order of the multiple second tasks to determine the execution result of the remote procedure call.

[0007] Optionally, the converting of the calling information defined in the proto file into a remote procedure call RPC code with a C language structure includes: based on the nanopb tool, converting the message defined in the message field into a message with a C language structure, and, according to the method of the remote procedure call RPC service defined in the service field, generating a client calling interface and a service registration interface with a C language structure.

[0008] Optionally, performing text serialization on the multiple first tasks to convert the multiple first tasks into first communication data in binary format includes: using nanopb tool to convert the multiple first tasks into binary communication data in standard protobuf format to obtain the first communication data.

[0009] Optionally, the first communication protocol includes one of an http2 protocol, a domain socket protocol or a pipe communication protocol.

[0010] In a second aspect, a remote procedure call method is provided, which is applied to a server device, wherein the server device is called by a client device according to the remote procedure call method, the client device is a device based on a real-time operating system RTOS, and the server device is a device that supports Google's remote procedure call gRPC framework, and the method includes: receiving a first communication message sent by the client device, wherein the first communication message is a communication message defined according to a first communication protocol between the server device and the client device; performing protocol disassembly and deserialization on the first communication message to obtain third communication data in binary format; converting the third communication data into multiple third tasks, wherein the multiple third tasks include message sending and / or message reading tasks; adding the multiple third tasks to a task queue, scheduling the multiple third tasks, and determining the queue order of the multiple tasks; executing the multiple third tasks according to the queue order of the multiple third tasks, and determining the execution results of the multiple third tasks; and sending the execution results of the multiple third tasks to the client device.

[0011] Optionally, the execution results of the multiple third tasks are encapsulated in a second communication message, and the method also includes: converting the execution results of the multiple third tasks into multiple second tasks based on the six sub-message protocol of gRPC; adding the multiple second tasks to the task queue, and scheduling the multiple second tasks; performing text serialization on the multiple second tasks according to the queue order of the multiple second tasks, and converting the multiple second tasks into second communication data in binary format; encapsulating the second communication data into a second communication message defined by the first communication protocol; and sending the second communication message to the client device, so that the client device determines the execution result based on the second communication message.

[0012] Optionally, executing the multiple third tasks according to the queue order of the multiple third tasks and determining the execution results of the multiple third tasks include: dispatching the multiple third tasks to a thread pool according to the queue order of the multiple third tasks to execute the multiple third tasks.

[0013] Optionally, the first communication protocol includes one of an http2 protocol, a domain socket protocol or a pipe communication protocol.

[0014] In a third aspect, a remote procedure call device is provided, which is applied to a client device, wherein the client device is a device based on a real-time operating system RTOS, and the client device uses the remote procedure call device to call a server device, and the server device is a device that supports gRPC calls. The device includes: a stub code generation module, which is used to convert the call information defined in the proto file into a remote procedure call RPC code with a C language structure, and the call information defined in the proto file includes a message defined in a message field and an RPC service method defined in a service field; a first interface module, which is used to convert the RPC code with the C language structure into a plurality of first tasks based on six sub-message protocols of gRPC, The multiple first tasks are message sending and / or message reading tasks; a first processing module is used to add the multiple first tasks to a task queue and schedule the multiple first tasks; a first message protocol module is used to perform text serialization on the multiple first tasks according to the queue order of the multiple first tasks, and convert the multiple first tasks into first communication data in binary format; and, encapsulate the first communication data into a first communication message defined by a first communication protocol; a first communication module is used to send the first communication message to a server device, so that the server device executes the remote procedure call RPC service in response to the call information to determine the execution result; and, receive the execution result sent by the server device.

[0015] Optionally, the execution result is encapsulated in a second communication message, which is a message defined according to the first communication protocol; the first message protocol module is also used to: perform protocol disassembly and text deserialization on the second communication message to obtain second communication data in binary format; the first processing module is also used to: convert the second communication data into multiple second tasks; add the multiple second tasks to the task queue and schedule the multiple second tasks; parse the multiple second tasks according to the queue order of the multiple second tasks to determine the execution result of the remote procedure call.

[0016] Optionally, the stub code generation module is also used to: based on the nanopb tool, convert the message defined by the message field into a message of C language structure, and generate a client call interface and a service registration interface of C language structure according to the remote procedure call RPC service method defined by the service field.

[0017] Optionally, the first message protocol module is further used to: use the nanopb tool to convert the multiple first tasks into binary communication data in a standard protobuf format to obtain the first communication data.

[0018] Optionally, the first communication protocol includes one of an http2 protocol, a domain socket protocol or a pipe communication protocol.

[0019] In a fourth aspect, a remote procedure call device is provided, which is applied to a server device, and the server device is called by a client device through the remote procedure call device. The client device is a device based on a real-time operating system RTOS, and the server device is a device that supports Google's remote procedure call gRPC framework. The device includes: a second communication module, which is used to receive a first communication message sent by the client device, and the first communication message is a communication message defined according to a first communication protocol between the server device and the client device; a second message protocol module, which is used to perform protocol disassembly and deserialization on the first communication message to obtain third communication data in binary format; a second interface module, which is used to convert the third communication data into multiple third tasks, and the multiple third tasks include message sending and / or message reading tasks; a second processing module, which is used to add the multiple third tasks to a task queue, schedule the multiple third tasks, and determine the queue order of the multiple tasks; and, according to the queue order of the multiple third tasks, execute the multiple third tasks and determine the execution results of the multiple third tasks; the second communication module is also used to: send the execution results of the multiple third tasks to the client device.

[0020] Optionally, the execution results of the multiple third tasks are encapsulated in a second communication message: the second interface module is also used to convert the execution results of the multiple third tasks into multiple second tasks based on the six sub-message protocols of gRPC; the second processing module is also used to add the multiple second tasks to the task queue and schedule the multiple second tasks; the second message protocol module is also used to perform text serialization on the multiple second tasks according to the queue order of the multiple second tasks, and convert the multiple second tasks into second communication data in binary format; and, encapsulate the second communication data into the second communication message defined by the first communication protocol; the second communication module is also used to send the second communication message to the client device, so that the client device determines the execution result based on the second communication message.

[0021] Optionally, the second processing module is further used to: dispatch the multiple third tasks to a thread pool according to a queue order of the multiple third tasks, so as to execute the multiple third tasks.

[0022] Optionally, the first communication protocol includes one of an http2 protocol, a domain socket protocol or a pipe communication protocol.

[0023] In a fifth aspect, a client device is provided, comprising a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and execute the computer program from the memory to implement the method described in the first aspect.

[0024] In a sixth aspect, a server device is provided, comprising a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and execute the computer program from the memory to implement the method as described in the second aspect.

[0025] In a seventh aspect, a chip is provided, comprising: a processor, configured to call and run a computer program from a memory, so that a device equipped with the chip executes the method described in the first aspect or the second aspect.

[0026] In an eighth aspect, a computer-readable storage medium is provided, wherein the storage medium is used to store a computer program, and when the computer program is executed, the method described in the first aspect or the second aspect is implemented.

[0027] In the above-mentioned remote procedure call method provided in an embodiment of the present application, by converting the calling information defined in the proto file into a gRPC stubbing code in C language format, the stubbing code does not need to rely on an external library and can be applied to a device based on a real-time operating system RTOS, thereby realizing cross-end gRPC calls between RTOS devices and other platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 A scenario architecture diagram of an application scenario used by the remote procedure call method provided in an embodiment of the present application.

[0029] Figure 2 A schematic flowchart of a remote procedure call method provided in an embodiment of the present application.

[0030] Figure 3 A schematic flowchart of a remote procedure call method provided in another embodiment of the present application.

[0031] Figure 4 A schematic flowchart of a remote procedure call method provided for yet another embodiment of the present application.

[0032] Figure 5 This is a schematic diagram of a message queue in an embodiment of the present application.

[0033] Figure 6 A schematic structural diagram of a remote procedure call device provided in an embodiment of the present application.

[0034] Figure 7 A schematic structural diagram of a remote procedure call device provided in another embodiment of the present application.

[0035] Figure 8 A schematic structural diagram of the device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments.

[0037] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0038] The terms "first", "second", "third" and "fourth" etc. in the specification and claims of the present application and the drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices.

[0039] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0040] Figure 1 A scenario architecture diagram of an application scenario used by the remote procedure call method provided in the embodiment of the present application. Specifically, Figure 1 As shown, the application scenario may include a client device 110 and a server device 120, and the client device 110 may perform a remote procedure call on the server device 120; therefore, the above-mentioned client device may also be referred to as a caller, and the server device may be referred to as a called party.

[0041] The client device 110 and the server device 120 may be mobile phones, tablet computers, wearable devices, augmented reality (AR) / virtual reality (VR) devices, laptop computers, ultra-mobile personal computers (UMPC), netbooks, personal digital assistants (PDA), robotic arms, cameras, joysticks, monitors, sensors, logistics vehicles, smart shelves, etc. The embodiments of the present application do not impose any restrictions on their specific types.

[0042] For devices such as laptops, tablets or mobile phones, remote calls between operating systems such as Windows, Linux or Android are a mature technology, which can be achieved through the RPC protocol. The RPC framework is responsible for shielding the underlying transmission method (TCP or UDP), serialization method (XML / Json / binary) and communication details. The service caller can call the remote service provider just like calling the local interface, without having to worry about the underlying communication details and calling process. Commonly used RPC frameworks include: gRPC, Thrift, Dubbo and Spring Cloud.

[0043] Among them, gRPC is a high-performance, general-purpose open source RPC framework, which was developed by Google in 2015 mainly for mobile application development and based on the HTTP / 2 protocol standard. It is developed based on the ProtoBuf serialization protocol and supports many development languages. As it is an open source framework, both parties in communication can carry out secondary development, so the communication between the client and the server will focus more on the business level, reducing the focus on the underlying communication implemented by the gRPC framework.

[0044] As for wearable devices such as smart watches or IoT devices in smart homes, the hardware processing power of such devices is relatively low, and they usually run a relatively lightweight embedded real-time operating system (RTOS). In related technologies, when making remote calls to such devices, self-built protocols are widely used, such as self-built RPC protocols based on protobuf serialization protocols to support RPC calls of RTOS devices; however, this self-built protocol method has a closed ecosystem and poor versatility. It can only run on devices that support the protocol, but is not compatible with third-party devices. gRPC calls cannot be implemented in devices that are not configured with the protocol.

[0045] In addition, in the above self-built protocol solution, the structures of the initiator and receiver of the RPC call are exactly the same. For some devices with limited capabilities, they usually only need to respond to calls initiated by other devices, without the need to actively initiate calls; taking the device as a thermometer and hygrometer as an example, the device only needs to respond to the received remote call when the user initiates a query, and send the current temperature and humidity data to the server or user device without actively reporting. In the call framework of the related art, it is impossible to split the various functional modules, resulting in poor scalability.

[0046] Embodiments of the present application provide a remote procedure call method and apparatus, device, chip, and storage medium.

[0047] Let's first combine Figure 2 The remote procedure call method provided in the embodiment of the present application is introduced. The method is executed by a client device and a server device. The client device and the server device can be respectively Figure 1 The client device 110 and the server device 120 in the embodiment are as follows. The client device is a device based on a real-time operating system RTOS, and the server device is a device supporting the Google Remote Procedure Call (gRPC) framework.

[0048] Figure 2 It is described from the perspective of the interaction between the client device and the server device. Figure 2 The method includes steps S201-S211.

[0049] In step S201, the call information defined in the proto file is converted into an RPC code of a C language structure.

[0050] proto file is a file written in Protobuf language. Protobuf is a data description language used to describe a lightweight and efficient structured data storage format. It is suitable as a data storage or remote procedure call data exchange format. After serialization, the amount of data obtained is small, and then it is stored in a key-value manner. It has strong version compatibility with messages and can be used in communication protocols and other fields. It is a language-independent, platform-independent, and serialized structured data format.

[0051] In the gRPC calling framework, protobuf is used as the interface definition language. When making a call, stub code needs to be generated according to the message. The stub code is usually a code in a language structure such as Java, C++ or Python, and needs to rely on some gRPC libraries of the corresponding language. It occupies a large amount of resources and a large number of dependent libraries are not supported on embedded devices, and cannot be applied to the RTOS device involved in the embodiments of the present application.

[0052] In an embodiment of the present application, the call information can be converted into an RPC code in a C language structure without relying on an external library, so that it can run in an RTOS device.

[0053] The remote call information in the embodiment of the present application is defined by a proto file, which includes a message defined by a message field and a method of an RPC service defined by a service field. Therefore, the conversion of the above code also includes two parts: message conversion and method conversion.

[0054] The message conversion can be achieved by using the nanopb tool. nanopb is a standard protoc tool that supports the conversion of proto message formats and can convert the message defined by the message field in the above call information into a C language structure. An example is given below.

[0055] The proto message before conversion is:

[0056] message RequestFile{

[0057] string fileName=1;

[0058] bool end = 2;

[0059] bytes content = 3;

[0060] }

[0061] message RespFile{

[0062] int32 stat = 1;

[0063] }

[0064] The code of the C language structure converted by nanopb is:

[0065] typedef struct_RequestFile{

[0066] char*fileName;

[0067] bool end;

[0068] pb_bytes_array_t*content;

[0069] }RequFile;

[0070] typedef struct_RespFile{

[0071] int32_t stat;

[0072] }RespFile;

[0073] It should be noted that the nanopb tool described above only supports message conversion, and does not support the generation of gRPC services. Therefore, the method provided in this application modifies its implementation based on nanopb. For a given proto file, in addition to supporting the conversion of message types to C structures, it also supports the conversion of service and method definitions to C code. The generated stub code includes two parts: client method call and server method registration, which is the top-level interface visible when writing business code.

[0074] For example, the code of the RPC service method defined by the service field before conversion is:

[0075] service FileTrans{

[0076] rpc send(stream RequFile)returns(RespFile){}

[0077] }

[0078] The converted C language structure's client call interface and service registration interface are:

[0079] eg_proxy_t*FileTrans_send__client_call(eg_channel_t*channel,

[0080] eg_client_context_t*client_ctx,eg_client_cbs_t*cbs,void*tag,void*req);

[0081] eg_proxy_t*FileTrans_send__client_call_sync(eg_channel_t*channel,

[0082] eg_client_context_t*client_ctx,void**res);

[0083] int FileTrans_send__server_reg(eg_server_t*server,eg_server_cbs_t*cbs);

[0084] int FileTrans_send__server_reg_sync(eg_server_t*server,eg_server_funcfunc);

[0085] In step S202, the client device encapsulates the RPC code of the C language structure into multiple first tasks based on six sub-message protocols of gRPC, and the multiple first tasks include message sending and / or message reading tasks.

[0086] In order to achieve compatibility with gRPC, in the solution of this application, four types of call modes supported by gRPC are implemented in C language. According to the gRPC message protocol, from the perspective of any role in the client or server, an RPC request can be divided into 6 sub-messages, including: request header, request message body, request end, response header, response message body and response end.

[0087] The essence of the four different calling methods is the different combinations of these self-messages. For example, for the client, a unit call is strictly in the order of request header->request message body->request end->response header->response message body->response end; while the client's streaming call is in the order of request header->{request message body*n}->request end->response header->response message body->response end.

[0088] This solution encapsulates the sending and reading of sub-messages into specific read\write interfaces, converts messages of different request methods into tasks internally, and then manages the sending and response processing of each task. The business only needs to specify the calling mode when defining the proto file of the method, and then call the corresponding read\write interface to read and write messages.

[0089] int start_call(eg_proxy_t*proxy);

[0090] void stream_read(eg_proxy_t*proxy);

[0091] void stream_write(eg_proxy_t*proxy,void*req);

[0092] void stream_write_done(eg_proxy_t*proxy);

[0093] void stream_finish(eg_proxy_t*proxy);

[0094] For example, the above code is the client's RPC sending and receiving interface. start_call will send the message header structure, stream_write will send the message body structure, stream_write_done will send the message end structure, the response message header is processed internally, stream_read will read the response message body structure, and stream_finish will read the response message end. The above interface will not be called directly by the business, but will be implicitly called by the RPC code of the C language structure in the previous article.

[0095] In step S203 , the client device adds the multiple first tasks to a task queue to schedule the multiple first tasks.

[0096] In an embodiment of the present application, the scheduling of the above-mentioned multiple tasks can be implemented through a message queue. Among them, the message queue is a multi-producer single-consumer model, which is responsible for the final consumption of all tasks. The message processing process of the client's message sending and reading task is encapsulated as a unified task queue, and the queue processes tasks in sequence. The task scheduling method based on the task queue will be described in the following message.

[0097] In step S204 , the client device performs text serialization on the plurality of first tasks according to the queue order of the plurality of first tasks, so as to convert the plurality of first tasks into first communication data in binary format.

[0098] The client device and the server device are usually connected through a specific network protocol, and the data format transmitted between them needs to meet the provisions of the network protocol. Taking the http2 protocol as an example, the data format specified in the protocol is binary. Therefore, when transmitting the above message, it is necessary to convert its format. Specifically in the embodiment of the present application, when submitting the message to a network protocol such as http2, it is necessary to convert the message in the memory into a binary format, that is, to perform text serialization. In the embodiment of the present application, protobuf is used as the format for serialization and deserialization.

[0099] In some embodiments, the above binary format conversion can be implemented using the nanopb tool mentioned above, and the binary standard protobuf format after conversion can be interoperable with gRPC on other platforms.

[0100] In step S205 , the client device encapsulates the first communication data into a first communication message defined by the first communication protocol.

[0101] Before sending the first communication data in binary format to the server device, the binary data needs to be further encapsulated into a data format specified by the protocol of the first communication method according to the communication method between the client device and the server device.

[0102] For example, in the http2 protocol, it is necessary to encapsulate the message into the message header and message body, set the connection properties, multiplex multiple connections, etc. For the inter-process communication protocol, it needs to be constructed in the corresponding IDL form.

[0103] The embodiment of the present application does not specifically limit the first communication protocol between the client device and the server device. The first communication protocol may include one of the http2 protocol, the domain socket protocol or the pipe communication protocol.

[0104] In step S206, the client device sends the first communication message to the server device.

[0105] In step S207, the server device performs protocol decomposition and deserialization on the first communication message to obtain third communication data in binary format.

[0106] In step S208, the server device converts the third communication data into a plurality of third tasks, where the plurality of third tasks include message sending and / or message reading tasks.

[0107] In step S209, the server device adds the plurality of third tasks to the task queue to schedule the plurality of third tasks and determines the queue order of the plurality of tasks.

[0108] In step S210, the server device executes the plurality of third tasks according to the queue order of the plurality of third tasks and determines the execution result.

[0109] In some embodiments, a thread pool is configured on the server device, and when executing the plurality of third tasks, the plurality of tasks can be dispatched to the thread pool according to their requirements. For example, different numbers of threads can be configured for the tasks according to their types to improve the efficiency of the server device in executing the plurality of tasks.

[0110] In step S211 , the execution results of the plurality of third tasks are sent to the client device.

[0111] In the above-mentioned remote procedure call method provided in an embodiment of the present application, by converting the calling information defined in the proto file into a gRPC stubbing code in C language format, the stubbing code does not need to rely on an external library and can be applied to a device based on a real-time operating system RTOS, thereby realizing cross-end gRPC calls between RTOS devices and other platforms.

[0112] In some embodiments, the execution result of the above-mentioned server device is encapsulated in the second communication message. Figure 3 As shown, the above step S211 further includes:

[0113] Step S2111, converting the execution results of the multiple third tasks into multiple second tasks based on the six self-message protocols of gRPC.

[0114] Step S2112: adding the multiple second tasks to the task queue and scheduling the multiple second tasks.

[0115] Step S2113: performing text serialization on the plurality of second tasks according to the queue order of the plurality of second tasks, and converting the plurality of second tasks into second communication data in binary format.

[0116] Step S2114, encapsulating the second communication data into a second communication message defined by the first communication protocol;

[0117] It should be noted that the method in which the server device performs text serialization on the plurality of second tasks and encapsulates the communication data into the second communication message defined by the first communication protocol is the same as that of the client device, and will not be described in detail here.

[0118] Step S2115: Send a second communication message to the client device.

[0119] In some embodiments, after receiving the second communication message, the client device needs to parse it to obtain the result of the remote call, such as Figure 4 As shown, the method provided in the embodiment of the present application also includes steps S212-S215.

[0120] Step S212: The client device performs protocol decomposition and text deserialization on the received second communication message to obtain second communication data in binary format.

[0121] Step S213: the client device converts the second communication data into a plurality of second tasks.

[0122] Step S214: adding the multiple second tasks to the task queue and scheduling the multiple second tasks.

[0123] Step S215 , analyzing the plurality of second tasks according to the queue order of the plurality of second tasks, and determining the execution result of the remote procedure call, and thus the entire process of the remote procedure call method is completed.

[0124] Combine the following Figure 5 The task scheduling method in the task queue in the embodiment of the present application is illustrated by way of example. Figure 5 The dark task blocks and light task blocks in the figure are message sending tasks and message response tasks respectively.

[0125] As shown in the figure, when the client makes an RPC call, it first generates a client sending task (the first task). After these tasks are queued, they are dequeued in order and serialized by the message protocol unit and assembled with the corresponding protocol before being sent to the server.

[0126] After receiving the message task, the message protocol module on the server side puts it into the queue. The server side receives the task out of the queue according to the queue order, dispatches the task to the thread pool, and calls the service registration method to perform RPC method processing, obtains the return result of the server side, and puts the converted result sending task (third task) into the queue. After that, the sending task in the queue is encapsulated and submitted to the message protocol module on the server side, and the message protocol module sends it to the client device.

[0127] After the client device receives the communication message sent by the server device, it performs protocol disassembly and deserialization, converts it into a client receiving task (second task) and queues it. After these tasks are queued, they are dequeued in order, and the client device parses and obtains the execution result.

[0128] Combination of the above Figure 1-Figure 5 , describes the method embodiment of the present application in detail, and the following is combined with Figure 6-Figure 8 , describes the device embodiment of the present application in detail. It should be understood that the description of the method embodiment corresponds to the description of the device embodiment, so the parts not described in detail can refer to the previous method embodiment.

[0129] Figure 6 is a schematic structural diagram of a remote procedure call device 600 provided in an embodiment of the present application. The remote call device 600 is applied to a client device, which is a device based on RTOS. The client device uses the remote call device 600 to call a server device, which is a device that supports gRPC calls. The client device and the server device can be Figure 1 The client device 110 and the server device 120 in the embodiment. Figure 6 The device 600 in the embodiment comprises:

[0130] The stub code generation module 610 is used to convert the call information defined in the proto file into a remote procedure call RPC code in a C language structure. The call information defined in the proto file includes the message defined in the message field and the method of the RPC service defined in the service field.

[0131] The first interface module 620 is used to convert the RPC code of the C language structure into multiple first tasks based on the six sub-message protocols of gRPC, and the multiple first tasks are message sending and / or message reading tasks.

[0132] The first processing module 630 is used to add the multiple first tasks to a task queue and schedule the multiple first tasks.

[0133] The first message protocol module 640 is used to perform text serialization on the multiple first tasks according to the queue order of the multiple first tasks, convert the multiple first tasks into first communication data in binary format; and encapsulate the first communication data into a first communication message defined by the first communication protocol.

[0134] The first communication module 650 is used to send the first communication message to the server device so that the server device executes the remote procedure call RPC service in response to the call information to determine the execution result; and receive the execution result sent by the server device.

[0135] Optionally, the execution result is encapsulated in a second communication message, and the second communication message is a message defined according to the first communication protocol.

[0136] The first message protocol module is further used to: perform protocol decomposition and text deserialization on the second communication message to obtain second communication data in binary format.

[0137] The first processing module is also used to: convert the second communication data into multiple second tasks; add the multiple second tasks to the task queue and schedule the multiple second tasks; parse the multiple second tasks according to the queue order of the multiple second tasks to determine the execution result of the remote procedure call.

[0138] Optionally, the stub code generation module is also used to: based on the nanopb tool, convert the message defined by the message field into a message of C language structure, and generate a client call interface and a service registration interface of C language structure according to the remote procedure call RPC service method defined by the service field.

[0139] Optionally, the first message protocol module is further used to: use the nanopb tool to convert the multiple first tasks into binary communication data in a standard protobuf format to obtain the first communication data.

[0140] Optionally, the first communication protocol includes one of an http2 protocol, a domain socket protocol or a pipe communication protocol.

[0141] Figure 7is a schematic structural diagram of a remote procedure call device 700 provided in another embodiment of the present application, wherein the remote procedure call device 600 is applied to a server device, and the server device is called by a client device through the remote procedure call device, and the client device is a device based on a real-time operating system RTOS, and the server device is a device that supports the Google remote procedure call gRPC framework, and the above-mentioned client device and server device can be Figure 1 The client device 110 and the server device 120 in the embodiment. Figure 7 The device 700 in the embodiment comprises:

[0142] The second communication module 710 is used to receive a first communication message sent by the client device, where the first communication message is a communication message defined according to a first communication protocol between the server device and the client device;

[0143] The second message protocol module 720 is used to perform protocol decomposition and deserialization on the first communication message to obtain third communication data in binary format;

[0144] The second interface module 730 is used to convert the third communication data into a plurality of third tasks, wherein the plurality of third tasks include message sending and / or message reading tasks;

[0145] The second processing module 740 is used to add the plurality of third tasks to a task queue, schedule the plurality of third tasks, and determine a queue order of the plurality of tasks; and execute the plurality of third tasks according to the queue order of the plurality of third tasks, and determine execution results of the plurality of third tasks;

[0146] The second communication module 710 is further configured to send the execution results of the plurality of third tasks to the client device.

[0147] Optionally, the execution results of the multiple third tasks are encapsulated in a second communication message, and the second interface module is also used to: convert the execution results of the multiple third tasks into multiple second tasks based on the six sub-message protocols of gRPC.

[0148] The second processing module is further used to: add the multiple second tasks to the task queue and schedule the multiple second tasks.

[0149] The second message protocol module is also used to: perform text serialization on the multiple second tasks according to the queue order of the multiple second tasks, and convert the multiple second tasks into second communication data in binary format; and encapsulate the second communication data into the second communication message defined by the first communication protocol.

[0150] The second communication module is further used to: send the second communication message to the client device, so that the client device determines the execution result according to the second communication message.

[0151] Optionally, the second processing module is further used to: dispatch the multiple third tasks to a thread pool according to a queue order of the multiple third tasks, so as to execute the multiple third tasks.

[0152] Optionally, the first communication protocol includes one of an http2 protocol, a domain socket protocol or a pipe communication protocol.

[0153] Figure 8 It is a schematic structural diagram of an electronic device 800 provided in an embodiment of the present application, and the device may be a client device or a server device. Figure 8 The dotted line in the figure indicates that the unit or module is optional. The electronic device 800 can be used to implement the method described in the above method embodiment. The electronic device 800 can be, for example, a client device or a server device mentioned in any of the above embodiments, or the electronic device 800 can be Figure 1 The client device 110 or the server device 120 in the embodiment; or, the electronic device 800 may also be a chip or an integrated circuit capable of implementing the method of the above embodiment.

[0154] The electronic device 800 may include one or more processors 810. The processor 810 may support the electronic device 800 to implement the method described in the foregoing method embodiment. The processor 810 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor 810 may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0155] The electronic device 800 may further include one or more memories 820. The memory 820 stores a program, which can be executed by the processor 810 so that the processor 810 executes the method described in the above method embodiment. The memory 820 may be independent of the processor 810 or integrated in the processor 810.

[0156] The electronic device 800 may further include a transceiver 830. The processor 810 may communicate with other devices or chips through the transceiver 830. For example, the processor 810 may transmit and receive data with other devices or chips through the transceiver 830.

[0157] The embodiment of the present application also provides a chip, including a processor, which can be used to call and run a computer program from a memory, so that a device equipped with the chip performs the method described in the above method embodiment. It is understandable that the processor can be any type of processor mentioned above. It is understandable that the memory can be independent of the chip or integrated in the chip.

[0158] An embodiment of the present application further provides a computer-readable storage medium, wherein the storage medium stores executable code, and when the executable code is executed, the method described in any of the above embodiments is implemented.

[0159] The embodiment of the present application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to the electronic device provided in the embodiment of the present application, and the program enables the computer to execute the method in each embodiment of the present application.

[0160] It should be understood that the terms used in this application are only used to explain the specific embodiments of this application, and are not intended to limit this application. The terms "first", "second", "third", and "fourth" in the specification and claims of this application and the drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

[0161] In the embodiments of the present application, the "indication" mentioned can be a direct indication, an indirect indication, or an indication of an association relationship. For example, A indicates B, which can mean that A directly indicates B, for example, B can be obtained through A; it can also mean that A indirectly indicates B, for example, A indicates C, and B can be obtained through C; it can also mean that there is an association relationship between A and B.

[0162] In the embodiment of the present application, "B corresponding to A" means that B is associated with A, and B can be determined according to A. However, it should be understood that determining B according to A does not mean determining B only according to A, and B can also be determined according to A and / or other information.

[0163] In the embodiments of the present application, the term "corresponding" may indicate that there is a direct or indirect correspondence between the two, or an association relationship between the two, or a relationship of indication and being indicated, configuration and being configured, etc.

[0164] In the embodiments of the present application, "pre-definition" or "pre-configuration" can be implemented by pre-saving corresponding codes, tables or other methods that can be used to indicate relevant information in a device (for example, including a terminal device and a network device), and the present application does not limit the specific implementation method. For example, pre-definition can refer to what is defined in the protocol.

[0165] In the embodiments of the present application, the “protocol” may refer to a standard protocol in the communication field, for example, it may include an LTE protocol, an NR protocol, and related protocols used in future communication systems, and the present application does not limit this.

[0166] In the embodiments of the present application, the term "and / or" is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0167] In various embodiments of the present application, the size of the serial numbers of the above-mentioned processes 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.

[0168] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0169] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0170] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0171] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that can be read by a computer or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0172] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A remote procedure call method, applied to a client device, wherein the client device is a device based on a real-time operating system RTOS, wherein the client device calls a server device according to the remote procedure call method, wherein the server device is a device supporting Google's remote procedure call gRPC framework, wherein: The method comprises: Convert the call information defined in the proto file into a remote procedure call RPC code in a C language structure, wherein the call information defined in the proto file includes the message defined in the message field and the method of the RPC service defined in the service field; Convert the RPC code of the C language structure into a plurality of first tasks based on six sub-message protocols of gRPC, wherein the plurality of first tasks are message sending and / or message reading tasks; Adding the multiple first tasks to a task queue, and scheduling the multiple first tasks; According to the queue order of the plurality of first tasks, text serialization is performed on the plurality of first tasks to convert the plurality of first tasks into first communication data in binary format; Encapsulating the first communication data into a first communication message defined by a first communication protocol; Sending the first communication message to a server device, so that the server device executes the remote procedure call (RPC) service in response to the call information to determine an execution result; Receive the execution result sent by the server device.

2. The method according to claim 1, characterized in that The execution result is encapsulated in a second communication message, where the second communication message is a message defined according to the first communication protocol, and the method further includes: Performing protocol decomposition and text deserialization on the second communication message to obtain second communication data in binary format; converting the second communication data into a plurality of second tasks; Adding the plurality of second tasks to the task queue, and scheduling the plurality of second tasks; The plurality of second tasks are parsed according to the queue order of the plurality of second tasks to determine the execution result of the remote procedure call.

3. The method according to claim 1, characterized in that The process of converting the call information defined in the proto file into a remote procedure call RPC code of a C language structure includes: Based on the nanopb tool, convert the message defined by the message field into a message of a C language structure, and, According to the remote procedure call (RPC) service method defined in the service field, a client call interface and a service registration interface in a C language structure are generated.

4. The method according to claim 1, characterized in that The performing text serialization on the plurality of first tasks to convert the plurality of first tasks into first communication data in binary format includes: The plurality of first tasks are converted into binary communication data in a standard protobuf format using the nanopb tool to obtain the first communication data.

5. The method according to claim 1 or 2, characterized in that: The first communication protocol includes one of the http2 protocol, the domain socket protocol or the pipe communication protocol.

6. A remote procedure call method, applied to a server device, wherein the server device is called by a client device according to the remote procedure call method, wherein the client device is a device based on a real-time operating system RTOS, and the server device is a device supporting Google's remote procedure call gRPC framework, wherein the method comprises: Receiving a first communication message sent by the client device, where the first communication message is a communication message defined according to a first communication protocol between the server device and the client device; Perform protocol decomposition and deserialization on the first communication message to obtain third communication data in binary format; converting the third communication data into a plurality of third tasks, wherein the plurality of third tasks include message sending and / or message reading tasks; Adding the plurality of third tasks to a task queue, scheduling the plurality of third tasks, and determining a queue order of the plurality of tasks; executing the plurality of third tasks according to the queue order of the plurality of third tasks, and determining execution results of the plurality of third tasks; The execution results of the plurality of third tasks are sent to the client device.

7. The method according to claim 6, characterized in that The execution results of the plurality of third tasks are encapsulated in a second communication message, and the method further comprises: Convert the execution results of the plurality of third tasks into a plurality of second tasks based on six sub-message protocols of gRPC; Adding the plurality of second tasks to the task queue, and scheduling the plurality of second tasks; According to the queue order of the plurality of second tasks, text serialization is performed on the plurality of second tasks to convert the plurality of second tasks into second communication data in binary format; Encapsulating the second communication data into a second communication message defined by the first communication protocol; The second communication message is sent to the client device, so that the client device determines the execution result according to the second communication message.

8. The method according to claim 6, characterized in that The executing the plurality of third tasks according to the queue order of the plurality of third tasks and determining the execution results of the plurality of third tasks includes: According to the queue order of the plurality of third tasks, the plurality of third tasks are dispatched to a thread pool to execute the plurality of third tasks.

9. The method according to claims 6-8, characterized in that: The first communication protocol includes one of the http2 protocol, the domain socket protocol or the pipe communication protocol.

10. A remote procedure call device, applied to a client device, the client device is a device based on a real-time operating system RTOS, the client device uses the remote procedure call device to call a server device, the server device is a device that supports gRPC calls, and the device includes: A stub code generation module is used to convert the call information defined in the proto file into a remote procedure call RPC code in a C language structure, wherein the call information defined in the proto file includes the message defined in the message field and the method of the RPC service defined in the service field; A first interface module, used to convert the RPC code of the C language structure into a plurality of first tasks based on six sub-message protocols of gRPC, wherein the plurality of first tasks are message sending and / or message reading tasks; A first processing module, used for adding the multiple first tasks to a task queue and scheduling the multiple first tasks; A first message protocol module is used to perform text serialization on the plurality of first tasks according to the queue order of the plurality of first tasks, and convert the plurality of first tasks into first communication data in binary format; as well as, Encapsulating the first communication data into a first communication message defined in a first communication protocol; A first communication module is used to send the first communication message to a server device, so that the server device executes the remote procedure call (RPC) service in response to the call information to determine the execution result; and Receive the execution result sent by the server device.

11. The device according to claim 10, characterized in that The execution result is encapsulated in a second communication message, where the second communication message is a message defined according to the first communication protocol; The first message protocol module is further used to: perform protocol decomposition and text deserialization on the second communication message to obtain second communication data in binary format; The first processing module is further used to: convert the second communication data into a plurality of second tasks; Adding the plurality of second tasks to the task queue, and scheduling the plurality of second tasks; The plurality of second tasks are parsed according to the queue order of the plurality of second tasks to determine the execution result of the remote procedure call.

12. The device according to claim 10, characterized in that The stub code generation module is also used for: Based on the nanopb tool, convert the message defined by the message field into a message of a C language structure, and, According to the remote procedure call (RPC) service method defined in the service field, a client call interface and a service registration interface in a C language structure are generated.

13. The device according to claim 10, characterized in that The first message protocol module is also used for: The plurality of first tasks are converted into binary communication data in a standard protobuf format using the nanopb tool to obtain the first communication data.

14. The device according to claim 10 or 11, characterized in that The first communication protocol includes one of the http2 protocol, the domain socket protocol or the pipe communication protocol.

15. A remote procedure call device, applied to a server device, the server device is called by a client device through the remote procedure call device, the client device is a device based on a real-time operating system RTOS, and the server device is a device that supports Google's remote procedure call gRPC framework, the device comprising: A second communication module, configured to receive a first communication message sent by the client device, wherein the first communication message is a communication message defined according to a first communication protocol between the server device and the client device; A second message protocol module, used for performing protocol decomposition and deserialization on the first communication message to obtain third communication data in binary format; A second interface module, used for converting the third communication data into a plurality of third tasks, wherein the plurality of third tasks include message sending and / or message reading tasks; A second processing module, configured to add the plurality of third tasks to a task queue, schedule the plurality of third tasks, and determine a queue order of the plurality of tasks; as well as, executing the plurality of third tasks according to the queue order of the plurality of third tasks, and determining execution results of the plurality of third tasks; The second communication module is further used to send the execution results of the plurality of third tasks to the client device.

16. The device according to claim 15, characterized in that The execution results of the plurality of third tasks are encapsulated in the second communication message: The second interface module is also used to: convert the execution results of the multiple third tasks into multiple second tasks based on the six sub-message protocols of gRPC; The second processing module is further used to: add the multiple second tasks to the task queue and schedule the multiple second tasks; The second message protocol module is further used to: perform text serialization on the plurality of second tasks according to the queue order of the plurality of second tasks, and convert the plurality of second tasks into second communication data in binary format; and Encapsulating the second communication data into a second communication message defined by the first communication protocol; The second communication module is further used to: send the second communication message to the client device, so that the client device determines the execution result according to the second communication message.

17. The device according to claim 15, characterized in that The second processing module is also used for: According to the queue order of the plurality of third tasks, the plurality of third tasks are dispatched to a thread pool to execute the plurality of third tasks.

18. The device according to claims 15-17, characterized in that The first communication protocol includes one of the http2 protocol, the domain socket protocol or the pipe communication protocol.

19. A client device, characterized in that: The system comprises a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and execute the computer program from the memory to implement the method according to any one of claims 1 to 5.

20. A server device, characterized in that: The system comprises a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call and execute the computer program from the memory to implement the method according to any one of claims 6 to 9.

21. A chip, characterized in that: include: A processor, used to call and run a computer program from a memory, so that a device equipped with the chip executes a method as claimed in any one of claims 1 to 5 or claims 6 to 9.

22. A computer-readable storage medium, characterized in that: The storage medium is used to store a computer program, and when the computer program is executed, the method according to any one of claims 1 to 5 or claims 6 to 9 is implemented.

Images