Zusammenfassung

  • RFC 3321 machte eine explizite Bestätigung zum Nachweis, dass ein Zustand beim entfernten Dekompressor eingerichtet worden war.
  • Der Nachweis blieb an Zeitpunkt und Mechanismus gebunden: Speicherknappheit und spätere Erzeugungen konnten den Zustand löschen, während die alte Bestätigung lokal weiterbestand.

Ein Feld ohne selbstständige Bedeutung

RFC 3321 ließ SigComp-Nachrichten Informationen über bestätigte und gemeinsam genutzte Zustände tragen. Doch ein partieller Zustandsbezeichner erklärte sich nicht selbst. Die Implementierung musste ableiten, ob er einen bestätigten, geteilten oder global verfügbaren Zustand bezeichnete. Eine einfache SigComp-Implementierung durfte die erweiterten Bezeichner ignorieren. Selbst das Format des verbleibenden Nachrichtenteils blieb in wichtigen Bereichen Implementierungsentscheidung.

Damit beginnt die Beweisgrenze früher als bei einem gewöhnlichen Empfangsbeleg. Wer einen Wert in einer Paketaufzeichnung sieht, weiß noch nicht, welchen Zustand die Gegenstelle daraus ableitete. Dazu gehören der verwendete Mechanismus, die lokale Zuordnung, das Compartment und die Fähigkeiten der Implementierung. Und selbst wenn diese Bedeutung eindeutig war, blieb eine zweite Frage offen: War der Zustand beim späteren Gebrauch noch vorhanden?

RFC 3321 erschien im Januar 2003 als Informational. Es beschrieb erweiterte SigComp-Operationen auf Grundlage der UDVM aus RFC 3320, ohne Standardstatus, Verbreitung oder gemessenen Nutzen zu behaupten. Die Mechanismen sollten dynamische und gemeinsame Kompression ermöglichen. Ihre Voraussetzung war ein ausreichend genaues Modell des entfernten Speichers.

Bestätigung schloss eine Lücke, nicht alle

Bei dynamischer Kompression baut eine neue Nachricht auf Informationen aus früheren Nachrichten auf. Der Kompressor muss deshalb wissen, dass der entfernte Dekompressor den benötigten Zustand eingerichtet hat. acked_state_id bezeichnet einen erfolgreich gespeicherten Zustand. RFC 3321 verlangt, nur entfernte Zustände zu verwenden, die dort etabliert sind; andernfalls droht Dekompressionsfehler.

Auf unzuverlässigem Transport schließt die explizite Bestätigung die Lücke zwischen Senden und Ankommen. Bei TCP ist der Empfang früherer Nachrichten zuverlässig. Weder Transportzuverlässigkeit noch Zustandsbestätigung reservieren jedoch unbegrenzt Speicher. Sie beantworten nicht, was spätere Zustandserzeugungen und Löschregeln mit den gespeicherten Bytes tun.

Der Unterschied grenzt diese Untersuchung vom RFC-3320-Artikel ab. Dort ging es darum, dass erfolgreiche Dekompression keine Berechtigung zur Erzeugung dauerhaften Zustands ist. Hier sind Erzeugung und Bestätigung bereits erfolgt. Die offene Frage lautet, wie lange diese vergangene Bestätigung eine gegenwärtige Referenz rechtfertigt.

Ein Checkpoint ist bevorzugt, nicht unsterblich

RFC 3321 nennt drei Ursachen für einen nicht vorhandenen Zustand: Die erzeugende Nachricht ging verloren; beim Speichern fehlte Speicher; oder der Zustand wurde erfolgreich eingerichtet und später wegen Speichermangels gelöscht. Der dritte Fall erlaubt zwei zugleich wahre Aufzeichnungen: eine positive Bestätigung früher und STATE_NOT_FOUND später.

Ein Checkpoint erhält die höchste vom gleichen Kompressor gesendete Aufbewahrungspriorität und muss explizit bestätigt werden. Trotzdem muss der Kompressor den verfügbaren Speicher der Gegenstelle verfolgen. state_memory_size kann helfen abzuleiten, ob ein neuer Checkpoint einen älteren verdrängte. Der Wert ist keine Liste vorhandener Bezeichner. Er ist eine Kapazitätsangabe, die erst mit Reihenfolge, Alter und Priorität zu einer Aussage über einen bestimmten Zustand wird.

Die implizite Bestätigung hatte ein Rennen

Gemeinsame Kompression speichert die unkomprimierte Fassung einer Nachricht als geteilten Zustand. RFC 3321 beschreibt eine Optimierung, bei der die spätere Nutzung dieses Zustands implizit bestätigt, dass ein verwandter Zustand an der Gegenstelle erzeugt wurde. Ein gesonderter acked_state_id kann entfallen.

Doch die Ankündigungsinformation kann erfolgreich weitergegeben werden, obwohl der referenzierte Zustand wegen fehlenden Speichers verworfen wird. Das Signal überlebt sein Objekt. Wer es als fortdauernde Zusage liest, erzeugt mit der nächsten Referenz den Dekompressionsfehler. Das Dokument verweist wiederum auf state_memory_size, um eine fehlgeschlagene oder nicht mehr tragfähige Zustandsannahme abzuleiten.

Diese Warnung zeigt, warum das Mapping zwischen Zuständen Teil der Evidenz ist. Für die Optimierung muss die lokale Zustandsverwaltung wissen, welcher gemeinsame Zustand zu welchem erzeugten Zustand gehört. Geht diese Zuordnung verloren oder wird ihre Zeitordnung nicht protokolliert, bleibt nur ein scheinbar bestätigter Identifikator ohne belastbare aktuelle Bedeutung.

Die spätere Korrektur machte Regelkonformität nicht gleich Gewissheit

RFC 4896 klärte die ungewöhnliche Prioritätsordnung: 65535 liegt unter 0, danach folgen 1 bis 65534. Die Priorität hängt an der Referenz eines Compartments. Mehrere Compartments können dieselben Zustandsbytes mit unterschiedlichen Prioritäten behandeln.

Bei mehreren Zuständen mit Minimalpriorität kann der Kompressor nicht sicher wissen, welche Stücke im entfernten Compartment verbleiben. Ein neu erzeugter Zustand kann einen alten früher als erwartet herausdrängen, obwohl beide Endpunkte die Regeln korrekt ausführen. RFC 4896 folgert, der Kompressor solle keinen Zustand referenzieren, wenn er nicht sicher ist, dass er existiert.

Auch eine Anzeige hat einen begrenzten Inhalt: Sie belegt erfolgreiche Erzeugung und Verfügbarkeit mindestens für die durch Alter und Aufbewahrungspriorität definierte Lebensdauer. Sie hebt die Löschregeln nicht auf. Der scheinbar technische Zusatz „mindestens für diese Lebensdauer“ ist die Grenze zwischen Beleg und Besitzgarantie.

RFC 4077 gab dem späteren Scheitern mit STATE_NOT_FOUND einen Namen. Die NACK enthält den Bezeichner des nicht auffindbaren Zustands; der Kompressor wird ihn gewöhnlich künftig vermeiden. Das ist kein Urteil über die Ehrlichkeit der ursprünglichen Bestätigung. Es ist eine neuere Beobachtung in einer zeitlichen Beweiskette.

RFC 3321 erzählt damit eine allgemeine Geschichte verteilter Systeme. Positive Evidenz schafft Handlungsfähigkeit, aber keine zeitlose Wahrheit. Wer Mechanismus, Zeitpunkt und Löschereignisse nicht mit dem Beleg aufbewahrt, verwandelt eine korrekte Bestätigung in eine unprüfbare Behauptung über die Gegenwart.

Sources