Design and implementation of an embedded RPC

Abstract: Based on the study of the principle of remote procedure call and the characteristics of embedded systems, a remote procedure call design and its implementation on the server side of the VxWorks operating system and the client side of the Windows operating system are proposed. After being applied in the project, this design and implementation demonstrate good practicality, portability and extensibility.
Keywords: remote procedure call; embedded system; network; state machine

Remote procedure call (RPC) was first discussed in B. J. Nelson's doctoral thesis. The process here is equivalent to the meaning of routine and function. The idea of ​​RPC comes from the fact that most programs use procedures as the minimum design unit. RPC expands the procedure call mechanism, allowing the client process to call the server process through the network.
Based on the idea of ​​RPC, different organizations and companies have developed different RPC protocols. There are ONC RPC of SUN, DCE RPC of the Open Software Foundation, MSRPC of Microsoft, etc. These RPCs all rely on specific operating systems and define their own interface description languages ​​(IDL), which are too complicated for embedded development.

1 RPC Mechanism
1.1 Procedure Call
A typical procedure call is that procedure A passes parameters and control rights to procedure B, and procedure B returns the results and control rights to procedure A after a series of operations or the next level of process.
1.2 RPC Process
RPC is divided into synchronous RPC and asynchronous RPC. In synchronous RPC, the thread that the client issues the RPC call will be blocked until it is completed from the server. In asynchronous RPC, the thread that the client issues the call will not be blocked but will continue to execute. This paper takes synchronous RPC as the research object.
The idea of ​​RPC is to make remote procedure calls look like local procedure calls. From the perspective of program operation, its process is shown in Figure 1. The client (MACHINE A) process sends a remote procedure call request to the server (MACHINE B) through the network. After receiving the request, the server processes it and calls the corresponding procedure for execution. After the execution is completed, the server returns the result to the client process. After issuing the remote procedure call, the client process is blocked until the server returns the result to the client process.

1.3 RPC structural model
From the perspective of description, different RPC models are generated, such as the model discussed in Andrew S. Tanenhum's book Distributed Operating Systems and the RPC model in BJ. Nelson's paper. However, the main components of these models are the same. Figure 2 is Dr. BJ. Nelson's RPC structural model. The client process, client stub and RPC runtime instance are executed on the client side. The service process, server stub and RPC runtime instance are executed on the server side. The client process calls the corresponding client stub. The client stub packs the parameters. The client's RPC runtime sends the packed parameters to the server RPC runtime through the network. The server stub unpacks the parameters and then calls the server process. After completion, the result is returned to the server stub. The server stub packs the result to the server RPC runtime. The server RPC runtime sends the packed parameters to the client RPC runtime. The client stub unpacks the parameters and takes out the result and returns it to the client.

Although the idea of ​​RPC is relatively simple, there are many issues to consider. Since there are many different CPUs, such as X86, ARM, SPARC, etc., as well as various DSPs and single-chip microcomputers, parameter passing problems arise. For example, X86 uses the least significant byte first, while SPARC uses the most significant byte first. Some mainframes use EBCDIC code, while other processors use ASCII code. Stubs are used to solve these problems. There are also pointer problems, involving many considerations such as physical addresses, virtual addresses, and address spaces. We know that different computers cannot directly access each other's addresses. In addition, if the parameters of the process are data structures, this leads to the problem of data alignment. From this, it can be inferred that all RPC implementations are applicable within a certain range. The RPC design in this article assumes that the client and server have the same big and small endianness and are both 32-bit processors.

1.4 SunRPC
Sun RPC is sometimes called ONC (Open Network Computing) RPC. Sun RPC provides an interface language IDL and rpcgen for C language support. This language can define constants, typedef, structure, union. rpcgen can generate server code, client stub and header files. The server code mainly establishes sockets, registers ports and listens, accepts connections, unpacks parameters, calls actual procedures, and packs return values. The client stub packs parameters, sends them to the server, and unpacks the return values. The disadvantage of Sun RPC is that it does not support Windows well.

2 Design
This design is different from the traditional model. The server side is divided into: network communication, receiving state machine and process processing. The client side is divided into network communication, sending state machine and process call.
Figure 3 is the state machine of the server side. The server process enters the GetHeader state from the initial state. GetHeader is to read the header information of the remote procedure call. If all data is obtained at one time, that is, nCurLen>=dwTotalSize, it enters the GetComplatePacket state, otherwise it enters the GetData state. GetData reads parameter data, and reads data until all data is obtained and enters the GetComplatePacket state. If a timeout occurs during this period, it returns to the GetHeader state. The timeout starts from the first byte of GetHeader. If dwTotalSize bytes cannot be read within the defined time, the Timeout returns to the GetHeader state. During GetHeader and GetData, if there is an error in reading the data (such as the client disconnects, the recv function returns an error), the state machine exits. GetComplatePacket gets the complete package. CheckCall determines whether the current call is a valid procedure call. If invalid, it enters the state and replies an invalid command to the client, and finally enters the GetHeader state. If valid, this call is processed and the result is sent to the client.

Figure 4 shows the client state machine. First, the parameters are packaged and sent to the server, and the server waits for a reply, and then enters the GetHeader state. GetHeader, GetData and Get Com-plate Packet have the same meaning as the corresponding states of the server. If timeout occurs, a timeout error is returned. If the entire packet is obtained, it is split and finally returned.
DCE-RPC and ONC-RPC allow the selection of UDP or TCP protocols. TCP protocol, the transmission control protocol, provides a connection-oriented, reliable byte stream service. The UDP protocol does not provide reliability. It only sends the datagrams passed by the application to the IP layer, but it cannot guarantee that they can reach the destination. Based on the reliability of the TCP protocol, TCP is selected as the communication protocol.
3 Implementation
3.1 Data structure
The server and the client use a common header information and parameter structure for each process. The header information is defined as follows. dwCallID is the identification number of the process. Each process has a unique number. bCallType is the type of call. dwTotalSize is the number of bytes in the entire packet. dwReturn is the return result.

The types of procedure calls are defined as follows. RPC_TYPE_SIMPLE_WRITEREAD is a simple read and write operation, where both input and output parameters are in the header and procedure parameter data structures. RPC_TYPE_READ means that the return result is stored in a separate memory. RPC_TYPE_WRITE means that the write information is stored in a separate memory. The RPC_TYPE_WRITE_READ call requires memory to store the input data, and the output result needs to be stored when returning.

Each procedure defines its own input and output parameter structure. For example, for the GetCommState procedure, an RPC_GETCOMMSTATE structure is established.

Because each compiler implements different alignment of the members of the struct data structure, the same struct may have different sizes on the client and server, and the same members may have different positions in the structure. To ensure that the client and server have the same alignment, we use byte alignment with #pragma pack(1).
3.2 Packet Memory Layout
The header and parameters are in the beginning, and the rest varies depending on the specific procedure. Take the layout of RPC_TYPE_WRITE_READ type as an example: header information, parameters, input memory block [1...N], output memory block [1...N]. The layout of other process types is similar.
3.3 Server-side implementation
3.3.1 Network module implementation
RPC is executed in a separate task. Figure 5 is the RPC task flow chart. Call VxWorks system function taskSpawn to establish an RPC task. Call socket() to establish a connection-oriented SOCK_STREAM socket, bind to bind the socket to the local network address and port number, listen to declare to listen for client connection requests on this port, and accept to block and wait for the request to arrive.

3.3.2 State machine implementation
After accept, enter the server-side state machine. Set the socket returned by accept to a non-blocking state. When calling send on a blocked socket, if there is not enough output buffer, the call will be blocked. The same is true for recv. When the data to be read is not ready, the caller is blocked. The server does not know the number of bytes to be read each time, so the blocked socket cannot work.
Allocate 2 blocks of memory: A and B. Memory A is used to save the content of recv, and memory B is used to save the content of the Packet sent by the client. Because the server does not know how much content the client will send, the size of memory B is checked before copying from memory A to memory B each time. If the remaining size of memory B is not enough, reallocate it.
After getting the entire Packet, that is, GetComplatePacket, call the server's local procedure according to dwCallID, and after returning, package the return value and memory and send them to the client.
3.4 Client implementation
The client process is shown in Figure 6. When running under Windows, first call WSAStartup. Windows searches for the corresponding Socket library according to the requested Socket version, and then binds the found Socket library to the application. Then the socket is initialized, connected to the server, and then the procedure is called. For example, procedure call 1 will enter the state machine in Figure 4. The state machine is similar to the server side, except that the parameters are first packaged and sent to the server, and then unpacked and the returned information is copied to the memory after the return.

4 Conclusion
The RPC designed and implemented in this paper can be applied to white-box testing, cross-platform development environment, and client software development. Commercial embedded IDE software is very expensive. Through this RPC, testers can use open source environments such as cygwin to develop white-box test code. In addition, for embedded development with a large number of operating interfaces, it is necessary to frequently download to the development board for verification. The RPC in this paper can be used to build a cross-platform development environment, directly develop the interface part on Windows, and finally download it to the development board, thereby greatly improving development efficiency. Most embedded software has corresponding PC client software, and the implementation in this paper is also suitable for developing PC client software.