II. Fragen und Präferenzen

In diesem Abschnitt versuchen wir, jede der verschiedenen Fragen darzustellen, die in den jüngsten NWG/RFCs und in privaten Gesprächen aufgeworfen wurden, und schlagen zu jeder Frage eine Antwort oder eine Vorgehensweise vor. In vielen Fällen werden gute Ideen verworfen, weil sie nach unserer Einschätzung auf einer anderen Ebene angesiedelt werden sollten.

A. Doppeltes Auffüllen

Wie der BBN-Bericht #1822 erläutert, hängt die Imp-Seite der Host-zu-Imp-Schnittstelle eine 1, gefolgt von null oder mehr Nullen, an, um eine Nachricht bis zu einer Imp-Wortgrenze aufzufüllen und dennoch die Nachrichtenlänge zu erhalten. Außerdem verlängert die Host-Seite der Imp-zu-Host-Schnittstelle eine Nachricht mit Nullen, um die Nachricht bis zu einer Host-Wortgrenze aufzufüllen.

Der Mechanismus von BBN funktioniert gut, wenn der sendende Host eine ganzzahlige Anzahl von Wörtern senden will oder wenn die Hardware des sendenden Hosts Teilwörter senden kann. Will der sendende Host jedoch eine Nachricht unregelmäßiger Länge senden und kann seine Hardware nur Nachrichten aus ganzen Vielfachen eines Worts senden, so ist eine zusätzliche Konvention erforderlich.

Eine der einfachsten Lösungen besteht darin, die Imp-Seite der Host-zu-Imp-Schnittstelle so zu ändern, dass sie nur Nullen anhängt. Das würde bedeuten, dass die Host-Software die abschließende 1 liefern müsste. BBN lehnte die Änderung wegen einer verständlicherweise starken Abneigung gegen Hardwareänderungen ab. Es wurde auch vorgeschlagen, dass ein Patch von fünf Befehlen im Imp-Programm die von der Schnittstelle gelieferte 1 entfernen würde, doch auch dies wurde abgelehnt, und zwar mit der neuen Begründung, es erscheine sicherer, sich allein auf die Host-Hardware zu verlassen, um das Nachrichtenende zu signalisieren, und überhaupt nicht auf die Host-Software.

Zwei weitere Lösungen stehen ebenfalls zur Verfügung. Die eine ist „doppeltes Auffüllen“, wobei der sendende Host 10* liefert und das Netz ebenfalls 10* liefert. Bei der Eingabe entfernt ein empfangender Host dann das abschließende 10* 10*. Die andere Lösung besteht darin, die Markierung zu nutzen. Die Markierung ist eine Bitfolge der Form 0*1, die zwischen dem Leader und dem Text einer Nachricht eingefügt wird. Der ursprüngliche Zweck der Markierung war, den Leader so zu verlängern, dass der sendende Host seinen Text an einer Wortgrenze beginnen kann. Man kann die Markierung auch nutzen, um eine Nachricht so zu verlängern, dass sie an einer Wortgrenze endet.

Man beachte, dass doppeltes Auffüllen die Markierung vollständig ersetzen könnte, indem man den Textanfang unmittelbar an den Leader anschließt. Für 32-Bit-Maschinen ist dies bequem und die Markierung nicht, während bei anderen Wortlängen, insbesondere bei 36-Bit-Maschinen, die Markierung wesentlich bequemer ist als doppeltes Auffüllen.

Wir haben keine ausgeprägte Präferenz, zum Teil weil wir Wortfragmente senden können. Shoshani et al. behaupten in NWG/RFC #44, dass ihnen das Anpassen der Markierung keinerlei Probleme bereitet, und sie haben eine 32-Bit-Maschine. Da der Gedanke der Markierung schon seit einiger Zeit akzeptiert ist, schlagen wir vor, kein doppeltes Auffüllen zu verwenden und die Markierung zur Anpassung der Länge einer Nachricht zu nutzen. Wir weisen darauf hin, dass, falls BBN jemals die 1 aus dem Hardware-Auffüllen entfernt, auf der Sendeseite nur minimale Änderungen an der Host-Software nötig sind.

Eine viel elegantere (und teurere) Anordnung wurde von W. Sutherland vorgeschlagen. Er schlug vor, die Host/Imp-Schnittstellen so intelligent zu machen, dass sie Auffüllung oder Markierung entfernen und die Nachricht bei der Eingabe vielleicht sogar parsen.

B. Wiederverbindung

Eine sehr große Zahl von Netzwerkern hat uns heftig dafür kritisiert, dass wir die dynamische Wiederverbindung in das Protokoll aufgenommen haben. Wir dachten, es könnte von Interesse sein zu berichten, wie es dazu kam.

Nachdem wir uns eine Weile mit Verbindungen und ihren Verwendungszwecken beschäftigt hatten, fragten wir uns, wie sich der Mechanismus der Verbindungen zu bestehenden Formen der Interprozesskommunikation innerhalb eines Hosts verhält. Zwei Aspekte sind von Interesse: welche Formalismen in der Literatur vorgestellt wurden und welche Mechanismen in Gebrauch sind. Die Formalismen sind interessant, weil sie zu einheitlichen Implementierungen und einem sparsamen Entwurf führen. Die bestehenden Mechanismen sind interessant, weil sie aufzeigen, welche Probleme gelöst werden müssen, und manchmal andeuten, wie ein geeigneter Formalismus aussehen könnte. Insbesondere ist uns aufgefallen, dass die Mechanismen, mit denen beim Einwählen eine Konsole mit dem Logger verbunden wird, die Mechanismen zum Erzeugen eines Jobs und die Mechanismen, mit denen eine Konsole innerhalb eines Jobs an verschiedene Prozesse weitergereicht wird, meist höchst eigentümlich sind und sich von allen anderen Strukturen und Mechanismen innerhalb eines Betriebssystems unterscheiden.

Was die Literatur betrifft, scheint es nur eine Idee mit mehreren Varianten zu geben, nämlich dass Prozesse einen Teil ihrer Adressräume gemeinsam nutzen und einander kooperativ aufwecken sollten. Semaphore und Ereigniskanäle sind praktische Erweiterungen von Wecksignalen, doch die Absicht ist im Grunde dieselbe. (Ereigniskanäle könnten wahrscheinlich als Verbindungen fungieren, doch das scheint nicht ihrem vorgesehenen Einsatzzweck zu entsprechen. In kleinen Systemen stehen Effizienz und Kapazität von Ereigniskanälen in umgekehrtem Verhältnis zueinander.)

Was bestehende Implementierungen betrifft, stellen wir fest, dass mehrere Systeme es einem Prozess erlauben, einem anderen Prozess als Datei zu erscheinen. Manche Systeme, z. B. das SDS-940 am SRI, erzwingen zwischen zwei so verbundenen Prozessen ein Master/Slave-Verhältnis, andere Systeme dagegen sehen ein gleichrangiges Verhältnis vor, z. B. das PDP-6-System der AI-Gruppe am MAC. Das PDP-6-System verfügt außerdem über eine Funktion, mit der ein übergeordneter Prozess einen untergeordneten Prozess mit einer Abbildung von Geräte- und Dateinamen auf andere Geräte- und Dateinamen „umgeben“ kann. Konsolen haben nahezu dieselbe Semantik wie Dateien, daher ist es durchaus möglich, dass ein untergeordneter Prozess glaubt, mit der Konsole zu kommunizieren, in Wirklichkeit aber mit einem anderen Prozess kommuniziert.

Die Ähnlichkeit zwischen Netzverbindungen und bestehenden sequenziellen Interprozessverbindungen stützt unsere Überzeugung, dass Netzverbindungen wahrscheinlich die richtige Struktur für die Nutzung des Netzes sind. Zudem ist die Struktur sauber genug und mit genügend vielen Maschinen kompatibel, um als Formalismus oder Theorie durchzugehen, zumindest im Umfang der anderen in der Literatur vorgestellten Formen der Interprozesskommunikation.

Jeder neue Formalismus muss unserer Ansicht nach mindestens die folgenden zwei Prüfungen bestehen:

1. Welche offenen Probleme löst er?

2. Ist er unter allen Operationen abgeschlossen?

Im Fall der Netzverbindungen kommen für die erste Prüfung die oben genannten Probleme in Frage, d. h. alle Operationen, bei denen eine Konsole mit einem Job oder einem Prozess verbunden wird. Von Interesse sind auch die Modellierung sequenzieller Geräte wie Bandlaufwerke, Drucker und Kartenleser sowie die Modellierung ihrer Puffersysteme (Spooling, Symbiont).

Die zweite Frage spricht die Abgeschlossenheit an. Bei der Anwendung des Verbindungsformalismus auf die Einwähl- und Anmeldeverfahren sahen wir die Notwendigkeit, irgendeine Form von Umschaltung oder Wiederverbindung aufzunehmen, und eine äußerst milde Form wird in einem SJCC-Papier vorgestellt, das zugleich NWG/RFC #33 ist. Diese milde Form erlaubt nur das Ersetzen von AENs, und selbst das nur zum Zeitpunkt des Verbindungsaufbaus. Es ist jedoch eine allgemeine Erfahrung, dass es, wenn eine Operation eine natürliche Definition auf einem erweiterten Bereich hat, irgendwann notwendig oder zumindest wünschenswert wird, ihre Definition zu erweitern. Deshalb haben wir die folgenden Erweiterungen erwogen:

1. Umschalten auf einen beliebigen anderen Socket, möglicherweise in einem anderen Host.

2. Umschalten auch noch nach Beginn des Datenflusses.

Es gibt sogar gewisse Präzedenzfälle für die Annahme, dass diese Erweiterungen nützlich sein könnten. In einer bestimmten Sichtweise eines Betriebssystems betrachten wir alle verfügbaren Telefonleitungen als zu einem aktiven Prozess gehörig, der als Logger bezeichnet wird. Der Logger nimmt Anrufe entgegen, überprüft Benutzer und erzeugt Jobs und Prozesse. Eine der Eigenschaften der meisten Anlagen zur Anrufannahme ist, dass viele Telefonleitungen dieselbe Rufnummer bedienen können, indem ein Block fortlaufender Nummern und ein rotierendes Annahmesystem verwendet werden. Auf unserer Suche nach genauen Modellen praktischer Systeme wollten wir Netzbenutzern einen gleichwertigen Dienst bieten können, d. h. sie sollten eine einzige bekannt gegebene Nummer anrufen und mit dem Logger verbunden werden können. Damit ist prima facie ein Argument für das Umschalten begründet.

Als Nächstes sehen wir, dass der Logger, nachdem er einen möglichen Benutzer befragt hat, den Benutzer mit einem neu erzeugten Job verbinden muss. Der Datenfluss zwischen dem Benutzer und dem Logger hat bereits begonnen, daher muss die Flusssteuerung mit dem Umschalten verzahnt werden, wenn Daten während der Übertragung nicht verloren gehen oder verstümmelt werden sollen.

Was das Umschalten zwischen Hosts betrifft, können wir uns leicht einen Versorgungsdienst vorstellen, der über das Netz verteilt ist und Verbindungen ohne Wissen des Benutzers von einem Socket an einen anderen weiterreicht. Außerdem ähnelt dies den anspruchsvolleren Telefonsystemen, den Standarddiensten der Vermittlungskräfte von Telefongesellschaften und verteilten privaten Systemen.

Diese Überlegungen veranlassten uns zu untersuchen, ob sich eine Art der Wiederverbindung finden lässt, die eine Grundlage für alle bekannten Modelle bietet. Der Algorithmus fiel uns nicht leicht, wahrscheinlich wegen mangelnder Erfahrung mit der Theorie endlicher Automaten, doch schließlich entwickelten wir den in NWG/RFC #36 vorgestellten Algorithmus. Kurze Zeit später entwickelte Bill Crowther einen gleichwertigen Algorithmus, der Wettlaufsituationen auf andere Weise angeht.

Netzwerker scheinen eine von zwei Reaktionen zu zeigen. Entweder war es elegant und (vielleicht ipso facto) nützlich, oder es war komplex und (wiederum vielleicht ipso facto) unnötig. Die letztere Gruppe war für uns weit deutlicher wahrnehmbar, und wir wurden in die Defensive gedrängt und mussten einräumen, dass die dynamische Wiederverbindung lediglich

1. hübsch sei

2. für die Anmeldung und das Weiterreichen der Konsole nützlich sei

Auf anhaltende Kritik hin haben wir folgende Änderung am Protokoll vorgenommen. Statt zur Anmeldung den Socket <O,H,O> aufzurufen, sind Sockets der Form <U,H,O> und <U,H,1> der Eingabe- bzw. Ausgabe-Socket einer Kopie des Loggers oder, falls ein Job mit der Benutzerkennung U gestartet wurde, die Konsolen-Sockets. Das Protokoll für die Anmeldung besteht also darin, eine Verbindung zu <U,H,O> und <U,H,1> einzuleiten. Ist der Benutzer U nicht in Gebrauch, antwortet eine Kopie des Loggers und befragt den Anrufer. Ist die Benutzerkennung U in Gebrauch, wird der Anruf abgelehnt. Diese Änderung wurde kürzlich von Barry Wessler vorgeschlagen. (Andere haben diese Änderung auch schon viel früher vorgeschlagen; wir hatten sie damals jedoch abgelehnt.)

Der Logger kann verlangen, dass der Anrufer aus demselben virtuellen Netz stammt, d. h. dass der Anrufer die Benutzerkennung U in einem anderen Host hat, oder er kann verlangen, dass der Benutzer ein zur Benutzerkennung U passendes Passwort angibt, oder er kann beides verlangen. Manche Systeme entscheiden sich vielleicht sogar dafür, jedem die Anmeldung unter jeder Benutzerkennung zu erlauben.

Nach der Anmeldung bleiben die AENs 0 und 1 die Konsolen-AENs. Jedes System verfügt vermutlich über Mechanismen zum Weiterreichen der Konsole, und diese würden so erweitert, dass sie die AENs 0 und 1 für Netzbenutzer kennen. Das Weiterreichen der Konsole ist somit eine Frage der Wiederverbindung von Sockets mit Ports und geschieht innerhalb des Hosts und ohne das Netz.

In Gesprächen mit Meyer und Skinner nach Eingang von NWG/RFC #46 schlugen diese ein Anmeldeschema vor, das sich sowohl von Meyers als auch von unserem im obigen Abschnitt unterscheidet. Ihr neues Schema erschien uns etwas besser, und wir sehen ihrer nächsten Note mit Interesse entgegen.

Es besteht allgemein Einigkeit darüber, dass die Anmeldung auf der „dritten Ebene“ angesiedelt sein sollte, also oberhalb der NCP-Ebene. Uns werden bestimmte Anmeldeschemata allmählich gleichgültig; alle scheinen in Ordnung, und keines beeindruckt uns sonderlich. Wir schlagen vor, mehrere davon zu erproben. Es ist natürlich ein gewisser Aufwand, das lokale Anmeldeverfahren zu ändern, doch wir glauben, dass der Umgang mit unterschiedlichen Anmeldeverfahren keine zusätzliche Härte mit sich bringt. Das liegt daran, dass die Textfolgen und Interrupt-Konventionen so heterogen sind, dass der zusätzliche Aufwand, etwa unser Schema auf unserem System und Meyers Schema auf Multics zu befolgen, minimal ist.

Wir sind uns einig, dass die Wiederverbindung im ursprünglichen Protokoll nicht vorgeschrieben sein sollte, und wir werden sie später als optionales und experimentelles Werkzeug anbieten. Darüber hinaus möchten wir die Vorhersage zu Protokoll geben, dass allgemeine Wiederverbindungseinrichtungen nützlich werden und einen vereinheitlichenden Rahmen für die derzeit ad hoc entstandenen Betriebssystemstrukturen bieten werden.

C. Entkopplung von Verbindungen und Links

Bill Crowther (BBN) und Steve Wolfe (UCLA) haben unabhängig voneinander vorgeschlagen, Links nicht bestimmten Verbindungen zuzuordnen. Stattdessen, so schlagen sie vor, solle der Ziel-Socket in den Text der Nachricht aufgenommen werden, und die Nachrichten sollten dann über einen beliebigen nicht blockierten Link gesendet werden.

Wir haben diese Frage in NWG/RFC #37 kurz erörtert und sind der Ansicht, dass es für beide Varianten noch Argumente gibt. Angesichts der derzeitigen Betonung von Einfachheit, Geschwindigkeit und geringem Kernspeicherbedarf erscheint es effizienter, Links und Verbindungen gekoppelt zu lassen. Wir empfehlen daher dies.

D. Fehlermeldung

Wie J. Heafner und E. Harslem von RAND erwähnt haben, ist es wichtig, möglicherweise auftretende Fehler zu behandeln. Ein guter Grundsatz ist es, sich gegen jede Eingabe abzusichern, die die Konsistenz der Datenbasis des NCP zerstört.

Die konkrete Formulierung des Fehlerbefehls, die Heafner und Harslem in NWG/RFC #40 und Meyer in NWG/RFC #46 angegeben haben, erscheint vernünftig, und wir empfehlen ihre Übernahme. Einige Anmerkungen sind jedoch angebracht.

Es sollte zwischen Ressourcenfehlern und anderen Fehlerarten unterschieden werden. Ressourcenfehler sind lediglich die Erkennung von Überlastzuständen. Überlastzustände sind wohldefiniert und gültig, wenn auch vielleicht unerwünscht. Andere Fehlerarten spiegeln fehlerhafte Software oder Hardware wider. Wir sind der Ansicht, dass Ressourcenfehler nicht mit Fehlermechanismen behandelt werden sollten, sondern mit problemspezifischen Mechanismen. So kann der Befehl <CLS> ausgegeben werden, wenn kein Platz mehr vorhanden ist, um wartende <RFC>s zu speichern. Das Flusssteuerungsprotokoll ist ausschließlich zur Behandlung von Pufferüberlastung ausgelegt.

Was echte Fehler betrifft, sind wir nicht sicher, welchen Wert der Befehl <ERR> für den Empfänger hat. Vermutlich ist dessen NCP defekt, und es könnte das Problem nur verschlimmern, es mit Fehlerbefehlen zu bombardieren. Wir empfehlen daher, dass die Fehlererzeugung optional ist, dass alle Fehler lokal in einer chronologischen Datei protokolliert werden und dass empfangene <ERR>-Befehle ebenfalls in einer chronologischen Datei protokolliert werden. Korrekturmaßnahmen werden derzeit nicht festgelegt.

In der kurzen Zeit, in der das Netz an der UCLA in Betrieb ist, haben wir uns davon überzeugt, dass das Netz selbst nur sehr wenige Fehler erzeugen wird. Wir haben beobachtet, wie die Mitarbeiter von BBN das IMP-Programm debuggten und testeten, und es schien, dass die meisten Fehler eher das Timing und den Durchsatz als die Korrektheit betrafen. Daher werden die meisten Fehler wahrscheinlich von defekten Hosts und/oder fehlerbehafteten NCPs herrühren.

E. Statusabfrage und Statusmeldung

Eine wertvolle Hilfe bei der Fehlersuche besteht darin, Informationen darüber erhalten zu können, was nach Ansicht eines fremden NCP gerade geschieht. Eine bequeme Möglichkeit hierfür ist, den NCPs zu gestatten, ihren Status zu senden, wann immer sie wollen, sie dies aber stets tun zu lassen, wenn sie eine Anfrage erhalten.

Da wir diese Funktion in erster Linie als Werkzeug zur Fehlersuche betrachten, schlagen wir vor, einen eigenen Link, etwa 255, zu verwenden. Die Absicht ist, dass die Verarbeitung von Statusanfragen und die Erzeugung von Statusmeldungen so wenig wie möglich von der normalen Maschinerie beanspruchen sollen. Daher schlagen wir vor, Link 255 zum Senden der Befehle „Status anfordern“ und „Status ist“ zu verwenden. Die Form folgt dem Vorschlag auf Seite 2 von NWG/RFC #40.

Meyers Befehl <ECO> ist leicht zu implementieren und erfüllt die grundlegendere Funktion, zu prüfen, ob ein fremdes NCP noch lebt. Wir schlagen vor, die Länge des Befehls <ECO> variabel zu halten, da 48 Bit in diesem Zusammenhang keine Bedeutung zu haben scheinen. Auch ist der Wert eines (vermutlich) 8-Bit-Binärschalters unklar, daher empfehlen wir ein Befehlspaar:

<ECO> <length> <text>

und

<ERP> <length> <text>

wobei

<length> umfasst 8 Bit.

Beim Empfang eines <ECO>-Befehls würde das NCP mit dem Befehl <ERP> ein Echo zurückgeben.

F. Erweiterung und Experimentieren

Wie Meyer in NWG/RFC #46 zutreffend feststellt, ist das Netzprotokoll eine geschichtete Angelegenheit. Bisher sind drei Ebenen erkennbar.

1. IMP-Netzprotokoll

2. Protokoll des Netzsteuerungsprogramms

3. Protokoll der speziellen Benutzerebene bzw. der Subsystemebene

Diese letzte Ebene sollte für jeden Host (oder sogar jeden Benutzer) individuell bleiben. Die erste Ebene ist von BBN klar spezifiziert, und unser Augenmerk liegt hier auf Ebene 2. Wir möchten Ebene 2 so neutral und einfach wie möglich halten, und insbesondere stimmen wir zu, dass das Anmeldeprotokoll so weit wie möglich auf Ebene 3 angesiedelt sein sollte.

Aller Einfachheit und Voraussicht zum Trotz wird es Anlässe geben, bei denen das Protokoll der Ebene 2 geändert oder mit ihm experimentiert werden sollte. Um Experimente und Änderungen zu ermöglichen, empfehlen wir, nur die Link-Nummern 2 bis 31 regulären Verbindungen zuzuweisen und die übrigen Link-Nummern, 32 bis 255, experimentell zu nutzen. Wir haben bereits vorgeschlagen, Link 255 für Statusanfragen und -antworten zu verwenden, und dies steht im Einklang mit unserer Sicht auf die experimentellen Aspekte dieser Funktion.

Wir empfehlen außerdem, Präfixe von Steuerbefehlen ab 255 abwärts für Experimente zu verwenden.

Diese beiden Konventionen reichen unserer Ansicht nach aus, um bequemes Experimentieren mit neuen Protokollen zwischen beliebigen Teilmengen der Standorte zu ermöglichen. Wir befürworten daher nicht die Aufnahme von Anconas Vorschlag in NWG/RFC #42, einen Datentypcode der Nachricht als die ersten acht Bit des Nachrichtentexts vorzusehen.

G. Multiplexen von Ports auf Sockets

Wolfe in NWG/RFC #38 und Shoshani et al. in NWG/RFC #44 schlagen vor, dass es möglich sein sollte, mehr als einen Port an einen Socket anzuschließen. Zwar haben alle unsere Diagramme und prototypischen Systemaufrufe eine Eins-zu-eins-Entsprechung zwischen Sockets und Ports gezeigt, doch ist dies ausschließlich eine Frage der lokalen Implementierung. Wir weisen darauf hin, dass Sockets einen netzweiten Namensraum bilden, dessen einziger Zweck die Vermittlung zwischen den eigentümlichen, jedem Betriebssystem eigenen Strukturen ist. Unsere Bezugnahmen auf Ports sind lediglich als Anregung gedacht und sollten ignoriert werden, wenn ihnen keine internen Strukturen entsprechen. Die meisten Systeme verfügen jedoch über solche Strukturen, daher werden wir sie weiterhin zur Veranschaulichung verwenden.

H. Echo, Interrupts und Codeumwandlung

1. Interrupts

Wir waren bisher davon ausgegangen, dass alle Betriebssysteme die Tastatureingaben nach einem reservierten Zeichen durchsuchen, um es als Interrupt-Signal zu interpretieren. Tom Skinner und Ed Meyer vom MIT teilen uns mit, dass TTYs des Modells 37 und das IBM 2741 ein „langes Leersignal“ von 200-500 Millisekunden erzeugen, das von der Hardware des E/A-Kanals erkannt und als Interrupt an das Betriebssystem weitergegeben wird. Das „lange Leersignal“ ist kein Zeichen -- es hat keinen ASCII-Code und kann nicht von einem Programm erzeugt werden.

Vor weit über einem Jahr haben wir uns mit dem Problem der Simulation von Konsolen-Interrupts befasst und den Befehl vom Typ <INT> verworfen, weil er kein uns bekanntes System korrekt modellierte. Wir revidieren nun unsere Haltung und empfehlen die Implementierung eines Systemaufrufs INTERRUPT und eines Steuerbefehls <INT>, wie von Meyer in NWG/RFC #46 vorgeschlagen.

Zwei Einschränkungen der Interrupt-Einrichtung sollten beachtet werden. Erstens sollte diese Funktion bei der Kommunikation mit Systemen, die nach Interrupt-Zeichen suchen, nicht verwendet werden. Zweitens sollten nicht konsolenartige Verbindungen wahrscheinlich keine Interrupts haben. Wir empfehlen, dass die Systeme ihren eigenen Konventionen folgen, und wenn ein <INT> für eine Verbindung eintrifft, für die es nicht vorgesehen ist, sollte das <INT> verworfen und optional als Fehler zurückgemeldet werden.

2. Echo und Codeumwandlung

Wir sind der Ansicht, dass jeder Standort seine derzeitige Echo-Praxis beibehalten und die Codeumwandlung vom nutzenden Prozess vorgenommen werden sollte. Eine Standardisierung in diesem Bereich sollte weitere Entwicklungen abwarten.

Anconas Vorschlag eines tabellengesteuerten Front-End-Wandlers scheint das Richtige zu sein, doch wir glauben, dass solche Techniken Teil einer umfassenderen Diskussion über höhere Sprachen für das Netz sind.

I. Broadcast-Einrichtungen

Heafner und Harslem schlagen in NWG/RFC #39 eine Broadcast-Einrichtung vor, d. h. <TER> und <BDC>. Wir verstehen den Nutzen dieser Einrichtung nicht ganz und stehen ihr daher ablehnend gegenüber. Wir vermuten, dass wir ihren Nutzen besser verstünden, wenn wir mehr Erfahrung mit OS/360 hätten. Wahrscheinlich gilt allgemein, dass Standorte, die OS/360 oder ähnliche Systeme betreiben, unsere Vorschläge für das Netzprotokoll weniger relevant finden werden als Standorte mit Timesharing-Systemen. Wir wären für jede stichhaltige Darstellung des Verhältnisses zwischen OS/360 und den Konzepten und Annahmen, die dem Netzprotokoll zugrunde liegen, dankbar.

J. Instanznummern

Meyer schlägt in NWG/RFC #46 vor, einen Socket um einen Instanzcode zu erweitern, der den an den Socket angeschlossenen Prozess identifiziert. Wir haben die Dinge sorgfältig so eingerichtet, dass Prozesse nicht unterscheidbar sind. Wir taten dies in der Überzeugung, dass es sowohl formal als auch praktisch nur innerhalb eines Hosts von Belang ist, ob eine Berechnung von einem oder von vielen Prozessen ausgeführt wird. Daher glauben wir, dass alle Prozesse innerhalb eines Jobs bei der Vergabe von AENs zusammenarbeiten sollten. Verfügt ein Betriebssystem über Einrichtungen, um eine Konsole innerhalb eines Jobs von Prozess zu Prozess weiterzureichen, so fügen sich diese Einrichtungen gut in das derzeitige Netzprotokoll ein, sogar in das Wiederverbindungsprotokoll; Instanznummern stören ein solches Verfahren jedoch.

Wir schlagen vor, diese Angelegenheit eingehend zu erörtern, da sie die grundlegende Philosophie von Sockets und Verbindungen berührt. Derzeit empfehlen wir Socket-Nummern von 40 Bit ohne Instanzcodes.

K. AENs

Niemand, auch wir selbst nicht, ist mit unserer Bezeichnung AEN für die niederwertigen 8 Bit des Sockets besonders glücklich. Wir haben Socket-Nummer verworfen und sind mit Meyers Socket-Code ähnlich unzufrieden. Das Wort Socket sollte nicht als Teil des Feldnamens verwendet werden, und wir bitten um Vorschläge.