Die Tage danach
In der Zeit seit dem Treffen habe ich Gespräche mit Steve Wolfe (UCLA-CCN), Bill Crowther (BBN) sowie John Heafner und Erick Harslem (RAND) geführt. Wolfes Kommentare werden als NWG/RFC #38 erscheinen und fallen in eine Klasse, zu der ich weiter unten Stellung nehmen werde.
Crowther reichte Folgendes ein:
„Eine kurze Beschreibung zweier Ideen zur Vereinfachung des auf dem Märztreffen beschriebenen Host-Protokolls. Diese Ideen sind nicht sorgfältig ausgearbeitet worden.
Idee 1. Erneut verbinden.
„Ein NCP, der erneut verbinden will, sagt jedem seiner Nachbarn ‚Ich will erneut verbinden‘. Sie warten, bis keine Nachrichten mehr unterwegs sind, und antworten ‚OK‘. Er sagt dann ‚Verbindet wie folgt neu‘ und sie tun es. Im seltenen Fall erhält der NCP ein ‚Ich will stattdessen erneut verbinden‘ statt eines ‚OK‘; dann muss einer gehen und einer anhalten. Behandeln Sie also ein ‚erneut verbinden‘ von einem höheren Host-Benutzer usw. als ein OK und von einem niedrigeren als ein ‚Nein – warte, bis ich dich erneut verbinde‘, und führen Sie die Verbindung durch.
Idee 2
„Verbindungen und Links entkoppeln. Stellen Sie weiterhin Verbindungen her, aber verwenden Sie für die Nachrichten irgendeinen passenden Link. Senden Sie keine weitere Nachricht auf einer Verbindung, bevor ein FRNM zurückkommt. Fügen Sie Quell- und Ziel-Socket-Nummern in das Paket ein.
„Um erneut zu verbinden, sagen Sie zu jedem der Nachbarn ‚bitte verbinde mich wie folgt erneut ...‘. Halten Sie die Verbindung für kurze Zeit (Sekunden) fest und senden Sie sowohl Pakete als auch Verbindungsnachrichten in Richtung ihrer Ziele weiter. Ich habe nicht ausgearbeitet, wie man die unterwegs befindlichen Nachrichten in der richtigen Reihenfolge hält, aber wahrscheinlich funktioniert alles, wenn Sie kein erneutes Verbinden aussenden, solange RFNMs ausstehen.“
Bills erste Idee scheint mir weder entscheidend besser noch (nach einigem Nachdenken) sehr verschieden zu sein, und ich erwäge sie. Ich habe noch keine starken Gefühle dazu, aber ich versuche, welche zu entwickeln.
Bills zweite Idee scheint meiner Vorstellung von der Rolle der Links zu widersprechen. Ein Argument für die Entkopplung von Verbindungen und Links ist, dass die Anzahl der Verbindungen zwischen zwei Hosts 255 überschreiten könnte und dass es, selbst wenn nicht, ein solideres Vorgehen ist, Abhängigkeiten im Entwurf zu isolieren. Andererseits wird die neu bereitgestellte Link-Stopp-Einrichtung* (Seite 22 des in Kürze erscheinenden BBN-Berichts #1822, überarbeitet Februar 1970) nutzlos. (Bill, der das Merkmal gerade eingebaut hat, kümmert das nicht.) Ein weiterer Einwand ist, dass es intuitiv schlecht erscheint, die Möglichkeit zu verschwenden, das Link-Feld zum Transport von Informationen zu nutzen. (Beachten Sie den Konflikt der Bauchgefühle).
In einem Gespräch mit John Haefner und Eric Harslem von RAND wiesen sie darauf hin, dass das derzeitige Protokoll keine Vorkehrung für Fehlererkennung und -meldung, Statusprüfung und -meldung sowie Erweiterung und Experimentieren trifft. Fehlererkennung und Statusprüfung werden einige ausgedehnte Diskussionen erfordern, um zu sehen, was nützlich ist, und ich erwarte, dass solche Diskussionen stattfinden werden, während die Implementierung voranschreitet. Raum für Protokollerweiterung und Experimentieren zu lassen, geschieht jedoch am besten jetzt.
Ich schlage vor, zwei Bereiche für die Erweiterung zu reservieren. Einer ist, dass nur ein Bruchteil der 256 Links verwendet wird, sagen wir die ersten 32. Der andere Bereich ist, Befehlscodes von 255 abwärts zu verwenden, wobei dauerhafte Codes von der Anzahl der in Gebrauch befindlichen Links bis 32 zugewiesen werden; ich halte es für recht unwahrscheinlich, dass wir für geraume Zeit mehr als 32 benötigen würden, und außerdem würde das Netzwerk den Verkehr, der durch eine starke Link-Zuweisung impliziert wird, wahrscheinlich nicht bewältigen. (Diese beiden Dinge sind nicht notwendigerweise stark gekoppelt: Man kann viele Links zugewiesen haben, aber zu jedem gegebenen Zeitpunkt nur wenige, die Verkehr tragen.)
Einige von Heafners und Harslens anderen Ideen mögen in Form von NWG/RFC erscheinen.
Unmittelbare Interaktion
In den nächsten Tagen werde ich weiterhin an jener Kritik am derzeitigen Protokoll interessiert sein, die zu seiner Ablehnung oder ernsthaften Änderung führen könnte. Danach wird der Schwerpunkt auf Verfeinerung, Implementierung, Erweiterung und Nutzung liegen. Ich bin in UCLA über meine Sekretärin Frau Benita Kristel unter (213) 825-2368 erreichbar. Außerdem ist jeder eingeladen, zur NWG/RFC-Reihe beizutragen. Einmalige Nummern werden von Benita zugewiesen.
* Die Link-Stopp-Einrichtung ist eine Möglichkeit, wie ein empfangender Host RFNMs so abwandelt, dass sie eine flusslöschende Bedeutung tragen. Ein alternatives Verfahren ist die Verwendung eines Host-zu-Host-Steuerbefehls.
Hinweis: Diese RFC wurde von Ron Fitzherbert 1/97 für die Eingabe in die Online-RFC-Archive in maschinenlesbare Form gebracht.