RPC ist ein Kommunikationsverfahren, mit dem ein Client eine Prozedur auf einem entfernten Server anfordert und anschließend ein Ergebnis zurückerhält.
Ein Remote Procedure Call, kurz RPC, abstrahiert die Netzwerkkommunikation zwischen einem Client und einem entfernten Server. Aus Sicht des aufrufenden Programms ähnelt der Vorgang einem lokalen Funktionsaufruf. Tatsächlich müssen Anfrage, Parameter und Ergebnis jedoch über ein Netzwerk übertragen werden.
Das Verfahren wurde für verteilte Systeme eingesetzt und unter anderem im Umfeld des Network File System (NFS) bekannt. RPC beschreibt dabei ein Protokoll zur strukturierten Anforderung entfernter Funktionen.
Wie läuft ein RPC-Aufruf ab?
Ein Server stellt definierte Dienste bereit. Diese sind als Prozeduren implementiert und lassen sich über Angaben wie Serveradresse, Programmkennung und Prozedurkennung auswählen. Der Client formuliert daraus eine Anfrage.
- Prozedur auswählen
Der Client bestimmt den entfernten Dienst und die aufzurufende Funktion.
- Parameter serialisieren
Die Eingabewerte werden in ein transportierbares Format überführt, weil Client und Server getrennte Adressräume besitzen.
- Anfrage übertragen
Die kodierte Nachricht wird über das Netzwerk an den zuständigen Server gesendet.
- Prozedur ausführen
Der Server verarbeitet die Anfrage lokal und führt die angeforderte Funktion aus.
- Ergebnis zurückgeben
Rückgabewerte oder Fehlerangaben werden kodiert und an den Client übermittelt.
Die Umwandlung der Parameter ist wesentlich: Unterschiedliche Systeme können Datentypen und Byte-Reihenfolgen verschieden darstellen. Eine definierte Kodierung sorgt dafür, dass beide Seiten die übertragenen Werte eindeutig interpretieren.
Kommunikation über UDP oder TCP
RPC kann je nach Ausprägung auf dem UDP-Protokoll oder dem TCP-Protokoll aufsetzen. Die Wahl beeinflusst unter anderem Verbindungsaufbau, Zustellung und den Umgang mit Wiederholungen.
RPC über UDP
UDP arbeitet verbindungslos. Die RPC-Implementierung muss mögliche Verluste, Wiederholungen oder Zeitüberschreitungen angemessen behandeln.
RPC über TCP
TCP stellt einen geordneten Datenstrom bereit. Nachrichtenbegrenzung und Fehlerbehandlung auf Anwendungsebene bleiben dennoch relevant.
Anfragen, Antworten und Fehlerfälle
Nach einer RPC-Anfrage führt der Server die zugeordnete lokale Prozedur aus. Danach sendet er die Antwort zurück und kann weitere Anforderungen verarbeiten. Für den Client endet ein Aufruf mit einem Ergebnis, einer protokollspezifischen Fehlermeldung oder einer Zeitüberschreitung.
Ein verteilter Aufruf ist nicht vollständig mit einem lokalen Funktionsaufruf gleichzusetzen. Netzunterbrechungen können beispielsweise dazu führen, dass unklar bleibt, ob eine Anfrage den Server erreicht oder ob eine Antwort lediglich verloren ging. Anwendungen sollten deshalb Wiederholungen und mehrfach ausgeführte Operationen berücksichtigen.
Autorisierung und Zugriffskontrolle
Ein RPC-Endpunkt darf nicht allein aufgrund seiner Erreichbarkeit nutzbar sein. Server müssen den aufrufenden Client beziehungsweise dessen Kontext prüfen und festlegen, welche Prozeduren und Ressourcen verwendet werden dürfen. Diese Autorisierung sollte nach dem Prinzip der minimal erforderlichen Rechte erfolgen.
Die konkrete Absicherung hängt von der RPC-Implementierung und der Betriebsumgebung ab. Dazu zählen die Identitätsprüfung, eine geschützte Übertragung, sorgfältig validierte Parameter sowie eine kontrollierte Freigabe erreichbarer Dienste.
Standardisierung und Einordnung
Das klassische ONC-RPC-Verfahren wurde durch die IETF dokumentiert. Die ursprüngliche Beschreibung in RFC 1831 wurde später technisch fortgeschrieben. Der Grundgedanke prägt weiterhin viele Formen der Kommunikation in verteilten Anwendungen: Ein klar beschriebener Aufruf wird übertragen, entfernt ausgeführt und mit einer strukturierten Antwort abgeschlossen.