Résumé

  • Le RFC 1761 a publié le format des captures Snoop Version 2 pour que d’autres logiciels puissent produire et relire les fichiers de Sun.
  • La taille du paquet reçu, celle des octets conservés et le total des pertes forment trois informations différentes ; un total nul peut aussi signaler une incapacité à compter.

Un fichier de capture arrive à une réunion avec un avantage sur tous les témoins : il se laisse ouvrir une deuxième fois. L’équipe qui a recueilli les paquets peut passer le relais à celle qui les analysera. Voilà précisément l’intérêt que Brent Callaghan et Robert Gilligan attribuent au format de Sun dans le RFC 1761, daté de février 1995. En rendant le fichier lisible par des programmes compatibles, ils ont aussi décrit les limites que ces programmes devront afficher. Le classeur bien étiqueté n’a jamais promis que toutes les pièces y figuraient.

Le dossier commence par un en-tête de seize octets. Les huit premiers forment snoop suivi de trois octets nuls ; quatre indiquent la version 2 ; quatre donnent le type de liaison utilisé pour les paquets. Ethernet porte le code 4, IEEE 802.3 le code 0. Cette différence commande la lecture du début de chaque paquet : les données conservées commencent par l’en-tête de liaison. Token Ring, HDLC ou FDDI ont leurs propres codes. L’en-tête donne un contexte commun au fichier, pas une étiquette individuelle improvisée pour chaque ligne.

Viennent des enregistrements de longueur variable. Chacun débute par vingt-quatre octets descriptifs, soit six entiers de 32 bits. Les deux premiers invitent à se méfier du joli affichage : la longueur d’origine correspond au paquet reçu sur le réseau ; la longueur incluse mesure ce que le fichier en garde. Si la seconde est inférieure à la première, la capture a coupé le paquet. Un analyseur peut expliquer les octets qui restent. Il ne peut pas consulter la fin amputée par la simple force de sa conviction.

Le troisième entier, longueur totale de l’enregistrement, inclut cette partie descriptive, les données conservées et un éventuel bourrage. C’est lui qui mène au paquet suivant. Un programme qui confond cette longueur avec celle des données décale toute sa lecture. Le RFC impose aussi l’ordre des octets : les entiers sont écrits avec l’octet de poids fort en premier. La portabilité tient à ces détails peu glamour ; une erreur de frontière peut fabriquer un récit entier à partir de mauvais octets.

Le quatrième entier est le plus perfide : le cumul des paquets perdus par le système de capture depuis le premier enregistrement. Le texte précise que certaines implémentations ne savent pas compter ces pertes et peuvent alors inscrire zéro. Ce zéro a donc besoin d’un interrogatoire. Il peut correspondre à l’absence de pertes comptabilisées ou à l’absence de compteur utilisable. Il ne mesure pas non plus la réussite d’une livraison jusqu’à une application : il parle de l’outil qui capturait.

Deux entiers terminent l’en-tête de chaque enregistrement : secondes écoulées depuis le 1er janvier 1970 et microsecondes pour l’arrivée du paquet. Ils permettent d’ordonner ce qui a été sauvé. Une chronologie de capture n’est pas encore l’histoire complète d’une panne. Le format de 1995 était remarquable parce qu’il offrait à des lecteurs indépendants une structure commune et, à ceux qui regardaient les champs de près, une carte de ses absences.