CIS307: Hints for Homework 6

You organize your program in (at least) the three files sm.x, sm.c, and sm_svc_proc.c as indicated in the statement of the homework. 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;
			   var WHAT  : TABLE_ELEM) return INTEGER;
A possible RPC interface specification in the file sm.x is: 
   /*
    * sm.x: Interface for homework 6
    */

   const IDSIZE = 9;

   struct record1 {
     string id;
     int elem;
   };
   struct record2 {
     int elem;
     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. Do not worry about concurrency at the server [you can use threads if you like]. Concurrent requests will be served sequentially [if you do not use threads].

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, 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) and for interacting with the server (the access thread). It is implemented just as in homework 5. 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: