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

Zurück zu Kapitel 1: Einleitung

Weiter zu Kapitel 3: Remote Procedure Call

Netzwerkverbände

Frühe Computer-Netzwerke

Tatsächlich gab es bereits in den späten 1950er Jahren in den USA ein landesweites Netzwerk aus vernetzten Grossrechnern, das „Semi-Automatic Ground Environment”, „SAGE” ([]). Betrachtet man SAGE weniger als Rüstungs- denn als Forschungsprojekt, so waren seine wesentlichen Resultate:

Weder Computer noch Netzwerke sollten streng zweckgebunden sein (SAGE war praktisch bei seiner Einführung technisch überholt). Universalrechner und Vielzweck-Netzwerkprotokolle wurden zu erstrebenswerten Zielen.

Eine landesweite Netz-Infrastruktur sollte schrittweise wachsen und ausbaufähig sein. Die Topologie sollte nicht fest vergeben sein.

Die Finanzierung sollte nicht allein vom Staat getragen werden (auch, weil dessen Mittel durch SAGE belastet und durch Wettrüstung und „Space Race” gebunden wurden). Entwicklungen sollten bedarfsorientiert teils vom Staat und teils von der Industrie gefördert werden.

Die Entwicklung sollte nicht von einer einzigen Firma übernommen werden. IBM, Inc. nahm die phänomenalen Einnahmen aus SAGE, entwickelte für geschätzte 5 Milliarden US-Dollar „System 360”[IBMSYS360], wurde damit zum Marktführer und verkaufte es wiederum u.a. an den Staat, für den Staat ein deutliches Minusgeschäft (vgl. auch die Bemerkung in [ARPATAYLOR], Abschnitt ”Das ARPANet„, Absatz 2 Ende).

Die Rationalität der technischen Entwicklung sollte durch eine Vielzahl von Beteiligten und durch offene Standardisierungsprozesse (den „Peer Review”, der zu den „Requests for Comment”, „RFC„ führte) sichergestellt werden. Dieses Verfahren sollte gleichzeitig die Netzwerktechnologie so dokumentieren, dass ausserinstitutionelle, private und fremdstaatliche Netzwerke integriert werden konnten (dies war das Leitmotiv des „Internet Program”)

Diesen Designkriterien folgte DARPANET; (später ARPANET;, siehe [ARPANET]). Projekte, die diese Lehren nicht beachteten (z.B. CYCLADES, AUTODIN II, siehe [ARPAKAHN]), konnten sich nicht halten.

Mit dem Aufkommen des „Time-Sharing” richteten Betriebe Fernzugriff ihrer Terminals zu Mainframes ein. Zwischen grösseren privaten Rechenzentren (z.B. von Handel, Banken und Versicherungen oder internationalen Konzernen) wurden „Standleitungen” mit einer Infrastruktur mit „Circuit-Switching” (klassische Telefonverbindung) oder den moderneren „Virtual Circuits” (z.B. auf Basis von X.25, siehe [X25], für Time-Sharing auf Mainframe-Architekturen, vgl. [WPENTYMNET]) eingerichtet. Das fortgeschrittene „Packet-Switching” kam zuerst für verteilte Transaktionssysteme zum Einsatz (vgl. [SITANET], [NETTMSHR], Absatz 7f).

Interoperation und Daten-Assoziation

Interoperabilität und Ansteuerbarkeit entfernter Rechnerressourcen war ein frühes Ziel in ARPANET. Besim Karadeniz schreibt in [ARPATAYLOR] über den ehemaligen Leiter der IPTO, Bob Taylor:

”[Bob] Taylor war durch und durch ein Computerfreak und besaß in seinem Büro drei Terminals, die mit Großrechnern verbunden waren. Ihn störte es immens, dass jeder Großrechner eine eigene, zu einem anderen System gänzlich inkompatible, Sprache besaß. Zudem kam die Problematik auf, dass immer mehr Forschungseinrichtungen Computerressourcen benötigten. [...]„

Nicht nur in der Steuerung von Rechenvorgängen sondern auch bei der Datenhaltung zeigte sich im Rahmen der zunehmenden Vernetzung das Problem der Heterogenität. So wurde das französische Forschungsnetzwerk CYCLADES (experimentell) dazu eingesetzt, Datenbanken der französischen Institutionen miteinander abzugleichen[paris].

Louis Pouzin bemerkt in [POUZIN98]:

„[...] The data bases were everything at the time -there and each one had it's own format. Cyclades was to carry out the intercorrection and contribute to avoi[d] the inconsistencies. [...]”

Etablierung der Computernetzwerke

Ab Mitte der 70er Jahren kam es zu Entwicklungen, die vernetze Datenhaltung auch ausserhalb der grossen „Campus-artigen” Netzwerke sowohl machbar als auch gewinnbringend werden liessen.

Die Entwicklung dezentraler lokaler Bus-/Protokoll-Kombinationen (z.B. DECNET, siehe [CISCODEC], [ARCNET]) als Gegensatz zur hierarchischen Mainframe-Technologie (insbesondere IBMs „System Network Architecture”, siehe [CISCOSNA], aber auch Dumb-Terminal-orientierte WAN-Protokolle (wie X.25)) oder den reinen Forschungsnetzwerken förderte den Austausch zwischen verschiedenen Datenbanken (statt des entfernten Zugriffs auf ein- und dieselbe Datenbank, wie in der Mainframe-Systemarchitektur üblich).

Die Verbindung von „UNIX”, einem Betriebssystem für Minicomputer mit Compiler- und Interpretersprache und starkem akademischen Anklang mit der TCP/IP-Technologie des ARPANET (beschrieben in [ESR2003]) ist ein Beispiel für eine starke Ausrichtung eines Computer-Betriebssystems auf den Netzwerkbetrieb. „Netzwerk-Programmierung” konnte sich so auch als akademische Disziplin etablieren.

Weiter zu Kapitel 3: Remote Procedure Call


Tilman Kranz, 21.1.2009.