Einleitung
Seite 3. Die Markierung abschaffen. Stattdessen alle regulären Nachrichten in zwei Nachrichten aufteilen: Die erste enthält nur den Kopf und zeigt an, dass die Daten in der zweiten (nächsten) Nachricht folgen. Dies ist sowohl vom Quell-Host zu seinem IMP als auch vom Ziel-IMP zu seinem Host durchzuführen. Damit entfällt die Suche nach dem Anfang der Daten. Ist diese Anpassung erst einmal vorgenommen, ist eine weitere Vereinfachung möglich. Wenn die maximale Nachrichtenlänge ein gemeinsames Vielfaches der Wortgrößen aller Rechner im Netz ist (vielleicht 2880*2 Bit), können aufeinanderfolgende Nachrichten langer Dateien an Ort und Stelle verworfen werden, ohne verschoben zu werden.
Seite 4. Steuernachrichten sollten zum und vom Steuer-Socket gesendet werden – nicht über die Steuerverbindung. Das Konzept der Steuerverbindung erzeugt einen sehr großen, unnötigen Sonderfall.
Seite 5. Die dauerhafte Zuordnung von Sockets zu bestimmten Netzressourcen sollte gefördert werden, und ein Verzeichnis der Socket/Ressource-Zuordnungen sollte irgendwo im Netz verfügbar sein, vielleicht in Form eines gedruckten Verzeichnisses an jedem Standort.
Seite 6. Links haben keinen Host-Host-Zweck außer dem, eine Verbindung zu identifizieren, damit Socket-Nummern nicht in allen Nachrichten enthalten sein müssen, und die Tabellensuche in den NCPs zu vereinfachen. Da es jedoch möglicherweise 512 Links* mit derselben Nummer gibt, helfen Links bei der Tabellensuche nicht sehr. Auch das Auffinden des nächsten verfügbaren Links zu einem bestimmten Ziel ist sehr unschön. Daher schlage ich vor, die Anzahl der Links für alle Ziele auf insgesamt n zu begrenzen (wobei n = 32, 64 oder 256 oder eine andere gute Zahl ist). Mit anderen Worten: Ein bestimmter Link ist jeweils nur zu einem Ziel in Benutzung (genauer: jeweils von einem Ziel, da der Empfänger den für eine Verbindung zu verwendenden Link auswählt). Diese Änderung macht die Auswahl des nächsten verfügbaren Links sehr einfach und ist, wie ich finde, schon aus diesem Grund eine lohnende Änderung. Die Frage der Vereinfachung der Tabellensuche ist etwas komplexer. Es ist einfach, den Link direkt als Index in Tabellen des Empfangsteils des NCP zu verwenden, da der Empfänger den Link auswählt. Im Sendeteil des NCP ist jedoch weiterhin eine Hash-Tabelle oder lineare Suche oder Ähnliches erforderlich. Auch dies lässt sich mit den folgenden Änderungen beheben. Fügen Sie zu STR einen vom Sender gewählten Pseudo-Link hinzu. Dieser Link wird in allen Nicht-Steuernachrichten in den 8 Bits rechts neben dem Link im Kopf gesendet. Das IMP muss diese Bits bewahren und sie mit RFNMs zurückgeben, und der Empfänger muss den Pseudo-Link anstelle des Links in RET und INR verwenden. Der zusätzliche Speicher, der zum Speichern des Pseudo-Links in den Empfangstabellen des NCP (die nach Link indiziert sind) und des Links in den Sendetabellen des NCP (die nach Pseudo-Link indiziert sind) erforderlich ist, ist gewiss geringer als der Aufwand für die Pflege assoziativer Tabellen.
*Eine Zielnummer ist 9 Bit lang.
Seite 8. Der Zuordnungsmechanismus scheint für den Empfangsteil des NCP sehr unbequem zu sein. Der Empfänger möchte, dass die Zuordnung in Einheiten der Puffergröße des Empfängers aufgebraucht wird und nicht in Einheiten von Sender-Nachrichten, die von variabler Länge sein können. Andernfalls hat der Empfänger ein Problem mit der Speicherverdichtung.
Seite 9. Die neuen irregulären Nachrichten, die den „cease“-Mechanismus funktionieren lassen sollen, sind meines Erachtens unnötig. Der Sender kann (wohl mit einem Ein-Bit-Zähler) ALLs und GVBs verfolgen und GVB 0 ignorieren, für die bereits Wiederaufnahme-ALLs eingetroffen sind. Damit muss der Empfänger nicht wissen, ob das cease gesendet wurde oder nicht.
Seite 15. Wenn ich einen NCP implementierte, würden alle ERR wie NOP behandelt. Als Fehlerkontrollmechanismus ist ERR kompliziert und unzureichend. Wer möchte schon einen komplizierten Mechanismus debuggen, der nur Fehler abfängt, die dadurch entstehen, dass der primäre Mechanismus nicht gedebuggt ist. Der einzige Fehlerkontrollmechanismus, den ich vorsehen würde, ist eine Empfangsprozess-zu-Sendeprozess-Bestätigung bei jeder Nachricht. Wird diese zu lange nicht empfangen, kann der Sendeprozess die Nachricht erneut senden, wenn er sie gespeichert hat. Diese Bestätigung fängt Fehler ab, die zu Nachrichtenverlust auf den Ebenen Prozess/NCP, NCP/NCP, Host/IMP, IMP/IMP usw. führen. Gegenwärtig fehlt es der Host/IMP-Schnittstelle besonders an nützlicher Fehlerkontrolle. Um Fehlerarten, die Prüfsummen erkennen sollen, würde ich mich nicht kümmern. Sollten verlorene und falsch aufgenommene Bits jemals zum Problem werden, fügen Sie entweder Hardware zu weiteren Schnittstellen hinzu, oder lassen Sie den Empfangsprozess die Prozess-zu-Prozess-Bestätigung nicht senden, wenn eine Software-Prüfsumme nicht stimmt.
Die Kommentare zu Seite 3 und Seite 6 beinhalten eine Änderung des IMP-Programms. Ich fühle mich ein klein wenig schuldig, Änderungen vorzuschlagen, die ich nicht mehr implementieren muss. Ich vertraue jedoch darauf, dass Crowther und Cosell wie immer schlechten Änderungen widerstehen und zugleich vernünftige vornehmen. Der Kommentar zu Seite 9 zielt darauf ab, eine Änderung des IMP-Programms zu vermeiden.
Hinweis: Dieser RFC wurde von Luke Hollins 8/99 für die Aufnahme in die Online-RFC-Archive in maschinenlesbare Form gebracht.