Zusammenfassung

  • Christopher Welles und Walter Milliken beschrieben im Juli 1984 mit RFC 909 ein Anwendungsprotokoll zum Laden, Auslesen und Debuggen entfernter Ziele. Ein Host konnte Speicher lesen, schreiben und Ausführung steuern; zu den denkbaren Zielen gehörten Paketvermittlungsknoten und Gateways. Die Autoren warnten, dass ein angehaltenes Ziel während der Wartezeit auf weitere Netzbefehle seine Echtzeitaufgaben verfehlen konnte.
  • Die Spezifikation ordnete die Fähigkeiten in einen kleinen Loader/Dumper, einen Basis-Debugger und einen vollständigen Debugger. Letzterer konnte bedingte Befehlslisten im Ziel ablegen und beim Ereignis lokal ausführen. Die Netzwartezeit sank, während Speicher- und Rechenbedarf der beobachteten Maschine stiegen.

Ein Werkzeug für Fehler kann selbst einer werden

Die klassische Debug-Szene hat ein klares Bild: Programm anhalten, Zustand lesen, nächsten Schritt wählen. Für ein isoliertes Testsystem ist das nützlich. Ein Gateway muss währenddessen Pakete anderer Menschen weiterleiten. Welles und Milliken benannten diesen Konflikt im Motivationsteil von RFC 909 ausdrücklich. Ein Haltepunkt, der das Ziel stoppt, während ein Host weitere Befehle schickt, ist wenig hilfreich, wenn das Ziel Echtzeitanforderungen seines eigentlichen Programms bedienen muss. Eine genaue Diagnose konnte zum Ausfall werden, den sie eigentlich vermeiden sollte.

Das vorgeschlagene Loader Debugger Protocol, kurz LDP, war mehr als ein Fernfenster für Protokolldateien. Ein Host führte die Sitzung mit einem Ziel wie einem Paketknoten, PAD oder Gateway. Über vierzig Befehle deckten Datenübertragung, Verwaltung, Steuerung und Haltepunkte ab. Man konnte Speicher lesen und schreiben, Daten verschieben, Ausführung beginnen und Ausnahmen empfangen. Unterschiedliche Adressierungsarten sollten zu unterschiedlichen Prozessoren passen. Je tiefer der Fernzugriff in das Gerät reichte, desto mehr Arbeit musste das Gerät selbst für die Untersuchung leisten.

Darum teilte der Entwurf seine Fähigkeiten auf. Ein Bootloader hat oft knappen Codeplatz. LOADER_DUMPER hielt Lesen, Schreiben, Verschieben, Starten und Ausnahmebehandlung in einem kleinen Satz. BASIC_DEBUGGER ergänzte Steuerbefehle und gewöhnliche Haltepunkte. FULL_DEBUGGER brachte Zustandsautomaten für Haltepunkte hinzu; Beobachtungspunkte blieben optional. Die Stufen bauten aufeinander auf. Nach dem Öffnen einer Transportverbindung schickte der Host HELLO; das Ziel meldete in HELLO_REPLY Version, Ausbaustufe, Systemtyp und Adressformat. Wer das Gerät untersuchte, musste dessen tatsächliche Fähigkeiten erfahren, bevor er es mit einem Befehl überforderte.

Der Befehl wartet schon am Ort des Ereignisses

Ein gewöhnlicher Haltepunkt stoppt das betroffene Objekt und meldet seinen Zustand an den Host. Die Entscheidung über die nächste Aktion kommt danach zurück über das Netz. Beim vollständigen Debugger konnte der Host bedingte Listen vorher im Ziel ablegen. Wenn eine bestimmte Adresse ausgeführt wurde, wählte eine lokale Zustandsvariable die passende Liste. Ein Zähler und zwei Zeiger unterstützten Bedingungen und Aktionen. Der Fernrechner entwarf die Regel; das Ziel setzte sie im Moment des Ereignisses um, ohne auf eine neue Runde über die Leitung zu warten.

Das Ziel zahlte für diesen Vorteil mit Speicher und Rechenzeit. Listen mussten aufbewahrt, Bedingungen geprüft und Befehle ausgeführt werden. RFC 909 ließ Beschränkungen bei Anzahl der Haltepunkte, Zustände, Bedingungen und Listengröße ausdrücklich zu. Einzelne Aktionen konnten weiterhin ein Objekt anhalten oder verändern. Das Design versprach keine unsichtbare Diagnose. Es verschob eine zeitkritische Entscheidung zum Gerät, das die Tatsache gerade beobachtete. Für einen laufenden Netzdienst war das eine wichtigere Eigenschaft als die bloße Menge der Debug-Befehle.

Jeder Halte- oder Beobachtungspunkt war einer Debug-Verbindung und einer Adresse zugeordnet. Mehrere Benutzer sollten dasselbe Ziel untersuchen können, soweit Ziel und Transportschicht mehrere Verbindungen unterstützten. Die Zuordnung verhinderte, dass die Befehle verschiedener Sitzungen gedanklich zu einer einzigen Konsole verschmolzen. Physisch teilten sie sich weiterhin begrenzten Speicher und begrenzte Rechenzeit im Gerät, das gleichzeitig seine Hauptaufgabe erfüllen sollte.

Der tote Host belegt den einzigen Platz

Eine LDP-Sitzung begann mit einer Transportverbindung, HELLO und HELLO_REPLY. Der Host schloss sie später; das Ziel sollte dann Sitzungsressourcen freigeben. Aber ein Host konnte mitten im Gespräch abstürzen. Bei einem Ziel mit nur einem Verbindungsplatz machte eine halb tote Verbindung den gesamten Debug-Zugang unbrauchbar, falls das Ziel sie nicht erkannte. Die Autoren schlugen Erkennung des Ausfalls oder Verdrängung einer inaktiven Verbindung durch eine neue vor. Auch für das Verdrängen musste das Ziel neue Verbindungswünsche hören können, während der alte Kanal noch bestand.

RFC 909 empfahl das Reliable Data Protocol aus RFC 908 als Transport und ließ TCP als ressourcenintensivere Möglichkeit zu. Gefordert waren zuverlässige, geordnete Nachrichten und eine klare Trennung der Verbindungen. Eine Transportnachricht durfte mehrere LDP-Befehle enthalten, jeder Befehl musste jedoch vollständig in einer Nachricht liegen. Damit kamen Anweisungen an. Wer den einzigen Platz hielt und wie lange ein Haltepunkt den Betrieb beeinträchtigte, war dadurch noch nicht entschieden.

RFC 909 wurde als experimenteller Vorschlag veröffentlicht. Die Schrift zählt keine tatsächlich ausgerüsteten Gateways. Ihr technischer Konflikt ist trotzdem scharf: Ein Instrument soll einem entfernten Menschen Kontrolle über eine lebende Netzmaschine geben, ohne deren laufende Arbeit zum Preis der Erkenntnis zu machen. Der schönste Haltepunkt ist kein Erfolg, wenn alle anderen während der Untersuchung auf ihre Pakete warten.

Quellen