Zusammenfassung

  • Eine Verzeichniszeile sagte in RFC 2024, wo ein DLSw-Knoten eine MAC-Adresse oder einen NetBIOS-Namen für erreichbar hielt; sie meldete keine aktive Endstationsleitung.
  • Transport, Leitung, Taktsteuerung und Trennungsdaten beantworteten verschiedene Fragen und mussten als Beweiskette erhalten bleiben.

„Ist diese Ressource erreichbar?“ klingt nach einer einzigen Frage. RFC 2024 gab mehrere Antworten. Das Verzeichnis nannte einen Standort. Die Transporttabelle zeigte, ob zwei DLSw-Peers ihren Fähigkeitsaustausch abgeschlossen hatten. Die Leitungstabelle verfolgte einen Pfad zwischen Endstationen. Taktfelder erfassten, wie viele SSP-Nachrichten vor einer Wartephase noch gesendet werden durften. Kein Datensatz erzeugte den Zustand, den ein anderer beschrieb.

Das Verzeichnis speicherte eine lokale Annahme

Die MAC- und NetBIOS-Verzeichnisse verbanden jede Ressource mit einem Standortzeiger. Dieser konnte auf eine lokale Schnittstelle, eine konfigurierte Transportverbindung, eine operative Verbindung, eine Nullreferenz oder eine implementierungsspezifische Tabelle weisen. Der Zustand unbekannt, erreichbar oder nicht erreichbar beschrieb, was DLSw zu diesem Zeitpunkt über den Zugang an diesem Ort annahm.

Die statischen Beispiele bleiben zurückhaltend. Ein Eintrag konnte unbekannt beginnen. Dieselbe entfernte Ressource ließ sich über mehrere Partner führen. Die Reihenfolge der Kandidaten war nicht garantiert; bei gleich spezifischem statischem und dynamischem Wissen durfte die Implementierung entscheiden. Nach einer fehlgeschlagenen Suche konnte „nicht erreichbar“ vor allem weitere sofortige Suchläufe verhindern.

Das Verzeichnis verkleinerte also den Suchraum. Es bewies weder die Verbindung des ausgewählten Peers noch den Beginn des Leitungsaufbaus oder eine Antwort der Endstation.

Der Transport hatte seine eigene Zeitachse

Die operative Verbindung unterschied unter anderem Aufbau, anfänglichen Fähigkeitsaustausch, verbunden, Beruhigung, Trennung und getrennt. Verbunden bedeutete, dass die Peers ihre Fähigkeiten bestimmt hatten und für Nachrichten zum Leitungsaufbau bereit waren. Es war kein Ende-zu-Ende-Ergebnis.

Auch die Verbindung zur Konfiguration konnte altern. dlswTConnOperConfigIndex verwies auf die maßgebliche Konfigurationszeile, wurde aber null, wenn diese gelöscht wurde. Eine Änderung nach dem Verbindungsaufbau musste nicht alle zuvor ausgehandelten Bedingungen widerspiegeln. Verbindungszeit und letzte Konfigurationsänderung gehörten deshalb zusammen.

Eine Implementierung durfte die operative Zeile nach der Trennung für Statistiken und Fehlergründe behalten, ohne festgelegte Aufbewahrungsdauer. Vom Partner empfangene Fähigkeiten konnten dort weiter lesbar sein. Ein gefülltes Feld in einer historischen Zeile war kein Nachweis aktueller Verfügbarkeit.

Die Leitung begann erst nach der Suche

RFC 2024 trennte zwei Phasen. Explorer lokalisierten zuerst Adresse oder Namen; danach begann der Leitungsaufbau. Erst dann entstand eine Zeile in der Leitungstabelle.

Die Leitung durchlief eine eigene Zustandsfolge. Nur disconnectPending war setzbar; einen Verwaltungsbefehl zum Wiederaufbau gab es nicht, weil die Endstationen den Aufbau anstießen. Trennungsgründe und Zeiger in darunterliegende LLC- oder SDLC-MIBs grenzten die Suche ein. Manche Verkehrsstatistiken verlangten ebenfalls diesen Sprung. Es waren Spuren, kein selbständiger Ursachenbericht.

Taktkredite hatten eine ebenso enge Bedeutung: wie viele getaktete SSP-Nachrichten eine Seite vor dem Anhalten senden durfte. Null konnte auch bedeuten, dass keine Taktung eingesetzt wurde. Ein aktuelles oder größtes Fenster zählte weder zugestellte Nachrichten noch erledigte Anwendungsarbeit.

Eine Meldung erfasste einen Übergang

Beim Eintritt von Transport oder Leitung in „verbunden“ konnte eine Trap gesendet werden. Ihre Erzeugung war konfigurierbar und abschaltbar. Eine empfangene Trap bewies, dass ein lokaler Agent einen Übergang meldete und die Meldung ankam. Sie bewies nicht die Dauer des Zustands, die Übereinstimmung des anderen Peers oder das Ausbleiben einer späteren Trennung. Schweigen bewies umgekehrt nicht, dass es keinen Übergang gab.

Trennungszeit, Grund und die Anzeige aktiver Leitungen präzisierten einen Vorfall. Letztere sagte, dass Endnutzer betroffen gewesen sein könnten; sie zählte sie nicht und belegte keinen Geschäftsschaden. RFC 2166 ergänzte RFC 1795 später um breite HALT-Gründe, etwa Trennung durch die Endstation, DLC-Fehler, Leitungsprotokollfehler und Eingriffe des Betreibers. Ältere Peers konnten den Grund auslassen, Herstellerdetails variierten. Die Spur wurde besser, nicht endgültig.

Das Gesamtbild konnte auf beide Knoten verteilt sein

RFC 2024 erklärte, dass ein vollständiges Bild Abfragen mehrerer DLSw-Knoten erfordern konnte. Um Dopplungen zu vermeiden, wurden einige Informationen als vom Partner empfangen definiert. Das Protokoll bot außerdem keine Methode, die verwaltete Transportadresse des Partners seiner Managementadresse sicher zuzuordnen.

Jede Zeile war damit eine lokale Aussage mit Reichweite. Heng Lus Unterscheidung zwischen einem Datensatz und der von ihm beschriebenen Wirklichkeit bietet eine heutige Lesart: Der Datensatz kann korrekt sein, ohne den gesamten Betriebszustand zu enthalten. Das ist eine analytische Anwendung, keine unterstellte Absicht der RFC-Autoren.

Die Tabellen sind nicht schwach; ihre Verknüpfungen sind entscheidend. Das Verzeichnis stützt die Standortannahme, der Transport Peer-Zustand und Aushandlungszeit, die Leitung den Endstationspfad, die unteren MIBs die lokalen Übertragungsspuren. Mit Indizes, Zeiten und beiden Peer-Sichten erklären sie den Dienst. Als einzelne grüne Leuchte verdecken sie ihn.

Quellen