Wichtiger Hinweis: ich werde derzeit in Google unheimlich hochgeranked, weil ich offenbar z.B. so ziemlich der eninzige bin, der aktuell was über TI-RPC und Windows gleichzeitig schreibt (und das veröffentlicht), Ich bitte die Unvollständigkeit des Dokumentes, zu dem Sie hiermit gelangt sind, zu entschuldigen. Ich betreibe diese Dokumentenstruktur als Materialsammlung, um herauszufinden, welches RPC ich selbst verwenden will, um OS-übergreifendes RPC (im Sinne des Erfinders) zu betreiben. Recht viel Mühe habe ich mir bei den Quellenangaben gegeben, diese können Sie ja als Linksammlung auffassen. Viel Spass und danke für Ihr Verständnis (falls Sie welches haben).

Zum Übergeordneten Indexdokument

Zum Indexdokument

Weiter zu Kapitel 2: Netzwerkverbände

Einleitung und Übersicht

Vorbemerkung

Ich habe diesen Artikel hauptsächlich auf Internet-Quellen gestützt erstellt. Ich würde gerne Quellen bevorzugen, die einen „normativen Charakter” haben, insbesondere Requests for Comments (RFCs) der Internet Engineering Task-Force (IETF). Leider ist auch deren Erstellungsprozess Gegenstand marktwirtschaftlicher Verwerfungen, wie ich versuche, anhand des Beispiels von RPC für UNIX aufzuzeigen.

Die Ausführungen über den geschichtlichen Hintergrund, die ich in diesem ersten Kapitel von mir gebe, sind im Übrigen Spekulation darüber, wie es sich verhalten haben könnte. Ich war ja nicht dabei. Ich kann nur lesen, was ich finde, mir Gedanken dazu machen und versuchen, ein Gesamtbild daraus herzuleiten. Was ich natürlich versucht habe, ist, den Wahrheitsgehalt zu prüfen, wobei ich insbesondere Wert darauf gelegt habe, Nachweise für Schlüsselbehauptungen aus möglichst vielen, von einander unabhängigen Quellen zu beziehen. Trotzdem bleibt die Wahrheit hinter den Darstellungen beim besten Willen oft nur Andeutung.

Ich distanziere mich in diesem Dokument von der Bemühung, den Prozess der Softwareentwicklung zu „modellieren”. Wenn ich schreibe, dass die Fragestellung der entfernten Aufrufe „ab einem gewissen Organisationsgrad fast zwangläufig auftritt”, und es dabei belasse, dann ist das Absicht. Es soll nicht Ziel dieses Artikels sein, sich oder den Leser mit theoretischen Erwägungen über Softwareentwicklung zu beschäftigen. Dieser Artikel soll das Verständnis über die Zusammenhänge in einer Branche fördern, die wirklich existiert, nicht denen in einer, die optimalerweise oder nach den Vorstellungen irgendwelcher Beteiligter (einschliesslich mir) existieren sollte oder könnte. Dahinter steht jedoch (bei weitem) nicht die Ablehnung der Theorie der Softwareentwicklung an sich.

Grundidee von RPC

Ein Problem bzw. eine Fragestellung, die unter anderem in der Programmierung von Anwendungen in Netzwerken ab einem gewissen Grad der Organisation fast zwangsläufig auftritt, ist das der „Prozeduraufrufe in entfernten Kontexten[kontext]”.

Im englischen Fachjargon ist diese Aufgabenstellung als Remote Procedure Call (RPC) bekannt. Ich werde die geschichtlichen Hintergründe der Entwicklung von RPC darzustellen versuchen.

Es gibt eine ganze Reihe von „Implementationen” von RPC, von denen ich einige der weit verbreiteten aufzählen werde.


Weiter zu Kapitel 2: Netzwerkverbände


Tilman Kranz, 21.1.2009.