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 zurück übermittelt. RPC stützt sich auf das Client/Server-Modell: der lokal agierende Client-Rechner nutzt das Programm des entfernten Servers.
...................... .................................
. . . .
. Computer A . . Computer B .
. . . .
. Client Programm . . Server Dämon .
. . . .
. aktiv | RPC-Aufruf . . .
. V . . .
. -----------------------------------> Initialisierung .
. . . Datenübertragung . | des Dienstes .
. . . . | .
. . . . | Aufruf der Dienstroutine .
. . . V .
. Programm . . ----------> .
. wartet . . | die Dienst- .
. . . | routine .
. . . . Antwort V .
. . . . <----------- .
. . . | .
. Rückkehr aus . . | Abschluß des Dienstes .
. dem RPC-Aufruf . . V .
. <------------------------------------ .
. | . Datenübertragung . .
. | Programm- . . .
. | fortsetzung. . .
. V . . .
...................... .................................
Bild 1
Die Objekte des Serverdienstes sind primär Programme und CPU Resourcen. Dabei müssen Start- und/oder Ergebnisdaten übertragen werden. Sie haben innerhalb eines Prozessimages im Computer A eine rechnerspezifische Darstellung (z.B. Integer Big Endian oder IEEE-Float). Um solche Typen einem Prozeß auf einem anderen Computer (B) zur Verfügung zu stellen, müssen sie in das für B-Rechner spezifische Format (z.B. Little Endian) umgewandelt werden. Das geschieht durch eine Umwandlung in ein spezielles nichtrechnerspezifisches Format vor dem Verschicken und die Rückumwandlung nach der Ankunft im Rechner B. Das nichtrechnerspezifische Format heißt eXternal Data Representation (XDR).
---------------
Format A ----> | XDR-Filter |
---------------
|
|
Datenübertragung
|
|
V
---------------
| XDR-Filter | ----> Format B
---------------
Bild 2
RPC bietet Dienste an, die die Eigenschaften der Netzwerkverbindung
transparent (unsichtbar) machen. So können komfortabel Anwendungen
konstruiert werden, die ihre Programme oder Daten in einem Netzwerk
verteilen (verteilte Anwendungen). Ein Programm kann z.B. eine Prozedur
rdate() aufrufen, die das Datum auf einem anderen Rechner
liefert, ohne daß auf dieser Ebene die Probleme der Netzwerkkommunikation
behandelt werden.
Die RPC-Schnittstelle besteht aus Funktionsaufrufen, in denen alle
Details der Netzwerkkommunikation und Formatumwandlung implementiert sind.
Aus diesen Funktionsaufrufen könnte z.B. rdate() aufgebaut sein.
Unter anderem
sind Dienste wie NIS, REX, NFS, NLM mit Hilfe von RPCs konstruiert. RPC
selbst benutzt low-level Netzwerkprotokolle wie TCP, UDP oder SPX/IPX.
Nach dem ISO-OSI Modell ist RPC/XDR zwischen Transportschicht und der Anwendungsschicht anzusiedeln.
-------------------------- ISO/OSI-Terminologie ------------------------
| Client- | | Server- |
| Prozeß ------------- | | ------------ Prozeß |
| | Client- | | | | Server- | |
| | routinen | | Application Layer | | routinen | |
| ------------- | | ------------ |
| lokaler | ^ | | | ^ |
| Prozedur- V | | | V | |
| aufruf --------------- | | --------------- |
| | Client-Stub | | RPC | | Server-Stub | |
| | XDR-Filter | | XDR: Presentation Layer | | XDR-Filter | |
| --------------- | | --------------- |
| | ^ | Session Layer | | ^ |
------------- | -- | ----- ------ | -- | ----------
| | | |
System call | | Transport Layer z.B. TCP | |
| | | |
------------- | -- | ----- ------ | -- | ----------
| lokaler V | | | V | |
| Kernel --------------- | | |
| | Netzwerk- | | Network Layer z.B. IP | entfernter |
| | routinen | | | Kernel |
| --------------- | | |
------------- | -- ^ ----- ------ | -- ^ ----------
| | | |
| | Interrupt | |
V | V |
------------------------------ ------------------------
| Netzwerkkarte z.B.Ethernet | Datalink Layer | |
------------------------------ ------------------------
V | | |
| -------<----------------------------------- |
| Physical Layer |
---------------------------------------->------------
Bild 3
Da wir hier nur eine UNIX-Umgebung betrachten, kann RPC auch zur Kommunikation zwischen zwei Prozessen innerhalb eines Rechners verwendet werden. Der RPC-Mechanismus wurde jedoch in auf anderen Betriebssystemen, wie System/370 VM, MVS, VMS, MS-DOS implementiert.
RPC wurde in den 70-er Jahren entwickelt. Die ersten Versionen sind bei Xerox entstanden. Eine davon, »Courier«, wurde als Produkt 1981 eingeführt. 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 eine möglichst große Verbreitung der RPC/XDR-Schnittstelle zu erreichen, stellte Sun den Quellcode ihrer Implementierung als Public Domain allen zur Verfügung und ermunterte so dazu, sie einzusetzen. Als Bibliothek ist RPC/XDR von Sun auch in UNIX System V Release 4 (SVR4) von AT&T enthalten. Sie wurde ebenfalls dazu benutzt, Anwendungen auf Suns SPARC-Stations und VAX, IBM-PC, oder Cray zu verteilen.
Analoge Systeme sind:
Dieser Abhandlung liegt die SUN Version zugrunde.
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, daß der Client mit dem ersten RPC-Aufruf die Daten im Server sucht und sie erst mit dem zweiten RPC-Aufruf vom Server zum Client überträgt. Dann hängt die Antwort des Servers auf den zweiten Aufruf davon ab, ob der erste Aufruf vorher überhaupt 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 abstürzen, so muß 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 Abstürzen 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 Fällen deshalb immer der gleiche.
Als Beispiel betrachten wir die NFS-Implementierung von Sun. Sie unterstützt
zustandslose Server. Deshalb wird das Öffnen einer Datei mittels
open() zuerst im Client zurückgehalten, falls sich diese
auf einem entfernen Filesystem befindet. Die Übertragung
der für open() spezifischen Daten geschieht erst bei dem
nachfolgenden read() oder write() Aufruf zusammen in
einer Transaktion. Ein Absturz des entfernten Filesystems zwischen
open() und read() führt zu keinen Problemen.
Zustände sind lokal. Problematische Zustände propagieren nicht im
Netzwerk.
Diese Begriffsbildung ist nicht notwendigerweise auf RPC beschränkt, sondern ist allgemein auf das Client/Server Modell bezogen. Sie gestattet eine adäquate Beschreibungen der Probleme, die in Client-/Server-Konfigurationen auftreten.