Remote Procedure Call

Der RPC ist ein Protokoll, das die Implementierung verteilter Anwendungen - also Netzwerkdienste - vereinfachen soll. Ursprünglich von der Firma Xerox entwickelt, haben sich heute drei Standards etabliert:

• ONC: Open Network Computing (SUN...)



• NCA: Network Computing Architecture (HP...)



• DCE: Distributed Computing Environment (OSF)

Wie der Name schon verdeutlicht, handelt es sich um eine Dienstleistung, die auf einem entfernten Rechner erbracht wird. Im Unterschied zu lokalen Prozeduraufrufen ergeben sich daraus zahlreiche Probleme:

• Welcher Host bietet einen entsprechenden Dienst an?



• Welches Transportprotokoll (TCP/UDP) soll verwendet werden?



• Was ist bei Ausfall des Dienstanbieters (Server)?



• Semantik des Aufrufs (genau, höchstens oder mindestens einmal)



• Datendarstellung (Wortbreite, big endian, little endian)



• Performance



• Sicherheit

Nun soll hier keine Diskussion über die Grundlagen des RPC erfolgen, dennoch sei das Prinzip eines entfernten Prozeduraufrufs in folgender Abbildung kurz verdeutlicht.

Bei einem lokalen Prozeduraufruf werden die Parameter über den Stack übergeben. Das Prinzip versagt aber im Falle des RPC, deshalb werden nun die Parameter versendet, zusammen mit der gewünschten Programmnummer, der entsprechenden Version und der jeweiligen Prozedurnummer u.a. Stellt sich nun die Frage: An wen schicke ich das Paket? Die Wahl eines entsprechenden Servers kann auf mehreren Wegen erfolgen. So kann in einer lokalen Datei eine entsprechende Server-Adresse vermerkt sein oder es kommt ein per Multicast oder Broadcast arbeitendes Protokoll zum Einsatz.

Kennt der Client die genaue Portnummer des Dienstanbieters nicht, sendet er eine Anfrage an Port 111 des Server-Rechners, wo der so genannte Portmapper wartet.

Jeder auf dem Serverrechner aktive RPC-Server hat sich zuvor beim Portmapper registrieren lassen. Dieser kennt nun die genauen Fähigkeiten der einzelnen Server und kann - falls der Dienst von einem Prozess erbracht wird - auf die Anfrage mit der korrekten Portnummer antworten und der Client wird seine Aufgaben nun direkt an diesen Port übermitteln (Abbildung).

Die in den weiteren Abschnitten beschriebenen Netzwerkdienste greifen auf RPC-Dienste zurück, so dass der Portmapper vor dem Start der jeweiligen Dienste gestartet werden muss!

Ist der Portmapper noch nicht aktiv, sollte er durch Eintrag in die jeweiligen Runlevel bereits beim Systemstart installiert werden. Bei SuSE nennt sich das entsprechende Skript /sbin/init.d/rpc. Bei RedHat heißt es /etc/rc.d/init.d/portmap. Das Vorgehen beim Anlegen der Links ist analog zur Beschreibung zum inetd.