Computer Networks (CS425)
Instructor: Dr. Dheeraj Sanghi
Prev |
Next |
Index 
Remote Procedure Call (Contd...)
We now look at the different ways of writing RPC programs. There are three levels at which RPC programs can be written:
- On one extreme we can use some standard applications or programs provided by sun-RPC. For example, one can use the library function int rnusers (char *machinename ) for finding number of users logged onto a remote system. 
 - On the other hand we can use RPC runtime library : This has the maximum flexibility and efficiency. It has various functions like opening a connection, connecting to a port-mapper and other low level functions. Using this we can write our own stubs. This is however relatively difficult to use. 
 - The best approach is to use RPCgen : RPCgen stands for RPC generator. It generates client and server stubs. There are several details that cannot be easily controlled (for example, the number of retries in case of timeout). RPCgen takes as input a specification file which has a list of the procedures and arguments. It creates the client stub and server stub.
 
Writing the Configuration File
If we use RPCgen, then our work is essentially reduced to writing 
    a specification file. This file has the procedure names, argument types, 
    return types etc. Here we show a simple RPC specification file ( spec.x ) for 
    printing a message on some other machine :
     
    program MESSAGEPROG {
                    
    version MESSAGEVERS {
                        
    int PRINTMESSAGE ( string ) = 1;
                    
    } = 1;
    } = 99;
        
    We will have to do some changes on the server as well as client side. 
    The server program ( msg_proc.c ) will look like this :
     
    #include <stdio.h>
    #inculde <rpc/rpc.h>
    #include "msg.h"
    int *printmessage_1( msg )
    char **msg;
    {
            . . . . .
            . . . . .
    }
     
    On the client side the program ( client.c ) will look like 
  
  
    - #include <stdio.h>
 
    - #inculde <rpc/rpc.h>
 
    - #include "msg.h"
 
    - main( int argc, char *argv[])
 
    - {
 
    -                 
    client *c1;
 
    -                 
    int *result;
 
    -                 
    char *server = argv[1];
 
    -                 
    char *message = argv[2];
 
    -                 
    if (( c1 = clnt_create( server, MESSAGEPROG, MESSAGEVERS, "tcp" )) == NULL
 
    -                 
    {
 
    -                         
    // error
 
    -                 
    }
 
    -                 
    result = printmessage_1( &message, c1);
 
    -                 
    . . . . .
 
    - }
 
  
  After creating the specification file 
  we give the command $rpcgen   spec.x  
  ( where spec.x is the name of 
  the specification file ). The following files actions are taken and the files 
  spec.h, spec_svc.c, spec_clnt.c get created :
  
  
 
  
    
    - Once we have these files we write
 
    - $cc msg_proc.c spec_svc.c
 
    - $cc client.c spec_clnt.c
 
    -  
 
    
    - 1. 
    When we start the server program it creates a socket and binds any 
    local port to it. It then calls svc_register, to register the program 
    number and version. This function contacts the port mapper to register 
    itself.
 
    - 2.
     When the 
    client program is started it calls clnt_create. This call specifies 
    the name of the remote system, the program number, version number, and the 
    protocol. This functions contacts the port mapper and finds the port for the 
    server ( Sun RPC supports both TCP and UDP).
 
    - 3.  The client now 
    calls a remote procedure defined in the client stub. This stub sends the 
    datagram/packet to the server, using the port number obtained in step two. 
    The client waits for a response transmitting the requests a fixed number of 
    times in case of a timeout. This datagram/packet is received by the server 
    stub associated with the server program. The server stub executes the called 
    procedure.  When the function returns to the server stub it takes the return 
    value, converts it to the XDR format and transmits it back to the client. 
    The client stub receives the response, converts it as required and returns 
    to the client program
 
  
  Authentication
  RPC defines several possible forms of authentication, including a simple 
  authentication scheme that relies on UNIX and a more complex scheme that uses 
  the Data Encryption Standard (DES). 
  Authentication protocols can be of the following types: 
  
    - NULL Authentication - In this case, no authentication is done. 
    Neither the client cares about its identity nor the server cares who the 
    client is. Example is a time server. 
 
    - UNIX Style Authentication - Unix authentication relies on the 
    client machine to supply its hostname and the userid of the user making the 
    request. The client also specifies its local time as a timestamp which can 
    be used to sequence requests. The client also sends the main numeric group 
    identifier of the group of which the user is a member and also the group 
    identifiers of all the groups of which the user is a member. Based on this 
    information, the server decides whether the client will be given permission 
    to execute the procedure requested. This is a very weak form of security as 
    the user and group identifiers are the same as UID and GID in the client's 
    own machine, and anyone can send these information and see the data. This 
    form of authentication is used in NFS. 
 
    - Data Encryption Standard (DES) - Here the client gives a password 
    which is sent to the server in encrypted form. Encryption is done based on 
    keys which are known only to the client and the server. This is indeed a 
    powerful method of authentication. 
 
    - SHORT - This method is used for short form of authentication in 
    messages after the first one. The client is authenticated only once during 
    the initial handshake and a handle is given to the client. In future the 
    client communicates with the server using the handle. It is difficult for 
    another user to break in. This is not an entirely new style of 
    authentication, and it can be used with any form of authentication. 
 
  
Image References
- http://www.hlla.is.tsukuba.ac.jp/~yas/sie/pdsoft-2001/2002-01-10/images/rpcgen-files.gif
 
back to top
Prev| Next |
Index