Zum Hauptinhalt springen

I. Einleitung

Wie in NWG/RFC #53 angekündigt, legen wir das hier beschriebene Protokoll zur Kritik, Kommentierung usw. vor. Wir beabsichtigen, dass dieses Protokoll das erste offizielle Protokoll wird, und wären daher am glücklichsten, wenn keine ernsthaften Einwände erhoben werden. Dennoch nehmen wir bis zum 13. Juli 1970 Kritik jeder Art entgegen; solche Kritik sollte als NWG/RFC veröffentlicht oder an den Erstautor gerichtet werden.

Nach dem 13. Juli wird entschieden, ob dieses Protokoll (oder eine leichte Abwandlung davon) übernommen oder ob es überarbeitet und erneut zur Kritik vorgelegt wird.

Nur das Protokoll​

In früheren Diskussionen über das Protokoll wurde nicht klar zwischen netzwerkweiten Spezifikationen und lokalen Strategien unterschieden. Wir halten hier fest, dass die einzigen netzwerkweiten Fragen die Nachrichtenformate und die Einschränkungen des Nachrichteninhalts sind. Die Implementierung eines Netzwerksteuerprogramms (NCP) und die Wahl der Systemaufrufe sind ausschließlich lokale Angelegenheiten.

Dieses Dokument beschränkt sich auf netzwerkweite Fragen und behandelt daher weder Systemaufrufe noch NCP-Tabellen; dennoch ist ein Protokoll ohne NCP und einen Satz von Systemaufrufen nutzlos, weshalb wir großen Aufwand in die Ausarbeitung eines prototypischen NCP gesteckt haben. Über diese Arbeit wird in NWG/RFC #55 berichtet, und der Leser sollte das hier vorgestellte Protokoll mit den dort gemachten Vorschlägen zu seiner Nutzung abgleichen. Es ist jedoch wichtig zu bedenken, dass der Inhalt von NWG/RFC #55 lediglich als Anregung gedacht ist und dass konkurrierende Vorschläge geprüft werden sollten, bevor man sich für eine Implementierung entscheidet.

Flusssteuerung​

Im Verlauf des Entwurfs dieses Protokolls haben wir erkannt, dass die Flusssteuerung komplexer ist, als wir angenommen hatten. Wir glauben inzwischen, dass Techniken der Flusssteuerung mit zunehmendem Netzwerkverkehr zu den zentralen Problemfeldern gehören werden. Wir haben daher von einigen Ideen profitiert, die von Richard Kaline und Anatol Holt angeregt wurden, und das Verfahren zur Flusssteuerung geändert. (Mängel in unserem Schema gehen selbstverständlich allein auf uns zurück.) Dieses neue Verfahren hat nachweisbare Grenzen, bietet aber die Vorteile, dass es sich sauberer implementieren lässt und die anfängliche Nutzung des Netzwerks unterstützt. Dies ist die einzige inhaltliche Änderung gegenüber dem bereits vereinbarten Protokoll.

Der neue Mechanismus zur Flusssteuerung verlangt, dass der empfangende Host für jede Verbindung Pufferspeicher zuteilt und dem sendenden Host mitteilt, wie viel Speicher in Bit verfügbar ist. Der sendende Host verfolgt, wie viel Platz verfügbar ist, und sendet nie mehr Text, als der empfangende Host seiner Einschätzung nach annehmen kann.

Zur Umsetzung dieses Mechanismus führt der sendende Host für jede Verbindung einen Zähler. Der Zähler wird mit null initialisiert, durch Steuerbefehle des empfangenden Hosts erhöht und um die Textlänge jeder über die Verbindung gesendeten Nachricht verringert. Dem sendenden Host ist es untersagt, Text zu senden, der länger ist als der Wert des Zählers, sodass der Zähler nie unter null fällt.

Idealerweise teilt der empfangende Host Pufferspeicher zu, sobald die Verbindung hergestellt ist. Die zugeteilte Menge darf nie überschreiten, was der Empfänger garantiert annehmen kann. Eintreffender Text belegt den zugeteilten Pufferspeicher. Wenn der empfangende Prozess den wartenden Text aus dem Puffer übernimmt, sendet das NCP umgehend eine neue Speicherzuteilung für diese Verbindung zurück. Das NCP kann auch dann Speicher zuteilen, wenn der empfangende Prozess den wartenden Text noch nicht übernommen hat, sofern es zusätzlichen Pufferspeicher für angebracht hält. Ebenso kann das NCP entscheiden, keinen Pufferspeicher erneut zuzuteilen, nachdem der empfangende Prozess ihn freigegeben hat.

Der Steuerbefehl, der Speicher zuteilt, lautet

ALL <link> <space>

Dieser Befehl wird ausschließlich vom empfangenden Host an den sendenden Host gesendet.

Durch diese Formulierung der Flusssteuerung werden die Befehle RSM und SPD aus NWG/RFC #36 sowie der Host-an-IMP-Nachrichtentyp 10 und die IMP-an-Host-Nachrichtentypen 10 und 11 in der aktuellen Fassung von BBN Report 1822 überflüssig.

Die offensichtliche Einschränkung dieses Schemas besteht darin, dass sich der empfangende Host nicht auf die durchschnittliche Puffernutzung verlassen darf – es wird stets vom ungünstigsten Fall ausgegangen. Sind nur wenige Verbindungen offen, sind kaum nennenswerte Einsparungen zu erwarten. Bei mehr als einigen wenigen Verbindungen liegt die durchschnittliche Puffernutzung jedoch deutlich unter dem zugeteilten Pufferspeicher. Wir haben Erweiterungen dieses Protokolls mit adaptiver Zuteilung untersucht und halten dies für machbar. Vorerst scheint dieses begrenzte Schema am besten, und wir freuen uns darauf, später ausgefeiltere Schemata zu diskutieren. Das alte Schema mit speziellen RFNMs usw. ist ebenfalls weiterhin in der Diskussion.

Um Fragen zu beantworten und Details zu besprechen, werden wir zwei Netzwerktreffen abhalten. Das erste findet am 29. Juni in Harvard statt, das zweite am 1. Juli an der UCLA. Wir bitten darum, dass pro Host nur ein Programmierer an einem Treffen teilnimmt und dass jeder Host nur bei einem dieser Treffen vertreten ist. Zwei von uns (J.N. und S.C.) werden an beiden Treffen teilnehmen.

Anmeldungen für das Treffen in Harvard richten Sie bitte an

   Mrs. Margi Robison
   (617) 495-3989
      or 495-3991

Anmeldungen für das Treffen an der UCLA richten Sie bitte an Mrs. Benita Kirstel (213) 825-2368.