About SunRPC programming

Article title: SunRPC programming overview. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
　　 I. Overview
In the traditional programming concept, the process is a piece of code compiled by the programmer locally and can only be limited to local running, that is, the running relationship between the main program and the process is the local call relationship. As a result, this structure is no longer able to meet the needs of the ever-growing network. In general, the traditional process call mode cannot make full use of the resources of other hosts on the network (such as CPU and Memory), nor can it improve the degree of code sharing between entities, this wastes a lot of host resources.
The RPC programming described in this article is a good solution to the drawbacks of the traditional process. Through RPC, we can make full use of a multi-processor environment with non-shared memory (for example, connecting multiple workstations through local Wang), so that your applications can be easily distributed across multiple workstations, applications run on a multi-processor computer. You can easily share process code, improve the utilization of system resources, and run a large number of numeric processing operations on a system with high processing capability, this reduces the burden on front-end servers.
　　
　　 II. Structure and calling mechanism of RPC
As mentioned above, RPC is actually a C/S programming mode, which is a bit similar to the C/S Socket programming mode, but a higher layer than RPC. After the RPC service is established, the call parameters of the client can be UDP or TCP (that is, TI-RPC-unrelated transmission) through the underlying RPC transmission channel ), based on the destination address provided before transmission and the RPC upper-layer Application number, go to the corresponding RPC Application Porgramme Server, and the client is in the waiting status until the response or Time-Out signal is received. The specific flowchart is shown in F1. When the server receives the request message, it will tell the RPC system's routine entry address based on the RPC registration, perform the corresponding operation, and return the result to the client.
　　
F1
After an RPC call is completed, the client program continues to run only when the corresponding thread sends the corresponding signal. Of course, a service host can have multiple remote processes to provide services. how can we express a unique remote process? A remote process has three unique elements: Program number, version number, and process number. The program number is used to differentiate a group of related remote processes with a unique process. A program can have one or several different versions, and each version of the program contains a series of processes that can be called remotely, this allows RPC of different versions to provide services at the same time. Each version contains many processes that can be called remotely, and each process has a unique process number.
　　
　　 III. RPC-based application system development
After introducing the RPC principles, we will continue to discuss how to develop RPC-based application systems.
Generally, RPC development involves three steps:
A. define the communication protocol for the customer/server.
The communication protocol is used to define the name of a service process, the data type of the call parameter, and the data type of the return parameter. It also includes the underlying transmission type (which can be UDP or TCP ), of course, the underlying RPC function can automatically select the connection type to establish TI-RPC. The simplest way to generate a protocol is to use a protocol compilation tool, which is commonly used with Rpcgen. I will describe its usage in detail in the following examples.
B. develop client programs.
C. develop server programs.
When developing client and server programs, RPC provides interfaces for calling development routines at different levels. APIs at different levels provide different degrees of control over RPC. Generally, it can be divided into five levels of programming interfaces. next we will discuss the functional functions provided by each layer.
1. simple layer routine
The simple layer is intended for common RPC Applications. designed to quickly develop RPC application services, it provides the following functions.
Function description
Rpc_reg () registers a process on a specific type of transport layer to serve as the RPC program
Rpc_call () remote call of the specified process on the specified host
Rpc_Broadcast () broadcasts a remote procedure call request to all specified transmission ports.
　　
2. high-level routine
At this layer, the program needs to create a client handle before sending a call request, or create a server handle before listening to the request. At this layer, the program can freely bind its own applications to all transmission ports. It provides the following functions.
　　
Function description
The Clnt_create () program uses this function to tell the location of the underlying RPC server and its transmission type.
Clnt_create_timed () defines the maximum timeout time for each connection attempt
Svc_create () creates a server handle on a specified type of transmission port, telling the corresponding entry address of the underlying RPC event process
Clnt_call () sends an RPC call request to the server
　　
3. intermediate layer routine
The middle layer provides the program with more detailed RPC control interfaces, and the code at this layer becomes more complex, but the operation is more effective. It provides the following functions.
Function description
Clnt_tp_create () create a client handle on the specified transmission Port
Clnt_tp_create_timed () defines the maximum transmission latency.
Svc_tp_creaet () creates a service handle on the specified transmission Port
Clnt_call () sends an RPC call request to the server
　　
4. expert layer routine
This layer provides more transmission-related functions. It provides the following functions.
　　
Function description
Clnt_tli_create () create a client handle on the specified transmission Port
Svc_tli_create () create a service handle on the specified transmission Port
Rpcb_set () maps the RPC service and network address by calling rpcbind
Rpcb_unset () deletes the ing relationship created by rpcb_set ().
Rpcb_getaddr () calls rpcbind to specify the transmission address of the RPC service.
Svc_reg () associates the specified program and version with the corresponding time routine.
Svc_ureg () deletes an association created by svc_reg ().
The Clnt_call () client initiates an RPC request to the specified server.
　　
5. underlying routines
This layer provides all calling interfaces that control transmission options. It provides the following functions.
　　
Function description
Clnt_dg_create () establishes a client handle on the client in the remote process using the connectionless method.
Svc_dg_create () creates a service handle without connection
Clnt_vc_create () uses connection-oriented methods to create customer handles
Svc_vc_create () establishes RPC service handle in connection-oriented mode
The Clnt_call () client sends a call request to the server.
　　
　　 IV. instance introduction
Below I will introduce the implementation of RPC through simple layer to readers through examples. In this process, we usually use the RPC compiling tool-Rpcgen. The Rpcgen tool is used to generate remote program interface modules. it will compile the source code written in the RPC language. the Rpc language is similar in structure and syntax to the C language. The C source code compiled by Rpcgen can be directly compiled using the C compiler. Therefore, the entire compilation process is divided into two parts. The source program of Rpcgen ends with. x and the following file is generated through its compilation:
A) a header file (. h) contains descriptions of server and client program variables, constants, and types.
B) a series of XDR routines that can process data types defined in the object.
C) a standard program framework on the Server side.
D) a standard program framework of the Client.
Of course, these outputs can be optional. the Rpcgen compilation options are described as follows:
Option
'-'A generates all template files
'-' SC: generate the template file of the client
'-' Ss generates the server-side template file
'-'SM generate Makefile file
(For details, see Solaris Rpcgen Manaul)
　　
Rpcgen source code time. x:
/* Time. x: Remote time printing protocol */
Program TIMEPROG {
Version PRINTIMEVERS {
String PRINTIME (string) = 1;
} = 1;
} = 0x20000001;
Time_proc.c source code:
/* Time_proc.c: implementation of the remote procedure "printime "*/
# Include
# Include /* Always needed */
# Include "time. h"/* time. h will be generated by rpcgen */
# Include
/* Remote version of "printime "*/
Char ** printime_1 (char ** msg, struct svc_req * req)
　　
{
Static char * result;/* must be static! */
Static char tmp_char [100];
Time_t rawtime;
　　
FILE * f;
　　
F = fopen ("/tmp/rpc_result", "a + ");
If (f = (FILE *) NULL ){
Strcpy (tmp_char, "Error ");
Result = tmp_char ;;
Return (& result );
}
Fprintf (f, "% s \ n", * msg); // used for debugging
Fclose (f );
Time (& rawtime );
Sprintf (tmp_char, "Current time is: % s", ctime (& rawtime ));
Result = tmp_char;
Return (& result );
}
Rtime. c source code
/*
* Rtime. c: remote version
* Of "printime. c"
*/
　　
# Include
# Include "time. h"/* time. h generated by rpcgen */
　　
Main (int argc, char ** argv)
　　
{
CLIENT * clnt;
Char * result;
Char * server;
Char * message;
　　
　　
If (argc! = 3 ){
Fprintf (stderr, "usage: % s host message \ n", argv [0]);
Exit (1 );
}
　　
Server = argv [1];
Message = argv [2];
　　
/*
* Create client "handle" used
* Calling TIMEPROG on the server
* Designated on the command line.
*/
　　
Clnt = clnt_create (server, TIMEPROG, PRINTIMEVERS, "visible ");
　　
If (clnt = (CLIENT *) NULL ){
/*
* Couldn't establish connection
* With server.
* Print error message and die.
*/
　　
Clnt_pcreateerror (server );
Exit (1 );
}
　　
/*
　　
* Call the remote procedure
* "Printime" on the server
*/
　　
Result = * printime_1 (& message, clnt );
If