要約

  • RFC 1761はSunのSnoop Version 2キャプチャーファイルを公開し、採集した人と後で解析する人が別のプログラムを使えるようにした。
  • 一つの記録には受信したパケットの長さと実際に保存した長さが別々に入り、累積廃棄数のゼロは計数不能を隠している場合がある。

障害調査でファイルを開けた瞬間、会議室の空気は少しだけ楽になる。記憶より頼れるものが現れたからだ。だが「開ける」と「すべて見えた」の間には距離がある。Brent CallaghanとRobert Gilliganが1995年2月に書いたRFC 1761は、Sunが開発したSnoopの保存形式を他のプログラムにも読ませるための文書だった。その説明をたどると、ファイル自身が欠けた証拠の場所をいくつか教えてくれる。

最初の16オクテットはファイルの表札だ。八つの識別オクテットはSnoopではなく小文字のsnoopと三つのヌル値。続く四つは版番号2、さらに四つはリンク層の種類を表す。Ethernetは4、IEEE 802.3は0。記録内のパケットデータはリンク層ヘッダーから始まるので、この番号を読み違えるとその先の解釈もずれる。Token Ring、HDLC、FDDIなども一覧にある。異なる解析器が同じ入口に立つための情報が、ここに置かれている。

その後は可変長のパケット記録が続く。各記録の先頭には32ビット整数が六つ、合計24オクテット。その一番目がネットワークから受け取ったパケットの元の長さ、二番目がファイルへ含めた長さだ。後者が短ければ、採集時に切り詰めたということになる。ヘッダーだけきれいに見えても、失われた末尾のフィールドを後から推理だけで取り戻すことはできない。

三番目は記録全体の長さ。24オクテットの説明部分、保存データ、必要なら末尾の詰め物まで含む。次の記録の先頭を探すための道しるべだ。整数はすべてビッグエンディアンで並ぶ。こうした地味な約束を破れば、詰め物がデータに見えたり、次のパケットが前のものに飲み込まれたりする。互換性とは華やかな宣言ではなく、境界を同じ位置で数える技術である。

四番目の累積廃棄数が最も手ごわい。最初の記録から現在の記録までに、採集システムが失ったパケット数を表す。ところがRFCは、廃棄を数えられない実装がゼロを設定する場合を明記している。ゼロは「損失を数えなかった」かもしれないし、「数える仕組みがなかった」かもしれない。ここを確認せずに通信に欠落はなかったと宣言すれば、計器のない机で「針は動かなかった」と言うようなものだ。

残る二つは到着時刻で、1970年1月1日からの秒数とマイクロ秒数に分かれる。保存済みパケットの順序を追うには有用だ。ただし、アプリケーションでの受理や相手側への到達は別の記録が要る。Snoopの形式は1995年に、ネットワークの証言を持ち運びやすくした。同時に、その証言が聞き取れなかった部分まで記録の読み方に織り込んだ。