Zum Hauptinhalt springen

I Überblick

Das Netzwerkprotokoll stellt drei Einrichtungen bereit:

  1. Verbindungsaufbau

  2. Flusskontrolle

  3. Neuverbindung

Die Neuverbindung wird getrennt vom Verbindungsaufbau betrachtet, teils wegen der Komplexität der Neuverbindung, teils weil ich nicht genug Erfahrung mit dem Protokoll habe, um diese Konzepte in integrierter Form darzustellen.

Verbindungsaufbau​

Der Verbindungsaufbau funktioniert im Wesentlichen genauso wie in NWG/RFC #33. Die wesentliche Änderung besteht darin, dass eine allgemeinere Form des Umschaltens unabhängig vom Aufbau bereitgestellt wird, sodass der Aufbau vereinfacht wird, indem Umschaltprozeduren nicht einbezogen werden.

Es folgt ein grobes Szenario für den Verbindungsaufbau:

  1. Prozess PA in Host A belegt Socket SA und fordert eine Verbindung mit Socket SB an. Prozess PA erreicht dies durch einen Systemaufruf.

  2. Gleichzeitig mit dem oben Beschriebenen belegt Prozess PB in Host B Socket SB und fordert eine Verbindung mit Socket SA an.

  3. Als Antwort auf die Anforderung von Prozess PA sendet das Netzsteuerungsprogramm in Host A (als NCPA bezeichnet) ein Kommando zur Verbindungsanforderung (RFC) an Host B. NCPB in Host B sendet ein ähnliches Kommando an Host A. Es wird keine Reihenfolge impliziert: NCPB kann das Kommando an NCPA senden, bevor oder nachdem es das Kommando von NCPA empfängt.

  4. NCPA und NCPB wissen beide, dass die Verbindung hergestellt ist, wenn jeder ein RFC-Kommando empfangen hat und jeder den RFNM für das von ihm gesendete empfangen hat. Sie benachrichtigen dann die Prozesse PA bzw. PB, dass die Verbindung hergestellt ist.

Eine der befolgten Regeln ist, dass entweder SA ein Sendesocket und SB ein Empfangssocket ist oder umgekehrt. Diese Bedingung wird manchmal so formuliert: „SA und SB müssen ein Sende-/Empfangspaar sein.“

  1. Der sendende Prozess darf nun senden.

Flusskontrolle​

Um zu verhindern, dass ein sendender Prozess einen empfangenden Prozess überschwemmt, muss der empfangende Prozess in der Lage sein, den Fluss zu stoppen(*). Die Flusskontrolle ist in die RFNM-Behandlung des Netzwerks integriert. Wenn ein empfangender Host den Fluss auf einem bestimmten Link hemmen möchte, sendet der Host eine spezielle Nachricht an seinen IMP, die bewirkt, dass der nächste RFNM auf diesem Link geändert wird. Der sendende Host interpretiert diese Nachricht als einen RFNM und als eine Aufforderung, das Senden einzustellen. Ein bestätigendes Steuerkommando wird zurückgesendet.

Wenn der empfangende Host wieder bereit zum Empfangen ist, sendet er ein Kommando (RSM), das dem sendenden Host mitteilt, das Senden fortzusetzen.

Neuverbindung​

Aus sehr vielen Gründen ist es wünschenswert, ein (oder beide) Ende einer Verbindung von einem Socket auf ein anderes umschalten zu können. Je nach den Einschränkungen, die dem Umschaltvorgang auferlegt werden, kann es einfach oder schwierig zu implementieren sein. Um maximale Allgemeinheit zu erreichen, stelle ich hier ein Schema für die dynamische Neuverbindung vor, was bedeutet, dass eine Neuverbindung auch nach Beginn des Flusses stattfinden kann. Es kann sich herausstellen, dass dieses Schema für die Mehrheit der Fälle weit teurer ist als nötig; es werden jedoch die folgenden Vorzüge beansprucht:

  1. Alle verschiedenen Formen des Umschaltens von Verbindungen werden bereitgestellt.

  2. Die Neuverbindung verursacht keinen Mehraufwand bei der Verarbeitung von Nachrichten, die über eine Verbindung gesendet werden, d. h. die gesamten Kosten werden bei der Verarbeitung des Protokolls getragen.

*BB&N argumentiert, dass unbegrenztes Puffern bereitgestellt werden sollte. Es ist möglich, dass dies eine geeignete Strategie wäre: aber sie ist meiner Denkweise fremd, und ich habe den Protokollentwurf auf der Annahme aufgebaut, dass am Empfangsende jeder Verbindung nur ein kleiner Puffer bereitgestellt wird.