Zusammenfassung

  • RFC 1761 machte das Snoop-Version-2-Dateiformat von Sun für andere Programme les- und schreibbar; Aufzeichnung und spätere Analyse konnten getrennt stattfinden.
  • Jedes Paket trägt getrennte Angaben zu empfangener und gespeicherter Länge. Null verworfene Pakete können auch bedeuten, dass die Aufzeichnungssoftware Verluste nicht zählen konnte.

Eine Datei liegt auf dem Tisch, also müsse der Fall doch geklärt sein. So beginnt manche Netzbesprechung mit mehr Zuversicht als Belegen. Brent Callaghan und Robert Gilligan veröffentlichten im Februar 1995 RFC 1761, damit andere Programme die von Sun entwickelte Snoop-Aufzeichnung erzeugen und auswerten konnten. Der praktische Gewinn war erheblich: Wer Pakete einsammelte, musste nicht auch die einzige Person sein, die sie später lesen konnte. Die Feldbeschreibung zeigt zugleich, wie begrenzt die Aussage eines perfekt geöffneten Mitschnitts sein kann.

Der Dateikopf umfasst sechzehn Oktette. Acht bilden die Kennung snoop mit drei Nulloktetten; vier nennen die Version 2; vier den Datenverbindungstyp. Ethernet hat den Code 4, IEEE 802.3 den Code 0. Diese Angabe legt fest, wie der Anfang der folgenden Paketdaten zu lesen ist, denn die gespeicherten Bytes beginnen mit dem Link-Header. Die Liste enthält auch Token Ring, HDLC und FDDI. Wer den Typ ignoriert, kann aus korrekt gespeicherten Bytes eine falsche Geschichte zusammensetzen.

Auf den Kopf folgen unterschiedlich lange Paketdatensätze. Am Anfang eines jeden stehen sechs 32-Bit-Zahlen, insgesamt 24 Oktette. Zahl eins ist die Originallänge des empfangenen Pakets. Zahl zwei ist die eingeschlossene Länge, also die tatsächlich abgelegten Bytes. Ist sie kleiner, wurde das Paket beim Speichern beschnitten. Dann kann ein Programm den vorhandenen Anfang noch so elegant anzeigen: Das abgeschnittene Ende ist weg. Der Mitschnitt enthält immerhin den Hinweis darauf, dass es fehlt.

Zahl drei beschreibt die Länge des gesamten Datensatzes. Sie umfasst den 24-Oktett-Kopf, die gespeicherten Paketbytes und mögliche Füllbytes. Mit ihr findet der Leser den nächsten Datensatz. Sämtliche Zahlen stehen in Big-Endian-Reihenfolge. Das klingt nach Buchhaltung für Bits; tatsächlich entscheidet es darüber, ob zwei unabhängige Programme dieselben Grenzen sehen. Wer Datenlänge und Datensatzlänge verwechselt, nimmt unter Umständen Füllmaterial als Beleg in die Akte auf.

Zahl vier ist der kumulative Verlustzähler der Aufzeichnungseinrichtung, gerechnet vom ersten bis zum aktuellen Datensatz. Hier steckt die unangenehme Pointe: Laut RFC können manche Implementierungen Verluste nicht zählen und tragen dann womöglich null ein. Die Null kann eine beobachtete Null sein oder die höfliche Maske eines fehlenden Zählers. Bevor sie im Abschlussbericht zur Aussage „kein Paket verloren“ wird, muss die Zählfähigkeit feststehen. Zudem misst das Feld Verluste beim Erfassen, nicht den Erfolg einer Anwendung beim Empfänger.

Die letzten zwei Zahlen geben die Ankunftszeit als Sekunden seit dem 1. Januar 1970 und Mikrosekunden an. So lassen sich die gespeicherten Pakete ordnen. Warum ein Dienst scheiterte und was andere Systeme sahen, erschließt sich erst im Abgleich. RFC 1761 machte Pakete als Datei transportierbar und beschrieb zugleich, welche Fragen der Transport allein offenlässt. Gerade das macht es zu einem guten historischen Dokument der Netzbeobachtung.