2. Einige Designprobleme
2A. Grundannahme
Die Funktion des Telnet-Prozesses besteht darin, dass ein Terminal am Benutzer-Standort über das Netz logisch äquivalent zu einem „direkt" mit dem Server-Standort verbundenen Terminal erscheint. Diese Grundfunktion hat eine Reihe von Implikationen.
i) Der Benutzer sollte die Erzeugung aller Codes veranlassen können, die ein Terminal des Serversystems erzeugen kann. Hinsichtlich des Network Information Center und einiger anderer Standorte erscheint es eine vernünftige Anforderung, Tastaturkonventionen so zu gestalten, dass der Benutzer alle 128 ASCII-Zeichencodes als Eingabe in das Netz erzeugen kann. Andere Standorte mit anderen Zeichencodes benötigen möglicherweise einen Telnet-Prozess, der diese Codes dem Netz zur Verfügung stellt.
ii) Der Benutzer sollte zu seinem lokalen System zurück escapen (escape) können oder aus dem Server-Prozess in das Serversystem escapen können.
iii) Die Telnets zeilenweise (line-at-a-time) arbeitender Systeme sollten mit zeichenweise (character-at-a-time) und zeilenweise arbeitenden Systemen zusammenarbeiten können, und die Telnets zeichenweise arbeitender Systeme sollten mit zeilenweise und zeichenweise arbeitenden Systemen zusammenarbeiten können.
2B. Echo-Kontrolle
Wir verwenden den Begriff Echo-Kontrolle (echo control) statt der Begriffe Halbduplex (half duplex) oder Vollduplex (full duplex), da die Telnet-Verbindung hinsichtlich der Netzwerkübertragungen in Wirklichkeit Vollduplex ist. Drei Terminalfälle sind zu betrachten.
- Fall 1 - Zeichenweise, Server-Standort gibt das Echo
- Fall 2 - Zeichenweise, Benutzer-Standort gibt das Echo
- Fall 3 - Zeilenweise, Benutzer-Standort gibt das Echo
Manche Server-Standorte sind möglicherweise in der Lage, mit allen drei Fällen zu arbeiten, und es ist eine Konvention erforderlich, den Modus festzulegen. Streng genommen ist es nicht Sache des Server-Standorts, welche Zeichen bei welchen Tastenschlägen ausgegeben werden, obwohl man versuchen möchte, die Unterschiede im Schriftbild, wie es dem Benutzer erscheint, möglichst gering zu halten.
2C. Formatsteuerzeichen
Die Formatsteuerzeichen, nämlich horizontaler Tabulator (HT), vertikaler Tabulator (VT), Seitenvorschub (FF), Zeilenvorschub (LF) und Wagenrücklauf (CR), müssen in den obigen Fällen 2 und 3 einheitlich behandelt werden. Beim obigen Fall 1 ist die Situation einfacher.
2D. Netzwerknachrichtengrenzen
Das NCP-zu-NCP-Protokoll wurde mit dem Ziel festgelegt, dass die Nachrichtengrenzen des Netzes für die Benutzerprozesse unsichtbar bleiben. Es wäre gut, wenn dieses Ziel aufrechterhalten werden könnte, aber bei einigen zeilenweise arbeitenden Systemen könnte dies schwierig sein.
2E. Eine Implementierungskonvention
Wenn wir annehmen, dass der von einem Telnet-Prozess empfangene Zeichenstrom vom Server-Standort an jener Stelle in den Server-Monitor eingespeist wird, an der die Zeicheneingabe „direkt" angeschlossener Terminals eingespeist wird, und dass die Ausgabe des Server-Prozesses an der Stelle des Monitors eingespeist wird, an der die normale Zeichenausgabe eingespeist wird, dann lassen sich die Konventionen zur Lösung der obigen Probleme am einfachsten etablieren. Das Server-NCP empfängt seine Eingabe an der Stelle, an der die normale Zeichenausgabe des Monitors entnommen wird. Mit anderen Worten: Der Server-Prozess würde seine Eingabe aus den Zeichenpuffern des Server-Monitors beziehen und seine Ausgabe an diese Puffer senden, statt die Eingabe direkt aus den NCP-Puffern zu beziehen oder in die NCP-Puffer auszugeben.
Der Telnet-Prozess hingegen würde die Zeichenströme direkt von oder zu seinem lokalen NCP empfangen und senden.
Es existieren auch Situationen, in denen die Benutzerprozesse an beiden Enden direkt mit dem NCP kommunizieren. Daher würden wir empfehlen, dass für die Kommunikation zwischen dem NCP und einem Benutzerprozess beide Verbindungsmodi (Benutzerprozess-Monitor-NCP oder Benutzerprozess-NCP) verfügbar sind. Diese Modi würden vom Benutzerprozess unter Programmsteuerung festgelegt. Die anfängliche Netzkonvention während des Anmeldevorgangs und bis zu einer Änderung durch den Server-Prozess wäre, Zeichen vom Monitor zu empfangen und Zeichen an den Monitor zu senden. Das Server-NCP kommuniziert ebenfalls mit dem Monitor. Dieses Schema ist in Abbildung 1 dargestellt.
Die Motivation für eine solche Flexibilität wird aus der nachfolgenden Diskussion vielleicht klarer.