Zum Hauptinhalt springen

Einleitung

Es gibt viele gute Gründe, und vielleicht ein oder zwei schlechte, dafür, es so erscheinen zu lassen, als sei die Kommunikation über das Network nur ein Sonderfall der Ein-/Ausgabe – jedenfalls soweit es die Benutzerprogrammierung betrifft. So behandelt etwa der Harvard-Ansatz zur Implementierung des HOST-HOST-Protokolls und des Network Control Program jede Verbindung als ein „logisches Gerät“ in der PDP-10-Terminologie. Das Einrichten einer Verbindung ähnelt der lokalen Gerätezuweisung, und die Kommunikation über eine Verbindung wird die standardmäßigen Ein-/Ausgabe-UUOs des Systems nutzen. Dadurch ist es möglich, bestehende Programme zusammen mit dem Network ohne Änderung zu verwenden – jedenfalls, wenn es sich um andere PDP-10-Anlagen handelt.

Doch das bringt uns nur bis zu einem gewissen Punkt. Den Begriff eines „logischen Geräts“ gibt es auf der PDP-10 nicht; auf der IBM 360 gibt es ihn (ich spreche hier von der Ebene der Schnittstelle zwischen Betriebssystem und Benutzerprogramm). Weiterhin müssen, solange es keinen Network-Standard gibt, der feste Darstellungen für ganze Zahlen, Gleitkommazahlen usw. verlangt (was ich ablehnen würde), je zwei Benutzerprozesse zu einer lokalen Vereinbarung gelangen, und einer von beiden oder beide müssen die Last der Datenkonvertierung auf sich nehmen, wo sie nötig ist. Jedes Standardprotokoll sollte es erlauben, solchen Vereinbarungen Ausdruck zu verleihen, und sollte zumindest das Minimum an Steuerinformationen bereitstellen, das solche Vereinbarungen in der Praxis funktionieren lässt. Schließlich müssen wir festhalten, dass die IMP-IMP- und HOST-HOST-Protokolle keine Prüfung vorsehen, ob eine von einem Benutzerprozess angeforderte Aktion tatsächlich von den anderen Prozessen ausgeführt wird; diese Art von Frage wurde stets als auf der Ebene des BENUTZER-BENUTZER-Protokolls behandelbar angesehen.

Dieser Vorschlag soll sich den obigen drei Arten von Fragen nur bis zu einem gewissen Grad stellen. Am besten kann ich diesen Grad erklären, indem ich die Kriterien nenne, nach denen ich jeden Vorschlag für ein BENUTZER-BENUTZER-Protokoll beurteilen würde:

  1. Der Begriff eines (logischen) Satzes sollte vorhanden sein, und der Begriff einer Nachricht sollte unterdrückt werden. (Für einen FORTRAN-Programmierer ist das, was mit einer einzigen WRITE-Anweisung ohne begleitendes FORMAT geschrieben wird, ein Satz; für einen OS/360-Maschinensprachenprogrammierer schreibt PUT einen Satz.)

  2. Es sollte möglich sein, das Protokoll so in HOST-Systemen und/oder Bibliotheksroutinen zu implementieren, dass heute bestehende Benutzerprogramme ohne Programmänderung auf Dateien überall im Network zugreifen können. (Zumindest anfangs muss diese Fähigkeit auf HOST-Systeme desselben Typs beschränkt bleiben.)

  3. Das Protokoll sollte in jedem HOST-System auf der SVC- oder UUO-Ebene implementierbar sein (nicht notwendigerweise implementiert). Spezifische Kenntnis der Eigenschaften des jeweils anderen HOST sollte unnötig sein.

Es sei angemerkt, dass das Obige impliziert, dass einige Benutzerprogramme sich der Natur des anderen HOST bewusst sein müssen – jedenfalls in jedem Fall, in dem das zweite Kriterium versagt. Während wir in den Fällen, in denen das Versagen heute auftritt, Fortschritte machen (oder sie aufgeben), wird sich die Last des Ausgleichs von Systemunterschieden hin zur Implementierung in Protokollen (d. h. den HOST-Systemen) oder, ersatzweise, in Benutzerprogrammen verschieben.

Ganz offensichtlich sollte jeder heute initiierte Vorschlag hinsichtlich des Ausmaßes, in dem er endgültige Probleme „löst“, mit Skepsis betrachtet werden. Wie ehrgeizig man sein sollte, ist rein eine Frage des Geschmacks. In diesem Stadium ziehe ich es vor, etwas zu versuchen, von dem ich glaube, dass es von uns allen genutzt werden kann (und es daher wert ist, getan zu werden), das uns ein gutes Stück bei der Lösung unserer kurzfristigen Probleme voranbringt, das leicht zu tun ist und das Aussicht auf langfristige Lebensfähigkeit bietet. Im Folgenden beabsichtige ich, den Vorschlag selbst zu beschreiben, hoffentlich mit angemessenen motivierenden Argumenten für seine Bestandteile. Danach werde ich die konkrete Implementierung skizzieren, die wir in Harvard für die PDP-10 erstellen, und beschreiben, wie wir sie im konkreten Fall der Speicherung von Dateien auf anderen PDP-10-Anlagen im Network anzuwenden gedenken.