The following is a simple example to show what is involved in writing a client and server RPC.
First, programming is assisted by a compiler rpcgen that takes a specification for a remote procedure interface and generates the client stubs and the server stubs.
The example we will look at will specify two procedures:
bin_date_1()
which returns the binary time and date on the remote
host, and
str_date_1()
which takes the binary time and returns the human-readable
string.
The specification for this interface is the file date.x. Procedures start at number 0, but 0 must be the "null procedure" and will be generated automatically by the rpcgen compiler.
The command rpcgen date.x will produce three files.
date_svc.c, date.h, date_clnt.c
representing the server stub, a header file used by client and server,
and the client stub.
The client main function rdate.c is linked to the file date_clnt.c produced by rpcgen to create the client program.
Similarly the server procedures that we write date_proc.c are linked to the program date_svc.c produced by rpcgen to create the server program.
A Makefile that does all the work is provided, but if you use this Makefile at Auburn, it generates compiler warnings
"date_svc.c", line 119: warning: argument #3 is incompatible with prototype:
prototype: pointer to char : "unknown", line 0
argument : pointer to union {long str_date_1_arg}
"date_svc.c", line 129: warning: argument #3 is incompatible with prototype:
prototype: pointer to char : "unknown", line 0
argument : pointer to union {long str_date_1_arg}
To quote Doug.Hughes:
don't worry about them. You could correct them by editing the code, but it's not worth it, and it's sun's problem anyway.
To run the program, first start the server as a background process
date_svc &on some host_machine. This will create a socket and bind a local port to the socket. It will then call a function in the RPC library svc_register to register the program number and version. The port mapper keeps track of the program number, version number and port number. The server will wait for a client request. This is all done by the server stub.
Then from another system (or the same system) invoke the procedures by running the client program
r_date host_machineExecution of r_date first calls clnt_create which specifies the name of the remote system, the program number, version number and protocol. The function contacts the port mapper on the remote system to find out the port for the server.
The client program then calls the bin_date_1 function which is handled by the client stub. This stub determines which procedure is being called and calls the appropriate function on the remote host. When the server returns the information to the stub, the stub takes the information and returns it to our program. Similarly str_date_1() is called, with the difference being the client stub has to pass an argument to the remote procedure.