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.
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.
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:
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.
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.
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.
Der Fernzugriff auf räumlich entfernte Computersysteme ist seit jeher ein wichtiger Bestandteil gut organisierter Netzwerke. Administratoren verwalten und betreuen auf diese Weise die einzelnen Teilnehmer, und auch das Arbeiten von unterwegs kann durch die Möglichkeit des Remote-Zugriffs auf Firmendaten erheblich verbessert werden. Telnet ist eines der ersten Protokolle, das speziell zu diesem...
In den Zeiten von Großrechnern und ersten kleineren Netzwerken waren Terminals ein entscheidender Baustein für eine gemeinsame Nutzung von Hardware- und Software-Ressourcen. Dass Terminalserver – die zentrale Verwaltungsinstanz derartiger Netzwerke – auch noch Jahrzehnte später gefragt sind, wenn Applikationen mehreren Usern zur Verfügung gestellt werden sollen, kommt nicht von ungefähr.
Viele Unternehmen haben komplexe Serverinfrastrukturen, die oft von mehreren Administratoren betreut werden. Nicht nur die jeweiligen Betriebssysteme, sondern sämtliche Software-Pakete gilt es, zu installieren, konfigurieren und auf dem neuesten Stand zu halten. Mit SaltStack lassen sich alle Ressourcen von einem zentralen Rechner aus steuern. Wir zeigen Ihnen, was SaltStack kann und wo die...
Ist der RPC-Server nicht verfügbar, wird Windows-Nutzern der Fehlercode 0x800706BA angezeigt. Die Netzwerkkommunikation zwischen Client und Server ist dann gestört. Das Problem tritt relativ häufig unter Windows 10 auf. Was genau es mit dem RPC-Server auf sich hat und wie Sie den Fehler selbst ohne umfassendes Netzwerkwissen beheben können, erklären wir Ihnen hier.
Remote Procedure Calls nehmen schon länger eine Schlüsselrolle bei der intermaschinellen Kommunikation in Client-Server-Architekturen ein. Seit einigen Jahren gibt es mit gRPC einen würdigen Nachfolger, der mit besonders leistungsfähigen Strategien den gestiegenen Anforderungen von globaler Vernetzung und umfassender Digitalisierung Rechnung trägt.
Nur für kurze Zeit: So erhalten Sie zwei Gratis-Domains!
Kaufen Sie eine .de-Domain und erhalten Sie eine .com und .info Domain gratis dazu.
Sie empfehlen unsere Produkte über unseren Partner Aklamio weiter. Wir bedanken uns mit einer Geldprämie.
Weiterempfehlen
Professionell: 100% werbefrei