Zusammenfassung

  • Eine History Number wählt einen ausgehandelten Kompressionsspeicher. Reihenfolge, Prüfzähler und Reset-Signale gelten je History; verschiedene Histories müssen nicht gegeneinander sortiert werden.
  • C/U=0 bezeichnet die unveränderte Darstellung der Daten. Process-Uncompressed kann dieselben Bytes dennoch in beide History-Kopien übernehmen.
  • Sequenznummer, LCB und Reset-Ack decken verschiedene Übergänge ab. Keiner rekonstruiert Verluste oder belegt die Übergabe an eine PPP-Oberinstanz.

Wenn die Ausgabe größer wird als die Eingabe

Stac LZS kann Daten um bis zu 12,5 Prozent vergrößern. Überschreitet die komprimierte Ausgabe samt Header die MRU des Peers, schreibt RFC 1967 ein unkomprimiertes LZS-DCP-Paket vor.

Im Modus None hat der Sender zwei Kosten zur Wahl: Er kann die vergrößerte Fassung senden und die History behalten, oder Originaldaten senden und die History löschen. Process-Uncompressed eröffnet die dritte Möglichkeit: Originalbytes senden und sie an beiden Enden in die History einarbeiten. Die momentane Bandbreite bleibt geschont, ohne den künftigen Kontext zu verlieren.

Der RFC-Editor-Eintrag und der IETF Datatracker führen den Text als Informational RFC vom August 1996, ausdrücklich nicht als Internetstandard. Ausgangspunkt war das Nicht-DCP-Profil aus RFC 1974.

Getrennte Histories, getrennte Fehler

History Count 0 löscht den einzigen Speicher vor jedem Datagramm und setzt auf allen ausgehenden Paketen R-A. Das Verfahren braucht weder vorherige Pakete noch deren Reihenfolge, erreicht aber weniger Kompression als ein Strom mit Gedächtnis.

Count 1 hält einen fortlaufenden Zustand. Ab zwei bekommt jede History einen eigenen Speicher, Fehlerprüfzustand und Signalzustand. Nur innerhalb derselben Nummer gilt Ordnung. Das Feld ist bei 2–255 Histories ein Oktett und ab 256 zwei; bei Mehrfach-Histories steht es in komprimierten wie unkomprimierten Paketen beider Richtungen.

Eine History kann laut RFC eine logische Verbindung darstellen. Das ist ein Beispiel, keine Drahtidentität. Weder Kunde noch Anwendung, Transaktion oder Fünf-Tupel sind im Feld codiert.

Ein Reset wartet auf Nutzdaten

Der DCP-Header trägt C/U, R-R und R-A. Anders als die allgemeine CCP-Ebene von RFC 1962 gelten diese Bits für die History Number des Pakets und werden vor dessen Data verarbeitet.

Nach einem Empfangsfehler sendet der Empfänger R-R für die fehlerhafte History. Das Paket darf normalen Gegenrichtungsverkehr enthalten. Der Peer löscht den genannten Kompressor und sendet R-A erst in einem Paket mit Data; ohne sendebereite Daten wartet er.

R-A sagt genau, dass die History unmittelbar vor der Kompression des Inhalts dieses Pakets leer war. Der Sequenzzähler des Senders läuft weiter, der Empfänger richtet seine Erwartung am R-A-Paket neu aus. Bis dahin verwirft er Daten derselben History und wiederholt R-R bei Bedarf. Andere Histories bleiben unberührt.

Die gemeinsame Ausgangslage wird repariert, nicht die Vergangenheit. Verlorene, fehlerhafte oder falsch geordnete Datagramme werden nicht wiederhergestellt.

Prüfungen mit begrenzter Reichweite

Die einoktettige Sequenz beginnt bei 1 und läuft modulo 256 für datenführende Pakete einer History. Sie findet unerwartete Abfolgen, prüft aber keinen Inhalt. Der LCB XOR-verknüpft 0xFF mit dem ursprünglichen Datagramm und wird nach der Dekompression verglichen. Er ist nur auf komprimierten Daten erlaubt, nur ein Oktett breit und nicht kryptographisch.

Link-FCS und der zuverlässige nummerierte Modus aus RFC 1663 beantworten andere Fragen. Die IANA-PPP-Tabelle belegt Codepunkt-Zuweisungen, nicht eine funktionierende Sitzung.

Nach erfolgreicher Dekompression muss PPP nach RFC 1661 das rekonstruierte Paket noch annehmen und weiterreichen; erst danach kann eine Anwendung quittieren. RFC 1990 ordnet Multilink-Fragmente mit B/E und eigenen Sequenzen und liegt außerhalb der LZS-History. RFC 1977 mit BSD Compress, LZW und CLEAR bleibt Gegenstand eines anderen Beitrags.

Die Errata-Seite lieferte bei der Erhebung keinen verwertbaren Inhalt; eine leere Errata-Menge wird nicht behauptet. RFC 1967 selbst behandelt Sicherheitsfragen nicht.

Heng Lus Texte über Running-Code Primacy, Minimum Initial Specification, Reality Layers und Reality, Not Advocacy liefern die redaktionelle Regel, Spezifikation, Ausführung und Ergebnis zu trennen. Sie sind keine historischen Quellen zu LZS-DCP.