Einleitung

Das Protokoll sieht ein Verfahren zur Pufferzuordnung vor. Dieses Verfahren ist recht kompliziert, weil es zwei parallele Mechanismen erfordert. Es ist nicht offensichtlich, dass beide notwendig sind. Tatsächlich wird angeregt, dass dieses Verfahren wohl durch eine etwas andere Auffassung der Anforderung der nächsten Nachricht (RFNM) ersetzt werden könnte. Nun wird die RFNM vom empfangenden IMP zurückgesendet, nachdem die Nachricht wiederhergestellt und das erste Paket an den Host übertragen worden ist. Nichts gewährleistet, dass die gesamte Nachricht vom Host angenommen und korrekt empfangen wurde; außerdem erlaubt die Gestaltung der Host/IMP-Schnittstelle dem Host, während beliebiger Dauer keine Daten mehr vom IMP anzunehmen; da die Verbindung durch das Zurücksenden der RFNM bereits entsperrt wurde, kann vom sendenden fremden Host eine weitere Nachricht übertragen werden, welche den Speicher des IMP überlastet. Andererseits ist es wahrscheinlich, dass der Host üblicherweise Daten vom IMP mit einer höheren Rate annehmen kann, als sie im Netz übertragen werden, z. B. 200k Bit/s; die Zeit, eine vollständige Nachricht vom IMP zum Host zu übertragen, betrüge daher etwa 1/20 Sekunde, somit 10-mal weniger als die mittlere Übertragungsverzögerung einer Nachricht im Netz. Dies deutet darauf hin, dass das Senden einer RFNM nach dem Empfang einer vollständigen Nachricht durch den Host die Antwortzeit im Netz nicht wesentlich erhöhen würde.

In diesem Fall gibt es keinen Grund, warum die RFNM nicht vom empfangenden Host als Bestätigung des korrekten Empfangs der Nachricht (ACK) ausgelöst werden und die Form einer Host/IMP-Nachricht oder einer Steuerkommandonachricht annehmen könnte. Diese RFNM könnte die beiden Formen haben

         ACK  (CONTINUE)
or       ACK  (CEASE)

Damit ließe sich den Nachrichten eine gewisse Fehlererkennungsredundanz hinzufügen, etwa Prüfsummenbits, wie in [DELO 69] vorgeschlagen. Beim derzeitigen Entwurf gewährleistet nichts, dass ein oder mehrere Bits des Textes nicht verändert wurden, etwa durch eine Störung oder einen Defekt einer der Host/IMP-Schnittstellen. Dies könnte erhebliche Folgen haben, etwa wenn der Text zum Aktualisieren einer zentralen Datenbank dient. Wenn der Benutzer außerdem eine Möglichkeit hat, den Fehler zu erkennen, aber keine, ihn zu korrigieren, so hat er keine Möglichkeit, die erneute Übertragung der Nachricht zu verlangen, die beim Empfang der RFNM am sendenden Ende wahrscheinlich bereits verworfen wurde. Tatsächlich scheint es nicht Sache des Benutzers zu sein, Fehler in seinem Text zu erkennen, sondern Sache des NCP: Der Benutzerprozess muss sich so weit wie möglich so verhalten, als spräche er mit einem anderen lokalen Prozess. Eine dritte Art von RFNM, die vom NCP gesendet wird, könnte daher lauten:

            NAK(REPEAT)

Eine Wiederholung würde auch dann ausgelöst, wenn keine Antwort erfolgt.

Wir sehen somit, dass es sich lohnt, diese geringfügigen Änderungen vorzunehmen, die es ermöglichen würden, zwischen dem sendenden Host und dem empfangenden Host ein sehr einfaches Punkt-zu-Punkt-Übertragungsverfahren zu verwenden, welches die Kontrolle der übertragenen Daten von Ende zu Ende gewährleistet.

Es könnte auch den Mechanismus der Speicherzuordnung ersetzen: ACK (CONTINUE) würde nur gesendet, wenn auf dieser Verbindung Platz für eine neue Nachricht verfügbar ist, und/oder ACK (CEASE) würde gesendet, wenn kein Platz mehr verfügbar ist; dies entspricht dem WABT klassischer Übertragungsverfahren [USAS69]; die Übertragung könnte durch ein ACK (CONTINUE) oder ein RESUME vom empfangenden Ende wieder aufgenommen werden. Der Benutzerprozess ist an dieser Speicherzuordnung, die eine Aufgabe des Systems (oder des NCP) ist, überhaupt nicht beteiligt: er sieht nur eine sich ändernde globale Übertragungsgeschwindigkeit seiner Daten auf einer Verbindung. Die IMP-Programme kümmern sich um die Wegewahl der Daten entsprechend der verteilten Natur des Netzes, und weder der Benutzer noch das System (oder der NCP) muss sich darum kümmern. Weitere Verbesserungen des Protokolls mögen nach der Erprobung gefunden werden.

Abschließend ist festzustellen, dass diese Lösung den Speicher des IMP nicht länger belegt als die derzeitige Lösung, weil nicht das IMP eine Nachricht wiederholen muss, sondern der sendende Host.

DELO 69 DELOCHE G.  Implementation of the Host-Host Software
        Procedures in GORDO Network Working Group RFC #11 Aug 1969

USAS 69 Proposed USA standard data communication control procedures
        for USASCII CACM Vol. 12 NB 3 March 1969 PB 166-178

Hinweis: Dieser RFC wurde von Kai Henningsen 6/97 für die Aufnahme in die Online-RFC-Archive in maschinenlesbare Form gebracht.