Remote Procedure Call

Xerox Courier RPC

Auf der Ebene der „Hosts”, der komplexen Installationen, die Deinste und Anwendungen für den Mehrbenutzerbetrieb anbieten, und der „Workstations”, der (hervorragend ausgestatteten) interaktiven Computersysteme, mit denen lokale Systementwicklung verrichtet werden (im Gegensatz zu den „Terminals”, die nur Sichten auf entfernte Anwendungen ermöglichen) entstanden zwei Probleme:

Erstens, das Problem der Ausnutzung von Kapazitäten in verteilten, heterogenen Systemen. Ein „Host” sollte (idealerweise) sowohl mit Mainframe-Architekturen kommunizieren können, als auch mit den verschiedenen Netzwerktechnologien Applikationsdienste (insbesondere Rechenleistung und Speicherplatz) für das stetig wachsende Segement der „Personal Computer” sowie für (in den 1980er Jahren hauptsächlich mit UNIX ausgestatteten) „Workstations” anbieten können.

Zweitens, das Problem der Zusammenarbeit von Anwendungen in einer zunehmend heterogenen Landschaft aus Host- und Workstation-Betriebssystemen.

Die Frage stellte sich also, wie ein Client, der auf Betriebssystem X compiliert worden war, transparent auf Dienste eines Servers zugreifen konnte, der für Betriebssystem Y compiliert worden war.

Am Xerox Palo Alto Research Center (Xerox PARC) wurden vorherige Arbeiten mithilfe der Programmiersprache „Mesa” zum System des „Remote Procedure Call”, „RPC” generalisiert. Ein programmatischer Lösungsansatz wurde vorgeschlagen und als Entwicklungsumgebung für das Xerox Network System, XNS angeboten. Dabei war Courier RPC ursprünglich eine Beispielanwendung für das (proprietäre) XNS und wurde als Public Domain angeboten (vergleiche [XNSCOURIER], Abbildung „12-1. XNS Protocols”).

Damit wurde Courier RPC für spätere RPC-Implementationen und Network Operating Systems bzw. Distributed Computing Systems (siehe unten) wenn nicht zur Codebasis so doch zu einem massgeblichen Einflussgeber (vergleiche [WPDERPCHIST], [IETFONC]).

In Courier RPC war „Distribution Transparency” erklärtes Ziel. So etwas wie eine spezielle Beschreibungssprache für Interfaces sollte es nicht geben, ein Scanner (Präprozessor) sollte aus dem Quellcode erkennen, welche Aufrufe nicht-lokal und welche lokal sind (vgl. [JBACDS], Abschnitt „Integration of Programming Languages and RPC (1)”). Das Problem bei diesem Ansatz ist, dass sich damit die Programmiersprache ändert (ändert man z.B. den C-Präprozessor, dann weist die Programmiersprache, die das C-Programmiersystem anbietet, ein anderes Verhalten auf).

ONC RPC

Auf Systemen mit GNU LIBC (insbesondere GNU/Linux) ist auch heute das von Sun Microsystems, Inc. zuerst entwickelte und anschliessend in Zusammenarbeit mit AT&T vermarktete „Open Network Computing Remote Procedure Call”, ONC RPC die im Lieferumfang enthaltene RPC-Implementation. Dabei handelt es sich eigentlich um einen Teil der Architektur „Open Network Computing” (ONC), die wiederum ein Marketingbegriff für den Entwicklungsaufwand rund um das „Network File System”, „NFS” ist. Sein ursprünglicher Name, der heute noch zuweilen verwendet wird, ist „Sun RPC” (zitat einfügen!).

[CSFAQ39] bezeichnet ONC etwas allgemeiner als:

„[...] architecture, with third party alliances providing the missing pieces.”

BSD Version 4.3 führte auf Basis von ONC RPC den Dämon „portmap” ein (siehe [BSD43PM]), der eine Vielzahl von RPC-Anfragen den betroffenen Dienstprogrammen zuordnen sollte.

ONC RPC etablierte sich zu einer integrierten Umgebung aus Daemons und Werkzeugen, die via UDP/IP solche Dienste wie NFS sowie Network Information Service bzw. „Yellow Pages” (NIS-YP) implementierten.

[HAUTPNFS] beschreibt den historischen Verlauf der Entwicklung von NFS auf der Grundlage von ONC RPC. Im Abschnitt „1990s” schreibt der Autor:

„Sun Microsystems and the Internet Society (ISOC) reached an agreement to cede „change control” of ONC RPC so that ISOC's engineering-standards body, the Internet Engineering Task Force (IETF), could publish standards documents (RFCs) documenting the ONC RPC protocols and could extend ONC RPC.„

TI-RPC

Sun hat im Jahr 2000 eine Implementation genannt „Transport Independent RPC”, „TI-RPC” und unter der „Sun Industry Standards Source License” als Quellcode im Interet vertrieben[tircp] (siehe auch [TIRPC], desweiteren [DEBPM] für ein Beispiel einer Distribution von GNU/Linux, deren „portmap”-Implementation nach eigenen Angaben TI-RPC reimplementiert), die den „Requests for Comments” [RFC1057] (korrigierte Fassung des 2 Monate früher erschienenen RFC 1050) und [RFC1831] (Änderungen und Neuerungen[oncrpc]) entsprechen sollen.

ONC RPC und „portmap” bilden heute noch die Grundlage für NFS (bis Version 3) und NIS+. Desweiteren hat SGI mit dem „File Alteration Monitor” (FAM) eine NFS-kompatible, portable Dateizustands-Überwachung entwickelt([rpc]). NFS ab Version 4 soll (zur Einfacheren Anpassung auf IPv6, vgl. BULLNFS4, Abschnitt „General architecture”) TI-RPC verwenden.

Leider scheint die Iplementation von Bull kein „rpcgen” zu enthalten.

DCE/RPC

Als Alternative, die (zumindest zeitweilig) in offenem Wettbewerb mit ONC RPC stand[dceonc], ist DCE/RPC, an dessen Entwicklung (nebst anderen) die Apollo Computer, Inc., die Hewlett-Packard, Inc. (diese sind 1989 fusioniert, siehe auch [WPAPOLLO]) und später auch IBM, Inc. beteiligt waren. „DCE/*” sagt aus, dass es sich um die Komponente „RPC” im „Distributed Computing Environment”, „DCE” handelt, dieses sollte wiederum auf dem Betriebssystem OSF/1 installiert werden (vgl. [USENETDCE]). Tatsächlich war DCE unter anderem ein Konkurrenzprodukt zu ONC ([HAUTPNFS]). Die „Open Software Foundation” (mitbegründet von HP, Inc., zwischenzeitlich aufgegangen in der „Open Group” wurde zum Träger der Vermarktung von DCE (siehe [OGDCE]).

DCE verwendet sein RPC-System zur Implementation von systemweiten Diensten, dazu gehören der „Cell Directory Server”, der „Security Server” und der „Distributed Time Server” (Quelle: [WPENDCE]). Diese Dienste sollten bekannte Probleme bei ONC vermeiden, bzw. mehr Funktionsumfang „out-of-the-box” anbieten. Mit DFS wurde ein im Netzwerk replizierendes Dateisystem als Alternative zu NFS einführt.

Zwar wurde DCE von vielen Host-Betreibern interessiert aufgenommen (vgl. z.B. [HUDCE]). Bis zum heutigen Tag ist das Gesamtsystem DCE jedoch nicht standardisiert und nicht frei zugänglich dokumentiert (vergleiche [OGDCEDOC]). Die Open Group bietet zwischenzeitlich allerdings frei dokumentierte Programmierschnittstelle zur Erstellung eigener RPC-Anwendungen an (siehe [OGRPCDOC]). Erst seit 2005 wird die DCE von der Open Group unter der Lizenz LGPL vertrieben (siehe [OGDCEFREE])[dcefree].

DCE/RPC ist auf verschiedenen proprietären UNIX-Varianten verfügbar (HP-UX, IRIX und AIX), doch zumindest IBM propagiert für AIX heute die Migration von DFS nach NFS ([IBMDCEMIG]), und die anderen UNIX-Varianten haben stark an Bedeutung verloren.

Microsoft RPC

Der interne Protokollwirrwarr bei Microsoft steht dem bei allen anderen Herstellern zusammengenommen in nichts nach, so dass man fast meinen möchte, die Firma wolle eine Art „Gegenuniversum” erschaffen. Tatsächlich erweisen sich die funktionstüchtigen Anteile ihres Portfolios als geschickt zusammengekauft.

Ein Bericht über die Anfänge der Implementation von RPC für „Windows” von Microsoft, Inc. vor dem Hintergrund der Auseinandersetzung zwischen ONC (Sun und AT&T) und DCE (Apollo/HP, IBM, DEC und andere) findet sich in [GANMSRPC]. Microsoft entschied sich zur Lizensierung von DCE/RPC und implementierte einen Transport über SMB Named Pipes (um die Abhängigkeit von IP zu lösen). Die daraus resultierende Implementation wird als „MSRPC” bezeichnet, in der Benutzerschnittstelle von „Windows” lediglich als „RPC”.

DCE/RPC bildete dabei die Grundlage. DCE/RPC überträgt ohne Codeänderungen Werte in Host-Byte-Order (im Fall des IBM-PC ist dies Little-Endian), wenn beide Gegensetlle dieselbe Byte-Order verwenden (im Gegensatz zu ONC RPC, das gemäss XDR immer in Network-Byte-Order üebträgt, also Big-Endian). Dies wirkte sich im Einsatz in reinen Windows-Netzwerken natürlich als Vereinfachung aus.

Der Einsatz von RPC in MS Windows ist vielfälötig (vgl. z.B. [HSCMSRPC]). Auch auf Anwendungsebene kommt RPC zum Einsatz, insbeosndere beim Exchange Groupware Server (vgl. [MSKB163576]).

Weiter zu Kapitel 4: Mittlere und kleine Netzwerke