Zum Hauptinhalt springen

Einleitung

Wir halten den Meyer-Vorschlag (Note #46) für den bislang annehmbarsten, und zwar aus genau den Gründen, die er aufzählt, nämlich: einfach, ausreichend für die meisten geplanten Nutzungen des Netzwerks, leicht zu implementieren, erweiterbar. Er umfasst zwar nicht alles, was in jüngster Zeit vorgeschlagen wurde; wir stimmen jedoch den vorgeschlagenen Punkten zu und sind der Ansicht, dass die fehlenden Funktionen es wohl nicht wert sind, darum zu streiten und damit die Spezifikation zu verzögern.

Wir machen die folgenden Kommentare zu den sieben in Note #47 aufgeworfenen Fragen.

  1. Wir stimmen Steve darin zu, dass dynamische Wiederherstellung später für anspruchsvollere Nutzungen des Netzwerks erforderlich sein wird. Wir stimmen auch den Leuten von Project MAC darin zu, dass sie anfangs nicht notwendig ist. Mit etwas Erfahrung mit dem Netzwerk und den spezifischen Anforderungen seiner Nutzung lässt sich die dynamische Wiederherstellung besser bewerkstelligen.

  2. INT ist einfach zu implementieren und dient einem nützlichen Zweck.

  3. Wir befürworten die Aufnahme eines Unterfelds für die Instanz-Tag-Kennung. Wir sehen den Bedarf für beide Fälle: a) wenn mehrere Prozesse ununterscheidbar erscheinen sollen und b) wenn ein bestimmter Benutzer, der mehrere Prozesse besitzt, zwischen ihnen unterscheiden muss. Programmteile, die nicht zwischen Prozessen unterscheiden sollen, sollten das Instanz-Tag einfach ignorieren. Toms Vorschlag, einen Teil des Benutzernummer-Unterfelds zu verwenden, verringert lediglich die Gesamtlänge der Unterfelder von 32 Bit auf 24 Bit; das Problem bleibt bestehen.

  4. Wir stimmen weder Steve noch MAC darin zu, dass den übertragenen Daten keine besondere Struktur auferlegt werden sollte. Wir bevorzugen den von E. I. Ancona in Note #42, Seite 1, erwähnten „message data type“. Ein Beispiel für seine Verwendung wurde in Note #39, Seite 2, transmit vs broadcast angeführt. Für einen Standard-Zeichensatz gilt: wir befürworten nachdrücklich, von Anfang an einen einzigen anzunehmen, insbesondere ASCII. Wir haben beobachtet, dass die meisten Standorte zuvor ASCII vorgeschlagen haben. Gibt es jemanden, der Einwände erhebt?

  5. Wortgrenzen-Ausrichtung ist attraktiver als doppelte Auffüllung.

  6. Steves Vorschlag einer kurzfristigen Warteschlangenbildung für RFCs ist als Option akzeptabel.

  7. Wir unterstützen den UCC in Note #46 aus drei prinzipiellen Gründen:

    1. Im Allgemeinen sollte der Benutzer den entfernten Socket-Code des Prozesses, mit dem er kommunizieren möchte, nicht kennen.

    2. Die zusätzliche Duplex-Verbindung kann eine gewisse aufsichtführende Kontrolle über das Verhalten des Prozesses bieten, möglicherweise in Verbindung mit der Unterbrechungsprozedur.

    3. Die meisten der anderen vorgeschlagenen Methoden erfordern Warteschlangenbildung.

    Wir meinen, dass es einen Standard-UCC geben muss, ermutigen aber zu parallelen experimentellen UCCs.

Wir machen zwei zusätzliche Kommentare zu Note #46, die in Note #47 nicht wiederholt wurden.

BLK und RSM sind geradliniger als frühere Vorschläge und sie verneinen nicht das Multiplexen über eine gegebene Verbindung. Zur Nutzung von Verbindungen verweisen wir auf ein von Bob Kahn genanntes Beispiel, bei dem ein zwischengeschalteter IMP ausfällt und jemandes RFNM verschluckt. Dies sollte keine Wiederherstellung der Verbindung erforderlich machen.

In Note #46, Seite 6, ist die Aussage, dass der UCC die Fähigkeit hat, Verbindungen zu einem toten Prozess zu schließen, installationsabhängig. In unserem besonderen Fall wird der NCP direkt über den Ausfall eines Prozesses benachrichtigt, und zwar aufgrund der besonderen Softwareschnittstelle, über die alle Prozesse, einschließlich NCP, kommunizieren müssen.

JFH:hs

Hinweis: Dieser RFC wurde von Gary Okada 7/97 für die Aufnahme in die Online-RFC-Archive in maschinenlesbare Form gebracht.