Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Aufruf entfernter Prozeduren (Remote Procedure Call)

Remote Procedure Call (RPC) stellt Client/Server-Anwendungen grundlegende Mechanismen zur Verfügung. Es wurde von Sun Microsystems entwickelt und ist eine Sammlung von Tools und Bibliotheksfunktionen. Wichtige Anwendungen, die auf RPC basieren, sind NFS, das Network File System (beschrieben in Kapitel 14 Das Network File System), und NIS, das Network Information System (beschrieben in Kapitel 13 Das Network Information System).

Ein RPC-Server besteht aus einer Reihe von Prozeduren, die ein Client aufrufen kann, indem er eine RPC-Anforderung zusammen mit den Prozedurparametern an den Server schickt. Der Server führt die gewählte Prozedur im Namen des Client aus und liefert das Ergebniszurück, wenn es eines gibt. Um maschinenunabhängig zu sein, werden alle zwischen dem Client und dem Server ausgetauschten Daten vom Sender in das sogenannte XDR-Format (External Data Representation) umgewandelt und vom Empfänger wieder in die lokale Repräsentation der Maschine zurückgewandelt. RPC benutzt Standard-UDP- und -TCP-Sockets, um die XDR-formatierten Daten zum Remote-Host zu übertragen. Sun hat RPC großzügigerweise in die Public Domain freigegeben. Es wird in einer Reihe von RFCs beschrieben.

Manchmal führen Verbesserungen an einer RPC-Anwendung zu inkompatiblen Veränderungen in der Schnittstelle der Prozeduraufrufe. Natürlich würde ein einfacher Austausch des Servers alle Anwendungen zum Absturz bringen, die noch das ursprüngliche Verhalten erwarten. Deshalb werden RPC-Programmen Versionsnummern zugewiesen, die normalerweise bei 1 beginnen und mit jeder neuen RPC-Version erhöht werden. Häufig kann ein Server mehrere Versionen gleichzeitig anbieten. Die Clients geben dann in ihren Anforderungen durch die Versionsnummer an, welche Implementierung des Dienstes sie benutzen wollen.

Die Kommunikation zwischen RPC-Servern und -Clients ist etwas eigenartig. Ein RPC-Server bietet eine oder mehrere Sammlungen von Prozeduren an; jede Sammlung wird als Programm bezeichnet und durch eine Programmnummer eindeutig identifiziert. Eine Liste, die Service-Namen auf Programmnummern abbildet, wird für gewöhnlich in der Datei /etc/rpc gespeichert. Ein Ausschnitt davon ist in Tabelle 12.4 gezeigt.

Beispiel 12.4: Ausschnitt aus /etc/rpc

# # /etc/rpc - verschiedene RPC-basierte Dienste # portmapper      100000  portmap sunrpc rstatd          100001  rstat rstat_svc rup perfmeter rusersd         100002  rusers nfs             100003  nfsprog ypserv          100004  ypprog mountd          100005  mount showmount ypbind          100007 walld           100008  rwall shutdown yppasswdd       100009  yppasswd bootparam       100026 ypupdated       100028  ypupdate

In TCP/IP-Netzwerken wurden die Autoren von RPC mit dem Problem konfrontiert, Programmnummern auf allgemeine Netzwerkdienste abzubilden. Sie gestalteten jeden Server so, daß er für jedes Programm und jede Version sowohl einen TCP- als auch einen UDP-Port bereitstellt. Im allgemeinen verwenden RPC-Anwendungen UDP, um Daten zu übertragen, und greifen nur dann auf TCP zurück, wenn die zu übertragenden Daten nicht in ein einzelnes UDP-Datagramm passen.

Natürlich müssen Client-Programme eine Möglichkeit haben herauszufinden, auf welchen Port eine Programmnummer abgebildet wird. Die Verwendung einer Konfigurationsdatei wäre für diesen Zweck zu unflexibel. Da RPC-Anwendungen keine reservierten Ports verwenden, gibt es keine Garantie, daß ein ursprünglich von unserer Datenbankanwendung zu benutzender Port nicht von einem anderen Prozeß besetzt wurde. Darum nimmt eine RPC-Anwendung irgendeinen Port, den sie kriegen kann, und registriert ihn mit einem speziellen Programm, dem sogenannten Portmapper-Dämon. Der Portmapper fungiert als Dienstvermittler für alle RPC-Server, die auf dieser Maschine laufen. Ein Client, der einen Dienst mit einer gegebenen Programmnummer kontaktieren möchte, fragt zuerst den Portmapper auf dem Host des Servers ab, der dann die TCP- und UDP-Portnummern zurückliefert, über die der Dienst erreicht werden kann.

Diese Methode hat den Nachteil, daß sie – genau wie inetd für die normalen Berkeley-Dienste – einen “single point of failure” darstellt. Nur ist dieser Fall sogar noch schlimmer, weil alle RPC-Port-Informationen verlorengehen, wenn der Portmapper seinen Geist aufgibt. Das bedeutet üblicherweise, daß Sie alle RPC-Server manuell neu starten oder sogar die gesamte Maschine neu hochfahren müssen.

Bei Linux wird der Portmapper /sbin/portmap oder manchmal auch /usr/sbin/rpc.portmap genannt. Sie müssen lediglich sicherstellen, daß er von einem Ihrer Boot-Skripten aus gestartet wird. Ansonsten braucht der Portmapper nicht konfiguriert zu werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center