I. Fehler und Überlauf

Im Einklang mit der Diskussion in NWG/RFC #48 waren wir der Ansicht, dass zwei Arten von Fehlern unterschieden werden sollten. Die eine ist ein echter Fehler, etwa eine RFC, die aus zwei Sendesockets besteht. Diese Art von Fehler kann nur von einem fehlerhaften NCP erzeugt werden. Fehlen Fehler in Hardware und Software, dürften diese Ereignisse nie auftreten; die richtige Reaktion auf die Feststellung eines solchen Ereignisses wurde in der Beschreibung des ERR-Befehls in NWG/RFC #54 skizziert.

Der andere „Fehler“ ist ein Überlaufzustand, der entsteht, weil endliche Systemressourcen erschöpft sind. Ein Überlaufzustand könnte eintreten, wenn eine RFC empfangen wurde, aber kein Platz vorhanden war, um die erforderlichen Tabellen und Warteschlangen anzulegen. Dies ist kein echter Fehler, insofern niemand etwas Falsches getan hat (abgesehen vielleicht von den Systemplanern, die nicht genügend Tabellenplatz usw. vorgesehen haben). Ferner lässt sich ein Wiederherstellungsverfahren klar definieren; es besteht einfach darin, die Anforderung zu einem späteren Zeitpunkt zu wiederholen. Daher sind wir der Auffassung, dass ein Überlaufzustand von einem echten Fehler unterschieden werden sollte.

In NWG/RFC #54 wurde ein Überlaufzustand dadurch gemeldet, dass ein CLS zurückgesandt wurde, als sei die Verbindung abgelehnt worden. Diese Sequenz erfüllt die notwendigen Funktionen und lässt die Verbindung im korrekten Zustand zurück, doch der initiierende Benutzer wird falsch informiert. Er wird zu der Annahme verleitet, dass der fremde Prozess ihn abgelehnt hat, obwohl dies in Wirklichkeit nicht der Fall war. Bei bestimmten Algorithmen ist dieser Unterschied entscheidend.

Bei der weiteren Bestimmung der Fehlerbedingungen waren wir der Ansicht, dass es hilfreich wäre, neben der Angabe, was den Fehler verursacht hat, auch anzugeben, warum der Fehler festgestellt wurde. Bei der Erstellung des in NWG/RFC #55 erwähnten Pseudo-Algol-Programms unterschieden wir 9 Arten von Fehlern (unten aufgeführt). Daher möchten wir vorschlagen, die ERR-Nachricht um ein 8-Bit-Feld zu erweitern, das dem Op-Code folgt und die Art des Fehlers bezeichnet. Danach folgen – wie bisher – die Felder für Länge und Text. Wir schlagen diese Fehlertypen vor;

UNSPECIFIED ERROR
HOMOSEX (ungültiges Paar aus Sende- und Empfangssocket in einer RFC)
ILLEGAL OP CODE
ILLEGAL LEADER (unzulässiger Nachrichtentyp usw.)
ILLEGAL COMMAND SEQUENCE
ILLEGAL SOCKET SPECIFICATION - COMMAND
ILLEGAL COMMAND LENGTH (der letzte Befehl in der Nachricht war zu kurz)
CONNECTION NOT OPEN - DATA
DATA OVERFLOW (Nachricht länger als der angegebene verfügbare Pufferspeicher)
ILLEGAL SOCKET SPECIFICATION - DATA (Socket existiert nicht)

Im Licht der zuvor erwähnten weiteren Überlegungen möchten wir auch einen zusätzlichen Steuerbefehl vorschlagen, der einen Überlauf anzeigt:

        +-------------+-------------------+---------------------+
        |     OVF     |     my socket     |     your socket     |
        +-------------+-------------------+---------------------+

Das Format der Nachricht ähnelt dem der CLS-Nachricht, die sie in diesem Zusammenhang ersetzt. Die Socketnummern sind 32 Bit lang und entsprechen den Socketnummern in der RFC, die zurückgewiesen wird. Die Semantik eines eingehenden OVF sollte der eines eingehenden CLS entsprechen; darüber hinaus sollte der Benutzer darüber informiert werden, dass er nicht abgewiesen wurde, sondern die Ressourcen des fremden Hosts übermäßig in Anspruch genommen hat.

Eine Alternative zur Einführung eines separaten Steuerbefehls ließe sich verwirklichen, wenn man die Ähnlichkeit zwischen einem CLS und einem OVF betrachtet. Denkbar wäre, dem CLS-Befehl ein 8-Bit-Feld hinzuzufügen, das seine Herkunft definiert. Wir glauben jedoch, dass diese Alternative konzeptuell schlechter und praktisch schwieriger zu implementieren ist.

Ein Überlauf erfordert keine ernsthafte Betrachtung, wenn er ein deutlich seltenes Ereignis ist. Wir glauben nicht, dass dies der Fall sein wird, und wir glauben ferner, dass sein Fehlen eine unnötige Einschränkung für den Benutzer wäre.