CIS307: Hints for Homework 5

You need to name sm.c your client file for RAND_PROC and you need to name sm_svc_proc.c your server file for STORE_MANAGER_RPC. You will name sm.x the file containing the XDR definition of the interface to the store. Your naming and compilation of the file used for STORE_MANAGER_S is not affected by the use of rpc. Then you use the make command in conjunction with the following makefile. This results in a log similar to the following: 
   rpcgen sm.x
   cc -c -o sm.o  sm.c 
   cc -c sm_clnt.c
   cc -c sm_xdr.c
   cc -o sm sm.o sm_clnt.o sm_xdr.o  
   cc -c -o sm_svc_proc.o sm_svc_proc.c
   cc -c sm_svc.c
   cc -o sm_svc sm_svc_proc.o sm_svc.o  sm_xdr.o

We need to worry about the content of each of the three code files, sm.x, sm.c, and sm_svc_proc.c.

The sm.x interface specification file

The first thing that we need to define is the interface to be used by the Remote Procedure Calls. This information is placed in the file sm.x. The interface specification for our familiar functions for using the STORE was: 
    function TABLE_UPDATE (WHO : TABLE_ID;
			     WHAT : TABLE_ELEM) return INTEGER;

    function TABLE_READ (WHO : TABLE_ID;
			   out WHAT  : TABLE_ELEM) return INTEGER;
A possible RPC interface specification in the file sm.x is: 
   /*
    * sm.x: Interface for homework 5
    */

   const TABLEIDSIZE = 13;
   const TABLELEMSIZE = 9;

   struct record1 {
     string id;
     string value;
   };
   struct record2 {
     string value;
     int rc;
   };

   /* program definition */
   program SMPROG {
        version SMVERS {
          int UPDATE(record1) = 1;
          record2 READ(string) = 2;
        } = 1;
   } = 0x20000003;
Notice that there are similarities and differences between our original definitions and the definitions in the interface. Each function in the interface accepts only a single argument, representing the in arguments of the original function. The value returned by the function will have to represent the function's value and the outarguments, if any. Both the argument of the call and the value of the call are pointers to the actual values. [This is something that forces us to be careful because it is easy to make errors. You might check the sm.h, sm_clnt.c, and sm_svc.c files to see exactly what is the c translation and use of the interface specification.]

The files sm.c and sm_svc_proc.c represent respectively the calling program and an implementation [only for demonstration purposes] of the functions. You should copy into a directory of yours the sm.x, sm.c, sm_svc_proc.c, and makefile files in these hints and use make. Then you should use the program images sm and sm_svc respectively for clients and the server. This should convince you that the RPC mechanism for client-server interaction works.

Implementing the Functions on the Server: sm_svc_proc.c

Your implementation of the store management functions should have the intended functionality of truly updating and reading the content of the local store table.

Notice that your code in sm_svc_proc.c, while implementing the store-read and store_update functions, does not constitute a whole program. The rest of the implementation of the STORE_MANAGER_RPC, including the "main" part, will be created automatically by the rpcgen compiler from the sm.x file.

Once the executable image sm_svc is produced, you can launch it from the Unix shell without any command line parameters.

The Client Code: sm.c

The client code, in sm.c, includes code for interacting with the user (the main thread), for interacting with STORE_MANAGER_S, and for interacting with STORE_MANAGER_RPC (aka . It is implemented just as in homework 3. But this time it uses RPC instead of using directly sockets. The changes should be easy.

A client process RAND_PROC is started from the Unix shell. It is given one command line parameter: