# Remote Procedure Call (RPC) – effiziente Kommunikation in Client-Server-Architekturen

Der Remote Procedure Call (dt. „Aufruf einer fernen Prozedur“) ist ein zentrales Instrument, um operative und arbeitsteilige Strukturen in Netzwerken und **Client-Server-Architekturen** zu realisieren. Wie die Zusammenarbeit zwischen räumlich getrennten Rechnern via RPC-Call funktioniert, auf welchen Ebenen sie stattfindet und wo man RPC-Konzepte heute einsetzt, wird im Folgenden erklärt.

## Was ist ein Remote Procedure Call (RPC)?

Der Begriff Remote Procedure Call – deutsch: „**Aufruf einer fernen Prozedur**“ – bezeichnet ein Konzept, das die **Interprozesskommunikation**, also den Informationsaustausch zwischen Systemprozessen, regelt. 1984 definierten die Informatiker Andrew Birrell und Bruce Nelson RPC als einen synchronen Mechanismus, „der Kontrollfluss und Daten als Prozeduraufruf zwischen zwei Adressräumen über ein schmalbandiges Netz transferiert“. Durch das Überschreiten eines Adressraums können Prozesse auf einem entfernten Rechner im Netzwerk gestartet und externe Instanzen operativ in Berechnungs- und Datenverarbeitungsprozesse einbezogen werden. Zum Kommunikationsprozess via RPC gehören die **Übergabe von Parametern** und die **Rückgabe eines Funktionswertes**. Häufig bleibt es nicht bei einem Aufruf, da in der Praxis oft mehrere Anfragen parallel abgewickelt werden.

Letztlich strebt das RPC-Konzept eine **Angleichung der Verarbeitungsebenen** an: Für Programmierer und Anwender sollte es im Idealfall keinen Unterschied machen, um welchen Prozeduraufruf es sich handelt. Aufrufe aus der Ferne sollen also prinzipiell genauso leicht realisierbar sein wie lokale Prozeduraufrufe (Transparenzprinzip). RPC-Calls stehen in Netzwerken und Client-Server-Architekturen für eine **auftragsorientierte bidirektionale Kommunikation**. Sie ergänzen die rein nachrichtenbasierte Kommunikation, die dem Paradigma der Ein- und Ausgabe (Verwendung von I/O-Funktionen) folgt.

Hinweis Das Spezialgebiet von RPC-Calls ist die Kommunikation zwischen verschiedenen Computern, sie können aber auch innerhalb eines zusammenhängenden Systems zur Kommunikation zwischen verschiedenen Prozessen beitragen.

## Client-Stub meets Server-Stub – so funktioniert RPC

RPC-Calls **laufen immer nach einem bestimmten Muster ab**: Ein Client kontaktiert z. B. bei der Suche nach einem Ersatzteil einen zentralen Datenbankserver. Der entfernt liegende Server überprüft daraufhin den Datenbestand und sendet das Ergebnis an den Client zurück. Letzterer verarbeitet die erhaltenen Daten und zeigt z. B. eine Liste mit den Bestandsdaten in einer Verwaltungssoftware an.

An der Implementierung eines Remote Procedure Calls sind auf Sender- und Empfängerseite spezielle Instanzen beteiligt, die als Stubs (dt. „*Stummel“*) bezeichnet werden. Der **Client-Stub** agiert auf der Client-Seite als Stellvertreter der entfernten Server-Prozedur. Der **Server-Stub** ist der serverseitige Stellvertreter des aufrufenden Client-Codes. Die Stubs simulieren operativ eine funktionale lokale Einheit, indem sie das „Entferntsein“ des Codes auf der jeweils anderen Seite kaschieren. Zugleich fungieren sie als Prozedur-Schnittstellen. Der typische Ablauf eines RPC-Calls zeichnet sich durch folgende Schritte aus:

1. Der Client-Code ruft eine **Stub-Prozedur** auf (lokaler Client-Stub).
2. Der Client-Stub generiert aus den übergebenen Parametern des Prozeduraufrufs eine sendefähige Nachricht, die sich an das RPC-Protokoll hält. Bei dem Transfer findet eine **Serialisierung** statt, bei der strukturierte Daten in eine sequenzielle Darstellungsform überführt werden. Dieser Übersetzungsvorgang wird auch als Marshalling (von engl. „to marshal“, dt. „*aufstellen*“, „*ordnen*“) bezeichnet.
3. Der Client-Stub kontaktiert danach das Kommunikationssystem des lokalen Computers, das für den anschließenden Nachrichtenaustausch zwischen Client und Server häufig wahlweise [TCP/IP](https://www.ionos.de/digitalguide/server/knowhow/tcpip-vorgestellt/) oder [UDP/IP](https://www.ionos.de/digitalguide/server/knowhow/udp-user-datagram-protocol/) nutzt.
4. Nach Ankunft der gesendeten Nachricht beim Empfänger vollzieht der Server-Stub das sogenannte **De- bzw. Unmarshalling**, indem er die in der Nachricht enthaltenen Parameter wieder entpackt (auf Basis des RPC-Protokolls).
5. Der Server-Stub übergibt die dekodierten Parameter und sorgt damit für den **lokalen Aufruf einer Server-Prozedur**.
6. Der daraus resultierende **Funktionswert** wird an den Server-Stub kommuniziert.
7. Nun vollzieht sich der **Ablauf in umgekehrter Richtung**: Generierung einer sendefähigen Nachricht gemäß RPC-Protokoll, Nachrichtenaustausch zwischen Server und Client, dann wird der Rückgabewert zum wartenden Client-Code transportiert. Die Anwendung auf dem Ursprungsrechner wird fortsetzt.

[![Bild: Grafische Darstellung der Remote-Procedure-Call-Technik](https://www.ionos.de/digitalguide/fileadmin/_processed_/b/6/csm_remote-procedure-call-funktionsweise_faa4e857b2.webp "Grafische Darstellung der Remote-Procedure-Call-Technik")](https://www.ionos.de/digitalguide/fileadmin/DigitalGuide/Schaubilder/remote-procedure-call-funktionsweise.jpg) Grafische Darstellung der Remote-Procedure-Call-Technik ## Cloud Computing und Computercluster – Einsatzgebiete von RPC-Calls

RPC-Calls werden heute in vielen Bereichen eingesetzt. Sie dienen als Baustein von [Webservices](https://www.ionos.de/digitalguide/websites/web-entwicklung/webservice/ "Webservice") (z. B. in Form des Protokolls [XML-RPC](https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-xml-rpc/ "Was ist XML-RPC?") für entfernte Funktionsaufrufe via HTTP) und ermöglichen verteilte Anwendungen (Distributed Applications), bei denen sich verschiedene Rechenmaschinen vorhandene Ressourcen und anfallende Aufgaben teilen. Unter anderem zählen hierzu [Cloud-Computing](https://www.ionos.de/digitalguide/server/knowhow/cloud-computing-definition-erklaerung-geschichte/ "Cloud Computing | Definition, Erklärung, Geschichte")-Dienste, Bank- und Buchungssysteme in der Reisebranche sowie [Datenbanken](https://www.ionos.de/digitalguide/hosting/hosting-technik/datenbanken/ "Datenbanken"). Weitere Einsatzgebiete sind **Computer-Cluster** (High-Availability-Cluster), dezentrale **Peer-to-Peer-Netzwerke** sowie [Blockchains](https://www.ionos.de/digitalguide/online-marketing/verkaufen-im-internet/blockchain/ "Blockchain") (beispielsweise von Kryptowährungen), die häufig ebenfalls mit der RPC-Technik arbeiten.

Remote Procedure Calls sind zudem essentiell für heutige [Betriebssysteme](https://www.ionos.de/digitalguide/server/knowhow/was-ist-ein-betriebssystem/ "Was ist ein Betriebssystem?"). Windows erledigt mit ihrer Hilfe zum Beispiel viele Routinen, die permanent anfallen. So nutzen etwa der Faxdienst, die Druckerwarteschlange oder eingerichtete Netzwerkverbindungen einen Systemdienst, der in deutschsprachigen Systemversionen als **„Remoteprozeduraufruf“** bezeichnet wird.

In der Unix- und Linux-Welt spielt das von Sun Microsystems entwickelte **Network File System (NFS)** eine wichtige Rolle. Es verwendet RPC-Calls zwischen Clients und Servern, um etwa das Dateisystem eines entfernten Rechners teilweise oder komplett auf einem lokalen Computer zu mounten, also verfügbar zu machen. Durch das Verfahren kann der User mit einzelnen Dateien eines Remote-Computers so umgehen, als ob sie sich auf seinem eigenen Rechner befinden. Definierte Dateiberechtigungen regeln dann die Lese- und Schreibrechte. Auch das **Network Information System (NIS)** nutzt RPC und verwaltet damit zentral UNIX- und Linux-Systeme.

## Was sind die Vorteile von RPC?

Das RPC-Protokoll wickelt die Interprozesskommunikation zuverlässig ab und benötigt dabei relativ geringe Verarbeitungszeiten. Die Programmierung von Kommunikationsprozessen räumlich entfernter Computer wird erheblich erleichtert, da z. B. keine Rücksicht auf komplexe Details des jeweils verwendeten Netzwerks genommen werden muss. Zudem erlaubt das RPC-Konzept eine konsequente **Modularisierung**. Prozesse lassen sich auslagern, einzelne Computer werden dadurch entlastet. Netzwerke und verteilte Systeme können durch Arbeitsteilung effizienter arbeiten, indem für besondere Aufgaben spezialisierte Plattformen eingesetzt werden (z. B. Datenbankserver). Dabei können die beteiligten Protagonisten weltweit vernetzt sein. Weitere Vorzüge sind die hervorragende **Skalierbarkeit** der realisierten Client-Server-Architekturen sowie die Möglichkeit, unkompliziert cloudbasiert arbeiten zu können.

## Was sind die Nachteile von RPC?

Zu den Nachteilen der RPC-Technik zählt der Umstand, dass es **keinen einheitlichen Standard** für RPC-Calls gibt. Die unterschiedlichen – meist firmenspezifischen – Umsetzungen (z. B. ONC-RPC von Sun) sind untereinander normalerweise nicht kompatibel. Zudem bringen die Transfer- und Übermittlungsebenen RPC-basierter Systeme gewisse **Geschwindigkeitseinbußen** mit sich, was bei rein lokalen Prozeduraufrufen nicht der Fall ist. Da Client und Server für ihre jeweiligen Routinen unterschiedliche Ausführungsumgebungen nutzen, wird auch die **Verwendung von Ressourcen** (z. B. Dateien) aufwendiger. RPC-Systeme sind daher für die Übergabe großer Datenmengen nicht so gut geeignet.

Durch die Aufteilung auf verschiedene Verarbeitungsinstanzen wird die **Fehleranfälligkeit** erhöht. Nachrichten können in der Kommunikation verlorengehen (Netzwerkfehler, Ausfall eines Knotens im Netzwerk), es kann zu Verzögerungen und Abbrüchen kommen. **Timing-Probleme**, redundante Doppelausführungen (z. B. von Prozessaufrufen) oder unerwünschte Asynchronitäten in der Maschinenkommunikation zählen zu den daraus resultierenden Komplikationen. Beim synchronen RPC kann ein Serverproblem (z. B. Crash) den Client beeinträchtigen, wenn der aufrufende Prozess vergeblich auf den Rückgabewert wartet. Andererseits wird der **Server ausgebremst**, wenn die Antwort des Clients zeitverzögert bzw. gar nicht bei ihm ankommt. Diese Fehleranfälligkeit kann sich gerade in umfangreichen und hochgradig arbeitsteiligen Architekturen weitreichend auswirken.

Aufgrund möglicher Fehlerquellen muss außerdem eine spezielle **RPC-Fehlersemantik** berücksichtigt werden, was die Programmierung verhältnismäßig aufwendig macht. Programmierer und Systementwickler müssen sich mit den Sicherheitsaspekten auseinandersetzen, die verteilte Systeme und ihre Kommunikation via RPC und UDP/IP bzw. TCP/IP mit sich bringen (Netzwerksicherheit, Hacking, [Denial-of-Service-Angriffe](https://www.ionos.de/digitalguide/server/knowhow/dos-und-ddos-angriffsmuster-im-ueberblick/) usw.).

Hinweis Einige Probleme, die aus einer generellen Synchronität von Client und Server resultieren, können mit **asynchronen RPC-Konzepten** gelöst werden. Bei dem Verfahren muss der Client nicht zwingend auf eine Antwort vom Server warten. Er darf den Programmfluss fortsetzen und nach einem Call noch andere Operationen ausführen. Die Rückmeldung des Servers wird dann zu einem späteren Zeitpunkt vom Client verarbeitet. Die spezielle Programmierung asynchroner RPC-Calls ist allerdings sehr komplex und aufwendig.


This is a markdown version of: [https://www.ionos.de/digitalguide/server/knowhow/was-ist-ein-remote-procedure-call/](https://www.ionos.de/digitalguide/server/knowhow/was-ist-ein-remote-procedure-call/) for AI/LLM consumption.