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.
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:
- Der Client-Code ruft eine Stub-Prozedur auf (lokaler Client-Stub).
- 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.
- 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 oder UDP/IP nutzt.
- 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).
- Der Server-Stub übergibt die dekodierten Parameter und sorgt damit für den lokalen Aufruf einer Server-Prozedur.
- Der daraus resultierende Funktionswert wird an den Server-Stub kommuniziert.
- 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.
Cloud Computing und Computercluster – Einsatzgebiete von RPC-Calls
RPC-Calls werden heute in vielen Bereichen eingesetzt. Sie dienen als Baustein von Webservices (z. B. in Form des Protokolls 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-Dienste, Bank- und Buchungssysteme in der Reisebranche sowie Datenbanken. Weitere Einsatzgebiete sind Computer-Cluster (High-Availability-Cluster), dezentrale Peer-to-Peer-Netzwerke sowie Blockchains (beispielsweise von Kryptowährungen), die häufig ebenfalls mit der RPC-Technik arbeiten.
Remote Procedure Calls sind zudem essentiell für heutige Betriebssysteme. 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 usw.).
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.