Remote Procedure Call

remote procedure call (RPC, auf deutsch in etwa: „Aufruf einer fernen Prozedur“) bzw. Prozedurfernaufruf 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 weiterhin drei inkompatible Versionen von RPC unterscheiden, das ONC RPC, das vielfach auch als Sun RPC bezeichnet wird, ist die am weitesten verbreitete RPC Variante. ONC RPC steht hierbei für Open Network Computing Remote Procedure Call, 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. Die letzte Variante schließlich ist ein gescheiterter Versuch der ISO ein standardisiertes ISO RPC zu etablieren, von ISO RPC gibt es bis heute jedoch kaum eine Implementierung.

Die wichtigste Komponente auf der Serverseite ist der Portmapper-Daemon, der auf dem UDP- und TCP-Port 111 lauscht. Der Portmapper übernimmt die Koordination der durch den Client gewünschten Funktionsaufrufe. Jedes Programm, das auf dem Server RPC-Dienste zur Verfügung stellen will, muss daher dem Portmapper bekannt sein.

Neben NFS basiert unter anderem noch Network Information Service (NIS) in weiten Teilen auf RPC-Aufrufen.

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 angekommen, 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 Directory Service. (Der Directory Service 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 (leichtgewichtiger Prozess, der innerhalb eines schwergewichtigen Prozesses aktiv ist und dort seinen Adressraum mit anderen Threads teilt).

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.)

maybe: Eine Request-Nachricht wird im Fehlerfalle nicht noch einmal verschickt.

at-least-Once: Ein Request wird im Fehlerfalle gegebenenfalls noch einmal verschickt. Empfangene Duplikate werden nicht gefiltert. Die entfernte Prozedur wird bei einem empfangenen Duplikat wiederholt ausgeführt (nur empfehlenswert für idempotente Operationen).

exactly-once: Ein Request wird im Fehlerfalle gegebenenfalls noch einmal verschickt. Empfangene Duplikate werden jedoch gefiltert. Falls ein Duplikat empfangen wird, so wird ein bereits verschicktes Ergebnis wiederholt verschickt.

at-most-once: Ein Request wird im Fehlerfalle gegebenenfalls noch einmal verschickt. Empfangene Duplikate werden jedoch gefiltert, 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.

Siehe auch

Representational State Transfer

Weblinks

RFC 1057 – RPC: Remote Procedure Call Protocol Specification, Version 2
RFC 1831 – RPC: Remote Procedure Call Protocol Specification Version 2

Netzwerkprotokoll auf Anwendungsschicht

Gourt Home::Gourt :: Remote Procedure Call

Ablauf

Fehlersemantik

Siehe auch

Weblinks