Protokoll höherer Ebene

Das Netzwerk wirft besondere Probleme auf, wenn ein hohes Maß an Interaktion zwischen dem Benutzer und einem bestimmten Subsystem in einem fremden Host erforderlich ist. Diese Probleme entstehen durch heterogene Konsolen, den Overhead lokaler Betriebssysteme und Netzwerkübertragungsverzögerungen. Wenn wir keine speziellen Strategien anwenden, kann es für einen fernen Benutzer schwierig oder sogar unmöglich sein, die angebotenen ausgefeilteren Subsysteme zu nutzen. Während diese Schwierigkeiten im Bereich der Grafik besonders gravierend sind, können selbst bei der Fernschreiberinteraktion Probleme auftreten. Angenommen, ein fremdes Subsystem ist für über Telefon verbundene Fernschreiberkonsolen ausgelegt, und dieses Subsystem wird dann für Netzwerkbenutzer verfügbar. Dieses Subsystem könnte die folgenden Eigenschaften haben.

1. Abgesehen vom Echo und der Korrektur von Tippfehlern wird keine Aktion ausgeführt, bis ein Wagenrücklauf eingetippt wird.
2. Alle Zeichen außer "^" und "<-" und Wagenrückläufen werden beim Eintippen des Zeichens als Echo ausgegeben.
3. <- bewirkt das Löschen des unmittelbar vorangehenden Zeichens und wird als dieses Zeichen als Echo ausgegeben.
4. ^ bewirkt, dass alle zuvor eingetippten Zeichen ignoriert werden. Ein Wagenrücklauf und ein Zeilenvorschub werden als Echo ausgegeben.
5. Ein Wagenrücklauf wird als Wagenrücklauf gefolgt von einem Zeilenvorschub als Echo ausgegeben.

Wenn jedes eingetippte Zeichen in seiner eigenen Nachricht gesendet wird, dann verursachen die Zeichen

H E L L O <- <- P c.r.

neun Nachrichten in jede Richtung. Darüber hinaus wird jedes Zeichen von einem Programm auf Benutzerebene im lokalen Host behandelt, bevor es an den fremden Host gesendet wird.

Nun ist klar, dass wir, wenn dieses spezielle Beispiel wichtig wäre, schnell die Regeln 1 bis 5 in einem lokalen Host-Programm implementieren und nur vollständige Zeilen an den fremden Host senden würden. Wenn das fremde Host-Programm nicht so geändert werden könnte, dass es keine Echos erzeugt, dann könnte das lokale Programm nicht nur korrekt echoen, sondern auch die späteren Echos vom fremden Host verwerfen. Das Problem ist jedoch nicht irgendein bestimmtes Interaktionsschema; das Problem ist, dass wir erwarten, dass viele solcher Schemata auftreten werden. Wir haben keine allgemeinen Lösungen für diese Probleme gefunden, aber einige Beobachtungen und Vermutungen könnten den Weg weisen.

Hinsichtlich heterogener Konsolen stellen wir fest, dass Konsolen zwar selten kompatibel sind, viele aber äquivalent. Es ist wahrscheinlich vernünftig, einen Fernschreiber vom Modell 37 als Äquivalent eines IBM 2741 zu behandeln. Ebenso werden die meisten Speicher-Scopes eine Äquivalenzklasse bilden und die meisten Refresh-Display-Scopes eine weitere. Darüber hinaus könnte eine Hierarchie entstehen, bei der Mitglieder einer Klasse anstelle derjenigen einer anderen verwendet werden können, aber nicht umgekehrt. Wir können uns vorstellen, dass jedes Scope ein adäquater Ersatz für einen Fernschreiber sein könnte, aber kaum umgekehrt. Diese Beobachtung lässt uns fragen, ob eine netzwerkweite Sprache für Konsolen möglich wäre. Eine solche Sprache würde eine unterschiedliche Behandlung verschiedener Klassen von Konsolen mit für jede Klasse geeigneter Semantik vorsehen. Jeder Standort könnte dann Schnittstellenprogramme für seine Konsolen schreiben, um sie wie netzwerkstandardisierte Geräte erscheinen zu lassen.

Eine weitere Beobachtung ist, dass ein Benutzer ein interaktives System bewertet, indem er die Geschwindigkeit der Antworten des Systems mit seinen eigenen Erwartungen vergleicht. Manchmal hat ein Benutzer das Gefühl, nur eine geringfügige Anforderung gestellt zu haben, sodass die Antwort unmittelbar erfolgen sollte; zu anderen Zeiten hat er das Gefühl, eine substanzielle Anforderung gestellt zu haben, und ist daher bereit, auf die Antwort zu warten. Manche interaktiven Subsysteme sind besonders angenehm zu benutzen, weil viel Arbeit darauf verwendet wurde, die Antworten auf die Erwartungen des Benutzers zuzuschneiden. Im Netzwerk jedoch tritt ein lokaler Prozess auf Benutzerebene zwischen eine lokale Konsole und ein fremdes Subsystem, und wir müssen damit rechnen, dass sich die Antwortzeit für geringfügige Anforderungen verschlechtert. Nun kann es vorkommen, dass diese ganze Anpassung der Interaktion ziemlich unabhängig von dem Teil des Subsystems ist, der die schwere Rechen- oder E/A-Arbeit leistet. In einem solchen Fall könnte es möglich sein, ein Subsystem in zwei Abschnitte zu unterteilen. Ein Abschnitt wäre ein "Frontend", das die Ausgabe an den Benutzer formatiert, seine Eingabe annimmt und rechnerisch einfache Antworten wie Echos steuert. Im obigen Beispiel wäre das Programm zum Ansammeln einer Zeile und Erzeugen von Echos das Frontend eines Subsystems. Wir nehmen nun die Tatsache zur Kenntnis, dass die lokalen Hosts über beträchtliche Rechenleistung verfügen, aber unsere derzeitigen Entwürfe nutzen den lokalen Host nur als Datenkonzentrator. Das ist in gewisser Weise ironisch, denn der lokale Host wird nicht nur als Datenkonzentrator schlecht genutzt, sondern verschlechtert auch die Leistung wegen der von ihm eingeführten Verzögerungen.

Diese Argumente haben uns dazu veranlasst, die Möglichkeit einer Network Interface Language (NIL) in Betracht zu ziehen, die eine netzwerkweite Sprache zum Schreiben des Frontends interaktiver Subsysteme wäre. Diese Sprache hätte die Eigenschaft, dass Unterprogramme über netzwerkähnliche Verbindungen kommunizieren. Die Strategie besteht dann darin, den Quellcode für das Frontend eines Subsystems zum lokalen Host zu transportieren, wo er kompiliert und ausgeführt würde.

In vorläufigen Diskussionen haben wir uns darauf verständigt, dass NIL mindestens die folgenden semantischen Eigenschaften haben sollte, die in anderen Sprachen im Allgemeinen nicht zu finden sind.

1. Nebenläufigkeit. Weil Nachrichten asynchron auf verschiedenen Verbindungen eintreffen und weil die Benutzereingabe nicht mit der Ausgabe des Subsystems synchronisiert ist, muss NIL Semantik enthalten, um die möglichen Nebenläufigkeiten präzise zu modellieren.
2. Programmverkettung. Es ist sehr nützlich, ein Programm zwischen zwei andere Programme einfügen zu können. Um dies zu erreichen, würde die Zusammenschaltung von Programmen zur Laufzeit festgelegt und wäre nicht implizit im Quellcode enthalten.
3. Gerätesubstituierbarkeit. Üblicherweise werden Sprachen so definiert, dass ein Gerät durch ein anderes ersetzt werden kann. Die Anforderung hier ist, dass jedes Gerät durch ein NIL-Programm modelliert werden kann. Wenn beispielsweise ein netzwerkstandardisierter Anzeige-Controller Baumstrukturen gemäß den an ihn gesendeten Nachrichten manipuliert, dann müssen diese Strukturen in NIL leicht implementierbar sein.

NIL ist nicht vollständig spezifiziert, und es wurden Vorbehalte hinsichtlich seines Nutzens geäußert. Diese Vorbehalte hängen von unserer Vermutung ab, dass es möglich ist, ein interaktives System in ein transportables Frontend, das die Erwartungen eines Benutzers mit geringem Aufwand erfüllt, und einen substanzielleren ortsgebundenen Abschnitt zu unterteilen. Wenn unsere Vermutung falsch ist, dann wird NIL nicht nützlich sein; andernfalls scheint es sich zu lohnen, sie weiterzuverfolgen. Die Prüfung dieser Vermutung und die Weiterentwicklung von NIL werden Priorität haben, nachdem das HOST-HOST-Protokoll auf niedriger Ebene stabilisiert ist.