Remote Procedure Call

Remote procedure call (RPC), auf deutsch etwa „Aufruf einer fernen Prozedur“ oder Prozedur-Fernaufruf ist eine Technik zur Netzwerkkommunikation auf der fünften, teilweise auch sechsten Schicht des ISO/OSI-Modells. Mit Hilfe von RPC können über ein Netzwerk Funktionsaufrufe auf entfernten Rechnern durchgeführt werden.

RPC wurde ursprünglich durch Sun Microsystems für Network File System (NFS) entwickelt. Der genaue Aufbau von RPC wird unter RFC 1057 und RFC 1831 beschrieben. Die Idee hinter RPC beruht auf dem Client-Server-Modell, es sollte die gemeinsame Nutzung von Programmfunktionen über Rechnergrenzen ermöglichen. Ein RPC-Aufruf läuft fast immer synchron ab, das heißt, dass der aufrufende Client mit der Ausführung des weiteren Programmcodes wartet, bis er eine Antwort der Prozedur vom Server erhalten hat.

Es lassen sich drei inkompatible Versionen von RPC unterscheiden:

Die am weitesten verbreitete Variante ist das ONC RPC ('Open Network Computing Remote Procedure Call), das vielfach auch als Sun RPC bezeichnet wird. Für diese RPC-Variante findet sich unter anderem auch eine Implementierung in Linux.
Die zweite nicht ganz so weit verbreitete RPC Variante ist das Distributed Computing Environment Remote Procedure Call oder kurz DCE RPC. Microsoft verwendet in seinen Windows NT basierten Betriebssystemen eine Version von DCE RPC, MSRPC genannt, welche von der DCE RPC 1.1 Referenzimplementation abgeleitet ist.
Die dritte Variante schließlich ist ein Versuch der ISO, ein standardisiertes ISO RPC zu etablieren, von dem es bislang jedoch kaum eine Implementierung gibt.

Die wichtigste Komponente auf der Serverseite ist der Portmapper-Daemon, der bei ONC RPC auf dem UDP- und TCP-Port 111 lauscht; bei DCE RPC übernimmt diese Funktion der Endpointmapper, welcher auf dem UDP- und TCP-Port 135 lauscht. Portmapper resp. Endpointmapper übernehmen die Koordination der durch den Client gewünschten Funktionsaufrufe. Jedes Programm, das auf dem Server RPC-Dienste zur Verfügung stellen will, muss ihm daher bekannt sein.

Neben NFS basiert unter anderem noch Network Information Service (NIS) in weiten Teilen auf ONC RPC-Aufrufen. Die ganze Remoteadministration von Windows NT basierten Systemen läuft weitestgehend über MSRPC ab.

Ein weiterer RPC-Ableger ist das so genannte XML-RPC, welches die versendeten Daten in ein XML-Dokument kapselt und über eine HTTP-Verbindung überträgt.

Ablauf

Man unterscheidet zwischen synchronem RPC und asynchronem RPC. Beim synchronen RPC wartet der Client auf die Antwort. Der Programmablauf des Clients ist streng sequentiell. Beim asynchronen RPC wartet der Client hingegen nicht auf die Antwort und kann inzwischen andere Operationen ausführen.

Findet ein RPC statt, so kommuniziert ein Prozess mit einem anderen Prozess (Interprozesskommunikation). Es wird also eine Prozedur in einem anderen Adressraum ausgeführt. Der andere Prozess kann sich auf demselben oder auf einem anderen Rechner befinden.

Um eine fremde Prozedur aufzurufen, muss eine Nachricht vom Client-Prozess zum Server-Prozess versendet werden. In dieser müssen der Name der Prozedur (oder eine ID) und die zugehörigen Parameterwerte enthalten sein. Die Nachricht sollte letztlich bei einem Server-Prozess ankommen, der genau diese Prozedur implementiert (hierzu erforderlich beim Server: register (Bekanntmachung, sicherstellen des öffentlichen Zugangs); hierzu erforderlich beim Client: lookup und binding).

Die Suche nach einem entsprechenden Server kann durch Broadcast (in einem lokalen Netz) realisiert werden oder durch Inanspruchnahme eines Verzeichnisdiensts. (Der Verzeichnisdienst hält ein global verfügbares Objekt, genauer ein Verzeichnis von Servern und den von ihnen implementierten Prozeduren bereit.)

Die Suche und die Codierung, aber auch z. B. notwendige Recovery-Maßnahmen (error recoveries) erledigt auf der Seite des Clients der client stub. Auf der Seite des Servers erledigt Entsprechendes (Decodieren, Recovery-Maßnahmen, jedoch keine Suche) der server stub.

Wenn der Rechner, auf dem der Server-Prozess läuft, die Anfrage empfängt, so wird mit Hilfe eines Daemons (Portmapper) entweder erst der Prozess erschaffen, der die Prozedur ausführt. Oder alternativ kann ein Prozess auch nur aktiviert werden (in diesem Fall wird eine vordefinierte Anzahl von Prozessen bereitgehalten). Oder aber es wird ein neuer Thread erzeugt.

Fehlersemantik

Im Falle eines Fehlers (z. B. Kommunikationsfehler beim Versenden des Requests bzw. des Ergebnisses, oder Ausfall eines Netzwerkknotens) können implementierungsabhängig keine Ergebnisse empfangen werden, genau ein Ergebnis oder viele Ergebnisse. Hierzu können die folgenden "Fehlersemantiken" auf der Seite des Clients ausgewählt werden: maybe, at-least-once, exactly-once und at-most-once.

Falls Fehler auftreten, kann dann je nach spezifizierter Fehlersemantik das Folgende passieren:

(Falls keine Fehler auftreten, garantieren alle Semantiken die einmalige Ausführung der Prozedur.)

Typ	Ein Request wird im Fehlerfall ...	Filterung empfangener Duplikate
maybe	... nicht noch einmal verschickt.	keine Behandlung
at-least-Once	... noch einmal verschickt.	nein	Die entfernte Prozedur wird bei einem empfangenen Duplikat wiederholt ausgeführt (nur empfehlenswert für idempotente Operationen).
exactly-once	... noch einmal verschickt.	ja	Falls ein Duplikat empfangen wird, so wird ein bereits verschicktes Ergebnis wiederholt verschickt.
at-most-once	... noch einmal verschickt.	ja	und es wird weder die entfernte Prozedur erneut ausgeführt, noch wird ein bereits verschicktes Ergebnis wiederholt verschickt.

Generell gilt jedoch: Es kann keinerlei Garantie gegeben werden. Denn falls z. B. ein Netzwerk-Knoten dauerhaft ausfällt, ist in jedem Fall auch keine einzige Ausführung möglich.