Ein anpassbarer Mechanismus

Wir möchten Problemprogramme an die Netzwerknutzung anpassen – Programme, die nicht mit Blick auf das Netzwerk geplant wurden und die sich zweifellos nicht ohne Weiteres den Netzwerkstandards fügen werden, die zum Zeitpunkt ihrer Einbeziehung bestanden. Dieses Inkompatibilitätsproblem ist ein ebenso grundlegender Teil der dem Netzwerk zugrunde liegenden Forschung wie unterschiedliche Host-Hardware. Umfangreiche Front-Ends für jedes solche Programm zu verlangen, ist kein vernünftiges Ziel. Wir betrachten das Netzwerk als eine Verschmelzung aus a) Hosts, die Dienste bereitstellen; b) parasitären Hosts, die Terminals an die Dienste anbinden, und c) einem Spektrum von Hosts, die sich sowohl als Benutzer als auch als Anbieter von Diensten verhalten. Zu verlangen, dass jeder parasitäre Host unterschiedliche Protokolle und Datenformate für alle Dienste handhabt, die seine Benutzer benötigen, ist kein vernünftiges Ziel. Das Ergebnis sind Programme und Terminals, die kommunizieren möchten, aber nicht dieselbe Sprache sprechen.

Ein Ansatz für die Probleme mit Protokollen und Datenformaten besteht darin, einen anpassbaren Mechanismus bereitzustellen, den Programme und Terminals nutzen können, um leicht auf Netzwerkressourcen zuzugreifen. ARPA fördert das Adaptive Communicator Project bei Rand, eine Forschungsanstrengung zur Untersuchung eines lehrbaren Front-End-Prozesses, der den Menschen an das Programm anbindet. Die Vielfalt der untersuchten Endgeräte umfasst Sprache, Tablets, hochentwickelte Grafikterminals usw.

Der Adaptive Communicator sieht sehr vielversprechend aus, wird aber noch einige Zeit nicht verfügbar sein. Das Network Project bei Rand entschied sich für den anpassbaren Ansatz (nicht adaptiv, d. h. keine Heuristiken, kein Selbstlernen). Unser Problem besteht darin, die Forscher von Rand leicht ins Netzwerk zu bringen, wobei wir annehmen, dass sie unterschiedliche gleichzeitige Anwendungen haben, die unterschiedliche Programmprotokolle und Datenkonfigurationen erfordern.

Protokolle und Datenformate werden getrennt beschrieben, um zu veranschaulichen, was wir unter Anpassung verstehen. Protokolle sind Folgen von „Systemaufrufen“, die NCP-Befehlen entsprechen (und dazu führen, dass der NCP sie ausgibt). Datenformate sind die Beschreibungen regulärer Nachrichteninhalte und sind für einen NCP nicht von Bedeutung.

Die Form Machine (Anpassung an Datenformate)

Um dem Leser den Zusammenhang zu verdeutlichen: Die Form Machine gehört zur Klasse der endlichen Automaten, die eine Form von reguläre Ausdrücke_ erkennen, die in unserem Fall Datenformate beschreiben. Die Notation ist jedoch auf bestimmte Beschreibungen ausgerichtet und kann daher für unsere Zwecke knapper sein als die Sprache regulärer Ausdrücke.

Die Form Machine ist ein experimentelles Softwarepaket, das eine Vielzahl von Programmen und Terminals koppelt, deren Anforderungen an Datenformate unterschiedlich sind. Wir stellen uns Form Machines vor, die (zur Verringerung des Netzwerkverkehrs) bei verschiedenen Dienste bereitstellenden Hosts angesiedelt sind.

Um die Idee der Form Machine zu erproben, implementieren wir zwei von IBM OS aufrufbare Unterprogramme; einen Compiler, der Anweisungen kompiliert, die Formen von Datenformaten beschreiben; und einen Ausführer, der eine kompilierte Form auf einen Datenstrom anwendet.

Um den Test der Form Machine zu beschreiben, ist es notwendig, ein weiteres Programm bei Rand zu erwähnen – das Network Services Program (NSP), ein Mehrfachzugriffsprogramm, das das Network Control Program sowohl mit beliebigen Programmen als auch mit Video Graphics Consoles verbindet. (Wir betrachten ein Terminal als einfach ein weiteres Programm mit einer anderen Schnittstelle, d. h. # Zeichen/Zeile, # Zeilen/Seite, besondere Hardwaremerkmale, die Anwendung, für die es eingesetzt wird usw.) Die Unterprogramme der Form Machine sind von NSP auf Konsolen- oder Programmanweisung aufrufbar.

Operativ benennt und spezifiziert ein Konsolenbenutzer die Datenformen, die er verwenden wird. Die Formen werden kompiliert und für die spätere Verwendung gespeichert. Zu einem späteren Zeitpunkt, wenn der Benutzer Netzwerkverbindungen aufbauen und Daten übertragen möchte, ordnet er benannte Formen dynamisch jeder Seite eines Ports zu – einer symbolisch benannten Vollduplexverbindung des Netzwerks. Eingehende oder ausgehende Datenströme werden gemäß der kompilierten Form ausgeführt, und der transformierte Datenstrom wird dann an die Konsole bzw. das Programm oder an das Netzwerk weitergegeben.

Die Einzelheiten der Syntax unserer Form-Machine-Notation sind für die Netzwerkgemeinschaft als Ganzes unwichtig. Die Möglichkeiten der Notation sind jedoch von Interesse. Sie wird schließlich die Beschreibung von Hochleistungs-CRT-Anzeigen, TTY und beliebigen Dateistrukturen umfassen. Um ihre Tauglichkeit zu erproben, wird eine Teilmenge solcher Merkmale implementiert.

Die derzeitige Version ist durch die folgenden Merkmale gekennzeichnet:

1. Zeichencodeübersetzung (d. h. dezimal, oktal, hexadezimal, 8-Bit-ASCII, 7-Bit-ASCII, EBCDIC und binär).

2. Mehrere Abbruchzeichenketten (viele Terminals haben mehrere Abbruchsignale).

3. Einfügen von Literalen (hauptsächlich zur Darstellung von Anzeigeinformationen verwendet).

4. Überspringen oder Löschen beliebiger Zeichenketten (verwendet, um Satzfolgenummern usw. zu entfernen, die nicht angezeigt werden sollen).

5. Erzeugung von Satzfolgenummern.

6. Berechnung und Einfügen der Zeichenkettenlänge.

7. Beliebige Angaben zur Länge von Datenzeichenketten, z. B. „eine hexadezimale Literalzeichenkette, gefolgt von einer beliebigen Anzahl von EBCDIC-Zeichen, gefolgt von einer Abbruchzeichenkette, .....“.

8. Verkettung von Netzwerknachrichten, d. h. die Ausführung kompilierter Formen auf unvollständigen Datenzeichenketten.

9. Transposition von Datenfeldern.

10. Sowohl explizite als auch unbestimmte Vervielfachungsfaktoren für ein- und mehrzeilige Nachrichten.

Merkmale, die nicht implementiert werden, aber bei Erfolg hinzugefügt werden, umfassen:

1. Grafikorientierte Beschreibungen.

2. Allgemeine Zahlenübersetzungen.

3. Bedingte Anweisungen.

4. Eine Zeigerfähigkeit.

Der Protocol Manager (Anpassung an NCP-Befehlssequenzen)

Der NSP erlaubt Terminalbenutzern und Programmen, auf der Protokollebene des NCP zu arbeiten; d. h. LISTEN, INIT u. a. Er erlaubt ihnen außerdem, Informationen zu übertragen und aufzubereiten, die nur für sie selbst von Bedeutung sind. Dieser „praxisnahe“ Ansatz ist aus Sicht des Systemprogrammierers oder der Erkundung wünschenswert. Es ist jedoch wünschenswert, das mühsame „Handshaking“ für den Forscher zu beseitigen, der ein bestimmtes entferntes Programm wiederholt nutzt, indem man ihm erlaubt, „vorgefertigte“ Protokollfolgen zu definieren, zu speichern, abzurufen und auszuführen.

Wir spezifizieren derzeit einen Protocol Manager als Modul des NSP, der die obigen Operationen auf NCP-Befehlsssequenzen ermöglichen wird. Merkmale des Moduls sind:

1. Die Folgen können „Haltepunkte“ enthalten, damit der Konsolenbenutzer dynamisch alle kontextuell benötigten Informationen einfügen kann.

2. Die Parameter eines Befehls können Token enthalten, deren Werte von der Gegenstelle während des Protokolldialogs geliefert werden. Zum Beispiel ist in Note #66 die vom Server bereitgestellte Socket-Nummer vom Benutzer in nachfolgenden RTS-, STR-Befehlen zu verwenden.