R P C - Remote Procedure Calls
(Aufruf entfernter Prozeduren)

Der RPC-Mechanismus

RPC (Remote Procedure Call - Aufruf entfernter Proceduren) ist eine Programmiertechnik, die es erlaubt, innerhalb eines Programmes Daten an einen anderen Rechner zu verschicken. Im anderen Rechner wird eine dort abgelegte Prozedur mit den empfangenen Daten als Parameter aufgerufen und die Ergebnis-Daten werden wieder an den lokalen Rechner zurueck uebermittelt. RPC stuetzt sich auf das Client/Server-Modell: der lokal agierende Client-Rechner nutzt das Programm des entfernten Servers.

 ......................                    .................................
 .                    .                    .                               .
 .    Computer A      .                    .        Computer  B            .
 .                    .                    .                               .
 .  Client Programm   .                    .       Server Daemon            .
 .                    .                    .                               .
 . aktiv | RPC-Aufruf .                    .                               .
 .       V            .                    .                               .
 .        ----------------------------------->   Initialisierung           .
 .       .            .  Datenuebertragung  .   |  des Dienstes             .
 .       .            .                    .   |                           .
 .       .            .                    .   | Aufruf der Dienstroutine  .
 .                    .                    .   V                           .
 .     Programm       .                    .   ---------->                 .
 .      wartet        .                    .              | die Dienst-    .
 .                    .                    .              | routine        .
 .       .            .                    .      Antwort V                .
 .       .            .                    .   <-----------                .
 .                    .                    .   |                           .
 .   Rueckkehr aus     .                    .   |  Abschluss des Dienstes    .
 .   dem RPC-Aufruf   .                    .   V                           .
 .        <------------------------------------                            .
 .       |            .  Datenuebertragung  .                               .
 .       | Programm-  .                    .                               .
 .       | fortsetzung.                    .                               .
 .       V            .                    .                               .
 ......................                    .................................

Bild 1

                                ---------------
              Format A  ---->   | XDR-Filter  |
                                ---------------
                                       |
                                       |
                               Datenuebertragung
                                       |
                                       |
                                       V
                                ---------------
                                | XDR-Filter  | ---->   Format B
                                ---------------
            Bild 2

--------------------------   ISO/OSI-Terminologie     ------------------------
| Client-                |                            |              Server- |
| Prozess  ------------- |                            | ------------ Prozess |
|          | Client-   | |                            | | Server-  |         |
|          | routinen  | |       Anendungsschicht     | | routinen |         |
|          ------------- |                            | ------------         |
| lokaler     |    ^     |                            |      |    ^          |
| Prozedur-   V    |     |                            |      V    |          |
| aufruf --------------- |                            | ---------------      |
|        | Client-Stub | |   RPC                      | | Server-Stub |      |
|        | XDR-Filter  | |   XDR: Presentation Layer  | | XDR-Filter  |      |
|        --------------- |                            | ---------------      |
|             |    ^     |     Sitzungsschicht        |      |    ^          |
------------- | -- | -----                            ------ | -- | ----------
              |    |                                         |    |
  System call |    |        Transportschicht z.B. TCP        |    |
              |    |                                         |    |
------------- | -- | -----                            ------ | -- | ----------
| lokaler     V    |     |                            |      V    |          |
| Kernel --------------- |                            |                      |
|        | Netzwerk-   | |     Netwerkschicht z.B. IP |    entfernter        |
|        |   routinen  | |                            |     Kernel           |
|        --------------- |                            |                      |
------------- | -- ^ -----                            ------ | -- ^ ----------
              |    |                                         |    |
              |    | Interrupt                               |    |
              V    |                                         V    |
------------------------------                        ------------------------
| Netzwerkkarte z.B.Ethernet | Datenverbindungsschicht|                      |
------------------------------                        ------------------------
              V    |                                         |    |
              |    -------<-----------------------------------    |
              |                  physikalishe Schicht             |
              ---------------------------------------->------------
Bild 3

Geschichte der RPC-Versionen

RPC wurde in den 70-er Jahren entwickelt. Die ersten Versionen sind bei Xerox entstanden. Eine davon, "Courier", wurde als Produkt 1981 eingefuehrt. Die Version von Sun Microsystems, ONC (Open Network Computing) entstand 1985 und diente gleich demselben Entwickler zum Aufbau von NFS, das schnell zu einem Industriestandard wurde. Um moeglichst grosse Verbreitung der RPC/XDR-Schnittstelle zu erreichen, stellt Sun den Quellcode ihrer Implementierung als Public Domain allen zur Verfuegung und ermuntert so dazu sie einzusetzen. Als Library ist RPC/XDR von Sun auch in UNIX System V Release 4 (SVR4) von AT&T enthalten. Sie wurde ebenfalls dazu benutzt, Anwendungen auf Sun's SPARC-Stations und VAX, IBM-PC, oder Cray zu verteilen. Analoge Systeme sind:

Server mit und ohne Zustand

Die RPC-Schnittstelle kann dazu verwendet werden, im Client ein Protokoll auf der Applikationsebene zu unterhalten, das die interne Logik des Programms wiedergibt. Z.B. kann dieses Protokoll besagen, dass der Client mit dem ersten RPC-Aufruf die Daten im Server sucht und sie erst mit dem zweiten RPC-Aufruf vom Server zum Client uebertraegt. Dann haengt die Antwort des Servers auf den zweiten Aufruf davon ab, ob der erste Aufruf vorher ueberhaupt stattfand. Der Zustand des Servers nach dem ersten Aufruf ist in Bezug auf diese Antwort sicherlich nicht der gleiche, wie davor. Sollte der Server z.B. zwischen den Aufrufen abstuerzen, so muss er nach dem erneuten Start auch noch in den richtigen Zustand gebracht werden, damit der zweite Aufruf richtig beantwortet werden kann. Der Client soll von Abstuerzen des nicht betroffen sein. Solche Server nennt man Server mit Zustand. Im Gegensatz dazu antworten zustandslose Server auf die gleiche Request immer gleich, der Zustand der Servers ist in solchen Faellen deshalb immer der gleiche.

Als Beispiel betrachten wir die NFS Implementierung von Sun. Sie unterstuetzt zustandslose Server. Deshalb wird jedes open() von einem File auf dem entfernten Filesystem zuerst im Client zurueckgehalten. Die Uebertragung der fuer open() spezifischen Daten geschieht erst bei dem nachfolgenden read() oder write() zusammen in einer Transaktion. Der Absturz des entfernten Filesystems zwischen open() und read() fuehrt zu keinen Problemen. Zustaende sind lokal. Problematische Zustaende propagieren nicht im Netzwerk.

Diese Begriffsbildung ist nicht notwendigerweise auf RPC beschraenkt, sondern ist allgemein auf das Client/Server Modell bezogen. Sie gestattet eine adaequate Beschreibungen der Probleme, die in Client/Server Konfigurationen auftreten.

Das Prinzip von XDR

Bei der Uebertragung der Prozedurparametern bzw. deren Ergebnissen mittels RPC muss der zahlenmaessige Informationsgehalt und die Struktur von, unter Umstaenden komplizierten Datengebilden bewahrt werden. Dabei muessen folgende Gesichtspunkte beachtet werden.

                   serialising                deserialising
                       |                           |
                       V                           V

-------------      ----------                  ----------      -------------
|           | ---> |  XDR - |                  |  XDR - | ---> |           |
|           |      | Filter1| ---------------> | Filter1|      |           |
|           |      ----------                  ----------      |           |
| App1 z.B. |                                                  | App2 z.B. |
|           |                  Datentransfer                   |           |
|  Client   |                                                  |  Server   |
|           |      ----------                  ----------      |           |
|           |      |  XDR - | <--------------- |  XDR - |      |           |
|           | <--- | Filter2|                  | Filter2| <--- |           |
-------------      ----------                  ----------      -------------

                       ^                           ^
                       |                           |
                 deserialising                serialising

Bild 4

XDR-Streams

Die Operationen der Serialisierung/Deserialisierung von Daten beziehen sich auf Datenstroeme, die realisiert werden entweder

        enum xdr_op {
            XDR_ENCODE = 0,
            XDR_DECODE = 1,
            XDR_FREE   = 2
        };

        typedef struct {
            enum xdr_op  x_op;
            struct xdr_ops {
                bool_t   (*x_getlong)();
                bool_t   (*x_putlong)();
                bool_t   (*x_getbytes)();
                bool_t   (*x_putbytes)();
                u_int    (*x_getpostn)();
                bool_t   (*x_setpostn)();
                caddr_t  (*x_inline)();
                void     (*x_destrpy)();
            }              *x_ops;
            caddr_t        x_public;
            caddr_t        x_private;
            caddr_t        x_base;
            int            x_handy;
        } XDR;

----------------------------------
|                                |
| ---------  Umwandlung mittels  |                               ----------
| | user  |   XDR-Filter         |                               | output |
| | data  | ----------->         |   UDP-Pakete        --------->| data   |
| |       |                      |                    /          |        |
| |       |                         X  X  X  X       /           ----------
| ---------                  -----------------------
|                       /        |   ----------->           Rueckumwandlung
|                      /         |    XDR-Strom            mit dem gleichen
|  user prozess       /     ------------------------         XDR-Filter
|   space            /     /
|                   /     /      |
|                  /     /       |
|                 /     /        |
|        XDR-          /         |
|       handle                   |
|                                |
|                                |
----------------------------------

Bild 5

	enum xdr_op {
		XDR_ENCODE,    /* Serialisierung             */
		XDR_DECODE,    /* Deserialisierung           */
		XDR_FREE       /* befreit den Speicherplatz  */
	};

Das Funktionsprinzip

Im Gegensatz zur entfernten Ausfuehrung von Kommandos (Remote Command Execution - RCX) wie z.B. rsh, rcp oder rlogin, muss bei einem RPC-Call im Server-Rechner nicht notwendig ein neuer Prozess gestartet werden. Die Verbindung wird zu einem bereits laufenden, auf die Anforderung wartenden Prozess hergestellt, der als Server im engeren Sinne bezeichnet wird. So ein Server-Prozess kann mehrere ausfuehrbare Prozeduren als Dienste anbieten. Es ist aber ebenfalls moeglich, dass in einem Server-Rechner mehrere Server-Prozesse laufen, die verschiedene Arten von Diensten anbieten.

Die entfernten Dienste werden durch Programm- und Prozedurnummer adressiert. RPC ermoeglicht zusaetzlich eine Unterscheidung zwischen verschiedenen Versionen: In einem Server-Prozess koennen gleichzeitig mehrere Versionen der gleichen Prozedur angeboten werden. Damit kann man eine Prozedur-Entwicklung im Netzwerk sinnvoll verwalten. Der Client muss also bei der Adressierung der entfernten Prozedur den Server-Rechner, die Programmnummer, die Versionsnummer und die Prozedurnummer kennen.

Netzwerk Transport-Protokolle, wie z.B (TCP) ermoeglichen zusaetzlich zu Netzwerkadresse und Hostadresse (bereits in der Netzwerkschicht vorhanden) Adressierungen, die aus sog. Portnummern bestehen.

    Transportadresse = Netzwerkadresse + Hostadresse + Portnummer
                       |                           |
                       -----------------------------
                                    |
                               z.B. IP-Adresse
    Bild 9

	(Programmnummer, Prozedurversion) <--> (Protokoll, Portnummer)

            -----------------------------------
            |      Programm PROGNR            |
            |                                 |
            |  ---------------------------    |
            |  |   Version  VERSNR       |    |
            |  |                         | <- | ------> Portnummer
            |  |  -------------------    |    |
            |  |  | Prozedur PROCNR |    |    |
            |  |  -------------------    |    |
            |  |    .                    |    |
            |  |    .                    |    |
            |  ---------------------------    |
            |    .                            |
            |    .                            |
            |    .                            |
            |  --------------------------     |
            |  |   Version  VERSNR_2    |     |
            |  |     .                  |     |
            |  |     .                  |     |
            |  --------------------------     |
            -----------------------------------

            Bild 10

     ------------------                             -------------------------
     |                |                             |                       |
     |                |                        -----------                  |
     |   Client       |                        | Port    |     Server       |
     |                |                        |  a      |                  |
     |                |                        -----------                  |
     |                |                             |                       |
     | ------------   |                        -----------      ----------  |
     | |          | -------------------------> | Port    | ---> | Port-  |  |
     | | Client-  |   |                ------> | 111     | <--- | mapper |  |
     | |          | -----------        |       -----------      ----------  |
     | | Programm |   |       |        |            |                       |
     | |          | <------   |        |       -----------                  |
     | ------------   |   |   |  Registrierung | Port    |                  |
     |                |   |   |  des Services  |  b      |                  |
     |                |   |   |        |       -----------                  |
     |                |   |   |        |            |                       |
     |                |   |   |        |       -----------      ----------- |
     |                |   |   |        ------- | Port    | ---> | Server- | |
     |                |   |   ---------------> |  c      |      | program | |
     |                |   -------------------- |         | <--- |         | |
     |                |                        -----------      ----------- |
     |                |                             |                       |
     ------------------                             -------------------------

     Bild 11

Die Programmnummer

SUN erlaubt dem Anwender Programmnummern zwischen 0x 20 000 000 und 0x 3f fff fff, und reserviert andere fuer sich (siehe Anhang). Diese Nummer ist es, unter der Server-Prozess seine Dienste beim Portmapper registriert, und nach der der Client seinen Request anmeldet (well-known-number).

Diese Liste ist nicht vollstaendig (siehe auch /etc/rpc). Sie wird von SUN immer wieder erweitert. Um eigene Dienste fest eintragen zu lassen, wendet man sich an SUN.

Das Portmapper Protokoll

Das Portmapper Protokoll ist in der RPC-Sprache angegeben.

        const PMAP_PORT = 111           /* portmapper port number */


        /*
        ** A mapping of (program, version, protocoll) to port number
        */
        struct mapping {
            unsigned int prog;
            unsigned int vers;
            unsigned int prot;
            unsigned int port;
        };


        /*
        ** Supported values for port field
        */
        const IPPROTO_TCP =  6;
        const IPPROTO_UDP = 17;


        /*
        ** A list of mappings
        */
        struct *pmaplist {
            mapping  map;
            pmaplist *next;
        };


        /*
        ** Arguments to callit()
        */
        struct call_args {
            unsigned int prog;
            unsigned int vers;
            unsigned int proc;
            opaque args<>;
        };


        /*
        ** Results of callit()
        */
        struct call_result {
            unsigned int port;
            opaque res<>;
        };


        /*
        ** Portmapper procedures
        */
        program PMAP_PROG {
            version PMAP_VERS {
                void        PMAPPROOC_NULL    (void)      = 0;
                bool        PMAPPROOC_SET     (mapping)   = 1;
                bool        PMAPPROOC_UNSET   (mapping)   = 2;
                uint        PMAPPROOC_GETPORT (mapping)   = 3;
                pmaplist    PMAPPROOC_DUMP    (void)      = 4;
                call_result PMAPPROOC_CALLIT  (call_args) = 5;
            } = 2;
        } = 100000;

High-level RPC

High-level RPC: Fuer diese Schicht ist das Betriebssystem, die Rechnerhardware und das verwendete Netzwerk komplett transparent. Der Programmierer ruft eine C-Routine auf, die das Netzwerkhandling vollstaendig verdeckt: z.B. rnusers(), um die Anzahl der eingeloggten Benutzer auf einem entfernten Rechner zu erfragen. Andere bekannte Routinen sind

rusers	gibt Informationen ueber User auf einem entfernten Rechner
havedisk	ueberprueft, ob der entfernte Rechner eine Harddisk hat
rstat	erfragt Informationen ueber Rechnerauslastung
rwall	schreibt eine Nachricht an entfernte Rechner
yppasswd	startet den Password-Update im Network Information Service

Die Routinen des High-levels von RPC sind in der Bibliothek librpcsvc.a als fertige Objekt-Module enthalten. Ihre vollstaendige Auflistung findet man im R3-Teil der Standard UNIX Manual Pages.

Wegen der Einfachheit der Programmierarbeit wird diese Schicht bei vielen Autoren (z.B. Corbin) gar nicht erwaehnt, das Programm-Interface wird nur in zwei Schichten geteilt und Middle-level von RPC als High-level bezeichnet. Die vorliegende Beschreibung haelt sich an den Sprachgebrauch von SUN.

Middle-level RPC

Die Programmierschnittstelle zur mittleren Schicht besteht aus drei Bibliotheksfunktionen: registerrpc(), svc_run() und callrpc(), deren Synopsis sich im Anhang befindet. registerrpc() dient dazu, die Existenz einer Dienstroutine auf der Serverseite anzumelden. Mit svc_run() wird die Hauptschleife des Serverprozesses gestartet, die Anfragen des Clients entgegennimmt und beantwortet. Mit callrpc() laesst sich dann der eigentliche Client-Aufruf realisieren. Ein dem rnuser()-Beispiel analoges aus High-level RPC sieht dann so aus:

        #include 
        #include 
        #include 

        extern unsigned long     *nuser();

        main ()
        {
            registerrpc (RUSERSPROG, RUSERSVERS, RUSERSPROC_NUM,
                nuser, xdr_void, xdr_long);
            svc_run ();
            fprintf (stderr,
                "Server: main loop broke down, server died\n");
            exit (1);
        }

        #include 
        #include 
        #include 

        main (argc, argv)
        int     argc;
        char    *argv[];
        {
            unsigned long   n;
            int             stat = -1;

            if (argc > 1) {
                if (stat = callrpc (argv[1],
                    RUSERSPROG, RUSERSVERS, RUSERSPROC_NUM,
                    xdr_void, 0, xdr_long, &n))
                    fprintf (stderr, "%s callrpc error %d\n",
                                         argv[0],stat);
                printf ("%d users on %s\n", n, argv[1]);
            }
            exit (0);
        }

        xdr_long (handle, l)
        XDR     *handle;
        long    *l;

Low-level RPC

Middle-level RPC-Routinen verstecken Details der RPC-Kommunikation. Manchmal besteht jedoch die Notwendigkeit gerade diese Details zu beeinflussen. In der Praxis kann das drei Faelle betreffen:

                      ---------------------------------
                      |          Middle-level         |
                      ---------------------------------
                      |  Client-Seite | Server-Seite  |
------------          ---------------------------------          ------------
|          | -------> |  callrpc()    | registerrpc() | <------- |          |
|          |          |               | svc_run()     |          |          |
| Client   |          ---------------------------------          | Server   |
| Programm |              |                     |                | Programm |
|          |              |                     |                |          |
|          |              V                     V                |          |
|          |      -----------------------------------------      |          |
|          |      |              Low-level                |      |          |
|          |      -----------------------------------------      |          |
|          | ---> | Client-Seite      | Server-Seite      | <--- |          |
------------      -----------------------------------------      ------------
     |            | clnt_create()     |                   |           |
     |            | clntudp_create()  | svcudp_create()   |           |
     |            | clnttcp_create()  | svctcp_create()   |           |
     |            | clntraw_create()  | svcraw_create()   |           |
     |            | clnt_destroy()    | svc_destroy()     |           |
     |            | clnt_freeres()    | svc_freeargs()    |           |
     |            | clnt_call()       |                   |           |
     |            | clnt_control()    |                   |           |
     |            |                   | svc_register()    |           |
     V            |                   | svc_unregister()  |           V
------------      |                   | svc_sendreply()   |      ------------
|          | <--- |                   | svc_getreqset()   | ---> |          |
|   XDR    |      -----------------------------------------      |   XDR    |
| Library  |               |                  |                  | Library  |
|          |               |                  |                  |          |
------------               V                  V                  ------------
                    -------------------------------------
                    |  Transport Library des Netzwerks  |
                    -------------------------------------

Bild 12

        #include 
        #include 
        #include 
        #include 

        main ()
        {
            SVCXPRT   *transp;
            int       nuser();

            transp = svcudp_create (RPC_ANYSOCK);
            pmap_unset (RUSERSPROG, RUSERSVERS);
            svc_register (transp, RUSERSPROG, RUSERSVERS, RUSERSPROC_NUM,
                nuser, IPPROTO_UDP);
            svc_run ();
            fprintf (stderr, "main loop with dispatcher broke down\n");
            svc_unregister (RUSERSPROG, RUSERSVERS);
            svc_destroy (transp);
        }

        nuser (req, transp)
        struct svc_req   *req;
        SVCXPRT          *transp;
        {
            unsigned long    n, clnt_data;

            switch (req->rq_proc)
            case NULLPROC:
                svc_sendreply (transp, xdr_void, 0);
                return;
            case RUSERPROC_NUM:
                svc_getargs (transp, xdr_u_int, &clnt_data);
                /*
                ** count user number in n-variable here
                */
                svc_sendreply (transp, xdr_u_long, &n);
                return ();
            default :
                svcerr_noproc (transp);
                return ();
            }
        }

        #include 
        #include 
        #include 
        #include 
        #include 

        main (argc, argv)
        int    argc;
        char    *argv[];
        {
            struct hostent       *hp;
            struct timeval       t1, t2;
            struct sockaddr_in   s_addr;
            int                  sock = RPC_ANYSOCK;
            register CLIENT      *cp;
            unsigned long        n;

            if (argc != 2) {
                fprintf (stderr, "usage: %s hostname\n", argv[0]);
                exit (1);
            }
            t1.tv_sec         = 3;
            t1.tv_usec        = 0;
            hp                = gethostbyname (argv[1]);
            bcopy (hp->h_addr, (caddr_t)&s_addr.sin_addr, hp->h_length);
            s_addr.sin_family = AF_INET;
            s_addr.sin_port   = 0;
            cp = clntudp_create (&s_addr, RUSERPROG, RUSERVERS, t1, &sock);

            t2.tv_sec         = 20;
            t2.tv_usec        = 0;
            clnt_call (cp, RUSERSPROG_NUM, xdr_void, 0, xdr_u_long, &n, t2);

            printf ("%d users on %s\n", n, argv[1]);
            clnt_destroy (cp);
        }

Debugging mit Raw RPC

Unter Raw RPC versteht man eine Testumgebung fuer Low-level RPC. Sie besteht aus einem Programm, das sowohl den Client- als auch der Server-Stub enthaelt. Ausgelassen wird die ganze Netzwerkkommunikation. Es folgt ein Beispiel:

        #include 
        #include 
        #include 

        main ()
        {
            CLIENT          *cp;
            SVCXPRT         *sp;
            int             ni, no;
            struct timeval  timeout = {0, 0};

            sp = svcraw_create ();
            svc_register (svc, 200000, 1, server, 0);
            cp = clntraw_create (200000, 1);
            clnt_call (cp, 1, xdr_int, &ni, xdr_int, &no, timeout);
            printf ("input %d output %d\n", ni, no);
        }

        server (req, transp)
        struct svc_req  *req;
        SVCXPRT         *transp;
        {
            int    n;

            svc_getargs (transp, xdr_int, &n);    /* get client data n     */
            n++;
            svc_sendreply (transp, xdr_int, &n);  /* pass n to the client  */
        }

Aufbau eines Server-Dispatchers

Von den drei Middle-level Routinen registerrpc(), svc_run() und callrpc() wurde svc_run noch nicht in einfachere Bestandteile zerlegt. Das kann jedoch notwendig sein, wenn der Server zusaetzlich zu der Endlosschleife mit dem Warten auf einen Request und seiner Bearbeitung noch weitere Aufgaben erledigen soll. Der vollstaendige Code fuer den standard Dispatcher sieht wie folgt aus:

        void    svc_run ()
        {
            fd_set    readfds;
            int       dtbsz = getdtablesize ();

            for (;;) {
                readfds = svc_fdset;
                switch (select (dtbsz, &readfds, NULL, NULL, NULL)) {
                case -1:
                    if (errno != EBADF)
                        continue;
                    perror ("select");
                    return;
                case 0
                    continue;
                default:
                    svc_getreqset (&readfds);
                }
            }
        }

Server mit verschiedenen Versionen

Wenn die entfernte Prozedur mehrere Versionen hat, was bei der Entwicklung oft der Fall ist, ist es sinnvoll, dass sie alle durch den gleichen Dispatcher bzw. mithilfe des Wrappers unterstuetzt werden, z.B.:

        main ()            /* Server */
        {
            .
            .
            int     proc();
            .
            .
            svc_register (transp, PROGNR, VERS_SHORT, proc, IPPROTO_TCP);
            svc_register (transp, PROGNR, VERS_LONG,  proc, IPPROTO_TCP);
            .
            .
            svc_run ();
        }

        proc (req, transp)            /* wrapper */
        struct svc_req   *req;
        SVCXPRT          *transp;
        {
            extern short   proc1();   /* procedures differ in ret value */
            extern long    proc2();
            static short   n1;
            static long    n2;

            switch (req->rq_proc {
            case NULLPROC:
                .
            case PROCNR:
                switch (req->rq_vers {
                case VERS_SHORT:
                    n1 = proc1 (req, transp);
                    svc_sendreply (transp, xdr_short, &n1);
                    break;
                case VERS_LONG:
                    n2 = proc2 (req, transp);
                    svc_sendreply (transp, xdr_long,  &n2);
                    break;
                }
            default:
                svcerr_noproc (transp);
            }
        }

        main ()                             /* Client */
        {
            struct rpc_err    err;
            short             s;
            long              l;
            .
            .
            cl = clnt_create (host, PROGNR, VERS2, "udp");
            switch (clnt_call (cl, PROCNR, xdr_void, NULL, xdr_long,
                               &l, timeout)) {

            case RPC_SUCCESS:               /* version ok.         */
                printf ("%d\n", l);
                break;

            case RPC_PROGVERSMISMATCH:      /* try former version  */
                clnt_geterr (cl, &err);
                if (err.re_vers.high < VERS2) {
                    clnt_destroy (cl);
                    cl = clnt_create (host, PROGNR, VERS1, "udp");
                    clnt_call (cl, PROCNR, xdr_void, NULL, xdr_short,
                               &s, timeout);
                    printf ("%d\n", s);
                }
                break;
            }
        }

Beispiel einer TCP-Anwendung

Das hier gezeigte Beispiel lehnt sich an die SUN rcp-Implementierung an. Es zeigt eine typische TCP-Anwendung. Die stdin wird auf der Client Seite gelesen, zum Server transportiert und dort von der entfernten Prozedur rcp auf dem stdout geschrieben. Die Lese/Schreib-Operation uebernimmt dabei ein untypischer XDR-Filter xdr_rcp(), der gegenueber ENCODE/DECODE unsymmetrisch ist.

Der Client-Teil sieht so aus:

        #include 
        #include 
        #include 
        #include 
        #include "rcp.h"        /* with PROG-, VERS-, PROC */

        main (argc, argv)       /* client side */
        int   argc;
        char  *argv[];
        {
            int                 xdr_f();
            int                 socket = RPC_ANYSOCK
            struct sockaddr_in  server;
            struct hostent      *hp;
            struct timeval      tio;
            CLIENT              *cl;

            hp = gethostbyname (argv[1]);
            bcopy (hp->h_addr, (caddr_t)&server.sin_addr), hp->h_length);
            server.sin_family = AF_INET;
            server.sin_port   = 0;
            cp = clnttcp_create (&server, PROG, VERS, &socket,
                BUFSIZ, BUFSIZ);
            tio.tv_sec  = 20;
            tio.tv_usec = 0;
            clnt_call (cl, PROC, xdr_f, stdin, xdr_void, 0, tio);
            clnt_destroy (cl);
        }

        #include 
        #include 
        #include "rcp.h"

        main ()                 /* server side */
        {
            SVCXPRT     *transp;
            int         rpc();

            transp = svctcp_create (RPC_ANYSOCK, BUFSIZ, BUFSIZ);
            pmap_unset (PROG, VERS);
            svc_register (transp, PROG, VERS, rpc, IPPROTO_TCP);
            svc_run ();
        }


        rcp (req, transp)                 /* remote procedure */
        struct svc_req      *req;
        SVCXPRT             *transp;
        {
            extern int    xdr_f();

            switch (req->rq_proc) {
            case NULLPROC :
                svc_sendreply (transp, xdr_void, 0);
                break;
            case RPCPROC :
                svc_getargs (transp, xdr_f, stdout);
                svc_sendreply (transp, xdr_void, 0);
                break;
            default :
                svcerr_noproc (transp);
                break;
            }
        }

        #include 
        #include 

        xdr_rcp (xdr, fp)                 /* XDR-Filter */
        XDR    *xdr;
        FILE   *fp;
        {
            unsigned long    size = 0;
            char             buf[BUFSIZ], *p = buf;

            if (xdr->x_op == XDR_FREE)
                return (1);
            while (1) {
                if (xdr->x_op == XDR_ENCODE)    /* in client */
                    size = fread (p, sizeof (char), BUFSIZ, fp);
                if (!xdr_bytes (xdr, &p, &size, BUFSIZ))
                    return (0);
                if (size == 0)
                    return (1);
                if (xdr->x_op == XDR_DECODE)    /* in server */
                    fwrite (p, sizeof (char), size, fp);
            }
        }

Techniken der asynchronen Kommunikation

Sicherheitsmechanismen

RPC bietet drei Stufen der sicheren Identifikation (Identification) und der Pruefung, ob diese Identifikation authentisch ist (Authentication):

Benutzung des inetd Daemons

Wie die meisten Daemon-Prozesse lassen sich RPC-Server vom Internet Services Daemon inetd(8) starten, der anhand des Konfigurationsfiles /etc/inetd.conf die dort spezifizierten Prozesse nur dann anstoesst, wenn deren Services gebraucht werden. Die Eintraege im config-File inetd.conf sehen wie folgt aus:

	p_name/version dgram  rpc/udp wait/nowait user server args
	p_name/version stream rpc/tcp wait/nowait user server args

        transp = svcudp_create (0);
        transp = svctcp_create (0, 0, 0);
        transp = svcfd_create  (0, 0, 0);
        svc_register (transp, PROGNUM, VERSION, service, 0);

RPC Error Bibliothek

RPC-Library stellt eine Reihe Error-Routinen zur Verfuegung. Sie werden teilweise von anderen RPC-Funktionen aufgerufen oder koennen vom Benutzer selbst verwendet werden. Im ersten Fall ermoeglicht die Kenntnis ihrer Namen und Parameter, dass sie vom Benutzer durch eigenen Code ersetzt werden. Das wird erreicht, indem man dem Linker eigene Routinen vor der RPC-Bibliothek voranstellt.

Die folgenden Routinen werden im Serverstub aufgerufen. Sie nehmen als Parameter nur einen Zeiger auf eine SVCXPRT-Struktur und geben void zurueck. Als Ausnahme braucht svcerr_auth() zwei Parameter. Die meisten benachrichtigen auch den Client:

svcerr_auth ()	Verletzung eines Sicherheitsmechanismus, (zweiter Parameter vom Typ enum auth_stat)
svcerr_decode ()	kann die uebertragenen Parametern nicht dekodieren
svcerr_noproc ()	Prozedur mit dieser Nummer wird nicht angeboten
svcerr_noprog ()	Programm mit dieser Nummer wurde nicht registriert
svcerr_progvers ()	Programm mit dieser Version wurde nicht registriert
svcerr_systemerr ()	Systemfehler, jedoch von keinem Protokoll
svcerr_weakaout ()	Sicherheitsmechanismus zwar nicht verletzt, aber die Sicherheitsstufe zu niedrig

Folgende Routinen werden im Clientstub aufgerufen:

void clnt_pcreateerror (str)	Error bei Client-Erstellung (auf stderr)
char *clnt_spcreateerror (str)	" , Meldung nur als Rueckgabewert
void clnt_perrno (stat)	stderr-Ausgabe ueber die Variable stat
char *clnt_sperrno (stat)	", Meldung nur als Rueckgabewert
void clnt_perror (handle, str)	Message ueber fehlerhaften clnt_call
char *clnt_sperror (handle, str)	", Meldung nur als Rueckgabewert

Die Parameter sind von Typ:

            char               *str;
            enum clnt_stat     stat;
            CLIENT             *handle;

        RPC_SUCCESS
        RPC_CANTENCODEARGS
        RPC_CANTDECODERES
        RPC_CANTSEND
        RPC_CANTRECV
        RPC_TIMEDOUT
        RPC_VERSMISMATCH        Version der ganzen RPC-Bibliothek
        RPC_AUTHERROR
        RPC_PROGUNAVAIL
        RPC_PROGVERSMISMATCH
        RPC_PROCUNAVAIL
        RPC_CANTDECODEARGS
        RPC_SYSTEMERROR
        RPC_UNKNOWNHOST
        RPC_UNKNOWNPROTO
        RPC_PMAPFAILURE
        RPC_PROGNOTREGISTERED
        RPC_FAILED

Die RPC-Messages

Die Kommunikation zwischen Client und Server geschieht bei RPC durch message-, bzw. PDU- (Protokoll Data Unit) -Uebergabe. Der Client verschickt die call-message und der Server die reply-message. Diese Messages enthalten im XDR-Format kodierte Daten. Der Austausch von PDUs zwischen den Instanzen (Client, Server) erfolgt ueber fest definierte Regeln. Die Summe dieser Regel wird als Protokoll bezeichnet.

Bei der Implementierung des RPC/XDR Protokolls werden Dienste niedriger Kommunikationsschichten verwendet. Im RPC-Standard sind keine Angaben zu dem Transport-Protokoll enthalten. Sie sind der Wahl derer ueberlassen, die RPC auf einer konkreten Rechnerarchitektur implementieren. In UNIX-Systemen sind das meistens TCP,UDP/IP mit ihren Zugriffsschnittstellen TLI oder Sockets. So ist XDR nach dem ISO/OSI Modell in der sechsten, Darstellungsschicht und RPC in der siebten, der Applikationsschicht, anzusiedeln.

Der folgender Teil dieses Kapitels ist ein kommentierter Ausschnitt aus RFC1050.

        enum msg_type {
            CALL  = 0,
            REPLY = 1
        };

        enum reply_stat {
            MSG_ACCEPTED = 0,
            MSG_DENIED   = 1
        };

        /*
        * Erfolg und Misserfolg beziehen sich hier nicht
        * auf den Ausgang der aufgerufenen Prozedur, sondern
        * ausschliesslich auf die RPC-Kommunikation.
        * Entsprechend bedeutet der Erfolg nicht, dass die
        * entfernte Prozedur ueberhaupt richtig aufgerufen wurde.
        */

        enum accept_stat {
            SUCCESS       = 0,
            PROG_UANVAIL  = 1, /* remote hasn't exported program  */
            PROG_MISMATCH = 2, /* remote can't support version #  */
            PROC_UANVAIL  = 3, /* program can't support procedure */
            GARBAGE_ARGS  = 4  /* procedure can't decode params   */
        };


        enum reject_stat {
            RPC_MISMATCH = 0, /* wrong RPC version # */
            AUTH_ERROR   = 1
        };

        enum auth_stat {
            AUTH_BADCRED      = 1, /* bad credential                */
            AUTH_REJECTEDCRED = 2, /* client must begin new session */
            AUTH_BADVERF      = 3, /* bad verifer                   */
            AUTH_REJECTEDVERF = 4, /* verifier expired or replayed  */
            AUTH_TOOWEAK      = 5, /* rejected for security reasons */
        };



        struct rpc_msg {
            /*
            ** xid der Reply-Message gleicht xid von Call-Message.
            ** xid dient der Identifiakation der richtigen Antwort
            ** und der Call-Wiederholung, keine laufende Sequenznummer
            ** wird gesichert.
            */
            unsigned int   xid;
            union switch ( msg_type) {
            case CALL:
                call_body  cbody;
            case REPLY:
                reply_body rbody;
            } body;
        };

        struct call_body {
            unsigned int  rpcvers; /* erlaubt verschiedene RPC-Versionen   */
            unsigned int  prog;    /* prog, vers, proc identifizieren      */
            unsigned int  vers;    /* eindeutig die im Server aufzurufende */
            unsigned int  proc;    /* Prozedur                             */
            opaque_auth   cred;
            opaque_auth   verf;
            /* procedure specific parameters start here */
        };

        union reply_body switch (reply_stat stat) {
        case MSG_ACCEPTED:
            accepted_reply areply;
        case MSG_DENIED:
            rejected_reply areply;
        } reply;


        struct accepted_reply {
            opaque_auth verf;
            union switch (accept_stat stat) {
            case SUCCESS:
                opaque results[0];     /* procedure result data */
            case PROG_MISMATCH:
                struct {
                    unsigned int low;  /* lowest  prog_version supported  */
                    unsigned int high; /* highest prog_version supported  */
                } mismatch_info;
            default:
                void; /* include PROG_UNAVAIL, PROC_UNAVAIL, GARBAGE_ARGS */
            } reply_data;
        };

        union rejected_reply switch (reject_stat stat) {
        case RPC_MISMATCH:
            struct {
                unsigned int low;      /* lowest  RPC-version supported */
                unsigned int high;     /* highest RPC-version supported */
            } mismatch_info;
            accepted_reply areply;
        case AUTH_ERROR:
            auth_stat      stat;
        };

Das Protokoll der Sicherheitsmechanismen

Auf der Protokoll-Ebene besteht die Schnittsstelle zu den Sicherheitsmechanismen aus zwei Feldern in der Service-Request Message: einen fuer die Identifikation (client credential) und einen fuer die Authentizitaetspruefung (Authentication) (client verifier). Reply-Message enthaelt nur ein Feld (server verifier), eine Identifikation ist hier nicht mehr noetig.

        struct call_body {
            .
            .
            opaque_auth   cred;    /* Identification */
            opaque_auth   verf;    /* Verification   */
        };

        enum auth_flavor {
            AUTH_NULL  = 0;
            AUTH_UNIX  = 1;
            AUTH_SHORT = 2;
            AUTH_DES   = 3;
        };
        struct opaque_auth {
            auth_flavor     flavor;
            opaque          body<400>;
        };

Programmerzeugung

Die XDR/RPC-Programmierung beinhaltet oft Editiertaetigkeit, die teilweise automatisiert werden kann. Die Erzeugung von C-Code aufgrund einer etwas allgemeinerer Beschreibung in einer speziell dazu geschaffenen C- aehnlichen Sprache RPC-Sprache (RPCL) kann rpcgen uebernehmen. Es folgt eine Diagrammdarstellung, welche Files aus welchen generiert werden koennen. Die RPCL-Files haben die Extension ".x" .

     ---------------           ---------------
     | transf.data |           | XDR-filter  | --
     | structure   | --------> |             |  |
     | definitions |  rpcgen   | data_xdr.c  | ------
     |  data.x     |           ---------------  |   |
     ---------------           -------------    |   |
           .                   | remote    |    |   |
           .                   | procedure | -------|
           .                   |  proc.c   |    |   |        --------------
           .                   -------------    |   |        | Server     |
           .                   ---------------  |   |------> | executable |
           .           ------> | server stub |  |   |  cc    |            |
           .           |       | file_svc.c  | -----|        --------------
     ---------------   |       ---------------  |   |
     | remote proc.| ---       ----------       |   |
     | interface   | --------> | header | -----------
     | definition  | ---       | file.h | ------|
     |  file.x     |   |       ----------       |
     ---------------   |       ---------------  |
                       ------> | client stub | -|            --------------
                      rpcgen   | file_clnt.c |  |            | Client     |
                               ---------------  |----------> | executable |
                               ------------     |      cc    |            |
                               | client   |     |            --------------
                               | program  | -----
                               | client.c |
                               ------------
     Bild 15

        /* msg.x: remote procedure interface definition */
        program MESSAGEPROG {
            version MESSAGEVERS {
                int PRINTMESSAGE (string) = 1;
            } = 1;
        } = 0x20000099;

        #include "msg.h"

        main ()
        {
            CLIENT  *cl;
            int     *result;
            char    *text = "hello";
            .
            .
            cl = clnt_create (servername, MESSAGEPROG, MESSAGEVERS, "tcp");
            .
            .
            result = printmessage_1 (&text, cl);
            .
            .
        }

        #include "msg.h"

        int    *printmessage_1 (text)
        char   **text
        {
                static int   result;
            .
            .
            .
            return (&result);
        }

Ein Erweitertes Beispiel

In einem komplexeren Beispiel haben die Parameter- und Ergebnisstypen keine primitiven XDR-Filter, so dass zu den geaenderten rpcgen-Quellen noch die Definitionen dieser Typen hinzukommen:

        const   MAXLEN = 256;
        typedef string  msgtext;

        struct msglist {
            msgtext text;
            msglist *next;
        };

        /* result-typ   */
        union result switch (int errno) {
        case 0:
            msglist *list;
        default:
            void;
        }

        /* remote procedure interface defintion */
        program MESSAGEPROG {
            version MESSAGEVERS {
                result GETMESSAGE (void) = 1;
            } = 1;
        } = 0x20000098;

        #include "msg.h"
        #define MSGSZ   sizeof(struct msglist)

        result    *getmessage_1 (void)
        {
            static result            r = { 0 };
            register struct msglist  *l = r->list, **lp = &l;
            register msgtext         t;

            if (!r.errno)           /* free space from previous call */
                xdr_free (xdr_msglist, l);
            while (t = readtext ()) {
                l = *lp = (struct msglist *)malloc (MSGSZ);
                l->text = t;
                lp      = &l->next;
            }
            lp = NULL;
            if (!t) r.errno = errno;
            return (&r);
        }

Die rpcgen-Optionen

Ausser dem generierten C-Text werden von rpcgen die fuenf folgenden #define-Konstanten angeboten:

                        RPC_HDR
                        RPC_XDR
                        RPC_SVC
                        RPC_CLNT
                        RPC_TBL

        rpcgen -DDEBUG proto.x

Dispatcher Tabellen

Die "-T" Option erzeugt Dispatchtabellen im .i-File. Der Tabelleneintrag hat folgende Struktur:

	struct rpcgen_table {
		char        *(*proc)();  /* Service Routine                       */
		xdrproc_t   xdr_arg;     /* Zeiger auf den Input des XDR-Filters  */
		unsigned    len_arg;     /* Laenge in Bytes des Input Argumentes   */
		xdrproc_t   xdr_res;     /* Zeiger auf den Output des XDR-Filters */
		unsigned    len_res;     /* Laenge in Bytes des Output Argumentes  */
	};

        #define RPCGEN_ACTION(routine)  0

        #define RPCGEN_ACTION(routine)  routine

Die Sprachbeschreibung

Die RPC-Sprache (RPCL) ist eine Erweiterung der XDR-Sprache (siehe XDR Protokoll - Spezifikation, Syntax) um folgende drei Elemente:

        program-def:
                "program" identifier "{"
                        version-def
                        version-def *
                "}" "=" constant ";"

        version-def:
                "version" identifier "{"
                        procedure-def
                        procedure-def *
                "}" "=" constant ";"

        procedure-def:
                type-specifier identifier "(" type-specifier ")"
                "=" constant ";"

Ausblick

XDR/RPC gehoert heute zum festen Bestandteil von fast jedem UNIX-System.

CORBA

Wohl das wichtigste Projekt, das auf RPC aufsetzt, ist CORBA (Common Object Request Broker Architektur), das von den groessten Softwarehersteller gemeinsam (OMG - Objekt Managament Group) verfolgt wird. Mithilfe von CORBA ist es moeglich in einem Netzwerk netzwerktransparent Objekte zu Verwalten und ihre Dienste in Anspruch zu nehmen. Solche Objekte sind Zusammenschluesse von einem Daten- und Programmteil, der die Zugriffsmethoden (methods) auf diese Daten enthaelt. Damit ist es moeglich im Netzwerk Programme ueber Datenstrukturen auszufuehren ohne Kenntnis, wo die Objekte liegen und auf welchen Rechner die Programme effektiv ablaufen (distributed data / distributed processing). Fuer das Verstaendnis von CORBA ist die Kenntnis von RCP eine Voraussetzung.

ToolTalk-Service

Ebenfalls auf XDR/RPC baut das SUN-Produkt ToolTalk. Es definiert ein Pro- tokoll auf der Applikationsebene des ISO-OSI Modells. Mit ToolTalk gebaute Applikationen sind in der Lage ihre Daten auf einfache Weise auszutauschen.

ASN.1

Abstract Syntax Notation One (ASN.1) ist eine XDR-aehnliche Sprache von ISO/OSI. Sie enthaelt als Elemente z.B. folgende Datentypen:

        boolean               |
        integer               |
        bit string            |
        octet string          |-- einfache Datentypen
        null                  |
        object identifier     |
        object descriptor     |
        external              |

        sequence of           |-- zusammengesetzte Datentypen
        set of                |

        numeric string        |
        printable string      |
        teletex string        |-- Strings
        videotex string       |
        IA5string             |

        generalized time      |
        UTCTime               |-- andere Datentypen
        graphic string        |
        general string        |

Didaktische Hinweise

Das vorliegende Skript ist als Arbeitsgrundlage fuer ein Praktikum konzipert und ist fuer ein Studium ohne Zugang zu einem lauffaehigen RPC-System wenig geeignet. Auf viele selbstverstaendliche Details, die bei den Uebungen automatisch erlernt werden, wurde verzichtet.

Kursdauer:

In ein bis zwei Wochen kann bei Kursteilnehmern mit sehr guter Vorbil- dung alles Notwendige gesagt werden, so dass sie in der Lage sind mithilfe des Skripts und des Referenz Manuals selbstaendig Applikationen zu entwickeln. Die normale Kursdauer, ohne Protokoll-Spezifikationen, betraegt drei bis vier Wochen. Fuer Personen, die RPC auf einer Rechnerarchitektur neu portieren moechten, ist eine mindestens einwoechige detaillierte Auseinandersetzung mit Protokoll-Spezifikationen unerlaesslich.

Voraussetzungen der Kursteilnehmer:

Fragen, Aufgaben

Antworten

Backus-Naur Notation

Literaturangaben

Online documentation:

http://www12.w3.org/History/1992/nfs_dxcern_mirror/rpc/doc/Introduction/Abstract.html http://docs.sun.com/