IV. Das NCP
Wir betrachten das NCP als bestehend aus fünf Komponentenprogrammen, drei assoziativen Tabellen, einigen Warteschlangen und Puffern sowie einer Link-Zuordnungstabelle. Jeder Standort wird diesen Entwurf natürlich an seine Bedürfnisse anpassen, daher dient unser Entwurf nur der Veranschaulichung.
Die Komponentenprogramme
1. Der Eingabe-Handler
Dies ist eine interruptgesteuerte Eingaberoutine. Sie leitet die Imp-zu-Host-Übertragung in einen residenten Puffer ein und weckt den Eingabeinterpreter, wenn die Übertragung abgeschlossen ist.
2. Der Ausgabe-Handler
Dies ist eine interruptgesteuerte Ausgaberoutine. Sie leitet die Host-zu-Imp-Übertragung aus einem residenten Puffer ein und weckt den Ausgabe-Scheduler, wenn die Übertragung abgeschlossen ist.
3. Der Eingabeinterpreter
Dieses Programm entscheidet, ob die Eingabe eine für einen Benutzer bestimmte reguläre Nachricht, eine Steuernachricht, eine Imp-zu-Host-Nachricht oder ein Fehler ist. Für jede Nachrichtenklasse ergreift dieses Programm die entsprechende Maßnahme.
4. Der Ausgabe-Scheduler
An den Imp werden drei Klassen von Nachrichten gesendet
-
Host-zu-Imp-Nachrichten
-
Steuernachrichten
-
Reguläre Nachrichten
Wir sind der Ansicht, dass zwischen diesen Klassen eine Priorität festgelegt werden sollte. Die von uns vorgeschlagene Priorität entspricht der obigen Reihenfolge. Der Ausgabe-Scheduler wählt die Nachricht mit der höchsten Priorität aus und übergibt sie dem Ausgabe-Handler.
5. Der Systemaufrufinterpreter
Dieses Programm interpretiert Anforderungen des Benutzers.
Die beiden interessanten Komponenten sind der Eingabeinterpreter und der Systemaufrufinterpreter. Sie ähneln sich insofern, als der Eingabeinterpreter fremde Anforderungen und der Systemaufrufinterpreter lokale Anforderungen bedient.
Assoziative Tabellen
Wir stellen uns vor, dass der Großteil der Datenbasis des NCP in drei assoziativen Tabellen liegt. Mit „assoziativ“ meinen wir, dass es eine Suchroutine gibt, der ein Schlüssel übergeben wird und die entweder erfolgreich mit einem Zeiger auf den entsprechenden Eintrag zurückkehrt oder fehlschlägt, wenn dem Schlüssel kein Eintrag entspricht.
1. Die Rendezvous-Tabelle
„Verbindungsanforderungen“ und andere Attribute einer Verbindung werden in dieser Tabelle gehalten. Auf diese Tabelle wird über den lokalen Socket zugegriffen, doch andere Tabellen enthalten Zeiger auf vorhandene Einträge.
Die Bestandteile eines Eintrags sind:
-
lokaler Socket (Schlüssel)
-
fremder Socket
-
Link-Nummer
-
Warteschlange der Anrufer
-
Textwarteschlange
-
Verbindungszustand
-
Flusszustand
-
Zeiger auf den angeschlossenen Port
Ein Eintrag wird erzeugt, wenn ein Benutzer entweder einen Systemaufruf Init oder Listen ausführt oder wenn ein <RFC> empfangen wird. Manche Felder bleiben ungenutzt, bis die Verbindung hergestellt ist; z. B. ist der fremde Socket erst bekannt, wenn ein <RFC> eintrifft, falls der Benutzer ein Listen ausgeführt hat.
2. Die Eingangslink-Tabelle
Der Eingabeinterpreter verwendet den fremden Host und den Link als Schlüssel, um einen Zeiger auf den Eintrag in der Rendezvous-Tabelle für die Verbindung zu erhalten, die den eingehenden Link verwendet.
3. Die Ausgangslink-Tabelle
Um RFNMs zu interpretieren, benötigt der Eingabeinterpreter eine Tabelle in derselben Form wie die Eingangslink-Tabelle, die jedoch ausgehende Links verwendet.
Link-Zuordnungstabelle
Dies ist eine sehr einfache Struktur, die festhält, welche Links für jeden Host in Gebrauch sind. Ein Wort pro Host genügt wahrscheinlich.
Das folgende Diagramm zeigt unsere Vorstellung vom Netzsteuerungsprogramm. Kästen stellen Tabellen und Puffer dar, Kästen mit abgeschrägten Ecken und doppeltem Boden stellen Warteschlangen dar, gezackte Kästen stellen Komponentenprogramme dar, und die Pfeile stellen Datenpfade dar.
Die abgekürzten Namen haben folgende Bedeutungen.
-
ILT: Eingangslink-Tabelle
-
OLT: Ausgangslink-Tabelle
-
LAT: Link-Zuordnungstabelle
-
RT: Rendezvous-Tabelle
-
HIQ: Host-zu-Imp-Warteschlange
-
OCCQ: Warteschlange für ausgehende Steuerbefehle
-
ORMQ: Warteschlange für ausgehende reguläre Nachrichten
-
IHBuf: Puffer, der vom Eingabe-Handler aus dem IMP gefüllt und vom Eingabeinterpreter geleert wird
-
OHBuf: Puffer für ausgehende Nachrichten, der vom Ausgabe-Scheduler aus den Warteschlangen gefüllt und vom Ausgabe-Handler geleert wird.
+---------+
| I M P |
+---------+
v ^
| |
+---------------------------|-----|------------------------------+
| | | |
| /\/\/\/\/\/\/\ | | /\/\/\/\/\/\/\ |
| \ / <--------+ +---< \ / |
| / Input \ / Output \ |
| \ Handler / \ Handler / <----+ |
| / \ >------+ / \ | |
| \/\/\/\/\/\/\/ | \/\/\/\/\/\/\/ ^ |
| v +-----+ |
| +-----+ | OH | |
| | IM | | Buf | |
| | Buf | +-----+ |
| +-----+ /\/\/\/\/\/\/\/\ ^ |
| /\/\/\/\/\/\/\/\ v +----> \ / | |
| \ / | | / Output \ >--+ |
| / \ <------+ ^ \ / |
| \ Input / /-----\ / Scheduler \ |
| / \ >-------->| HIQ | \ / |
| \ Interpreter / |_____| / \ |
| / \ >----+ \_____/ \/\/\/\/\/\/\/\/ |
| \/\/\/\/\/\/\/\/ | ^ v ^ |
| ^ ^ ^ \ | /-----\ | | | /-----\ |
| | \ \ \ | | O | | | | | O | |
| | \ \ \ +--->| C |>----+ | +---<| R | |
| v v v \ | C | | | M | |
| +---+ +---+ +---+ \ | Q | v | Q | |
| | | | | | | \ |_____| +---------+ |_____| |
| |ILT| |LAT| |OLT| \ \_____/ | | \_____/ |
| | | | | | | \ ^ | R T | ^ |
| +---+ +---+ +---+ +------|-------->| | | |
| v | +---------+ | |
| | ^ ^ | |
| | /\/\/\/\/\/\/\/\ | | |
| | \ / | | |
| +----------->/ System \<-------+ | |
| \ Call / | |
| / Interpreter \>--------------------+ |
| \ / |
| +-->/ \>--+ |
| | \/\/\/\/\/\/\/\/ | |
+------------------|----------------------|----------------------+
| |
+---< system calls <---+
Hinweis: Dieser RFC wurde 1999 von Donald und Jill Eastlake in maschinenlesbare Form gebracht, um ihn in die Online-RFC-Archive aufzunehmen.
[Anmerkung des Herausgebers: Das ursprüngliche handgezeichnete Diagramm stellte Warteschlangen als Zylinder und Komponentenprogramme als „schwammige, amöbenartige Gebilde“ dar.]