Resumo

  • Publicado em fevereiro de 1995, o RFC 1761 explicou o arquivo Snoop Version 2 da Sun para que outros programas pudessem criar e interpretar capturas.
  • O registro separa o tamanho recebido do tamanho salvo; a contagem acumulada de descartes pode ser zero porque a ferramenta nem sabe medir perdas.

Há uma tranquilidade quase teatral em abrir uma captura de pacotes durante uma investigação. A tela mostra linhas, horários, bytes. Parece que a rede resolveu depor. Brent Callaghan e Robert Gilligan, da Sun, tinham um objetivo mais prático ao publicar o RFC 1761: permitir que programas diferentes trabalhassem com o mesmo arquivo Snoop. A graça histórica está no que a padronização obrigou a explicitar. Uma captura transportável continuava sendo uma observação feita por uma máquina concreta, com escolhas e falhas próprias.

O arquivo começa com dezesseis octetos. Oito identificam snoop seguido por três zeros; quatro trazem a versão 2; quatro informam o tipo de enlace. Ethernet usa o código 4, IEEE 802.3 o código 0. A distinção importa porque os dados de cada pacote começam pelo cabeçalho de enlace. Ler o cabeçalho errado muda o resto da história. A tabela também enumera Token Ring, HDLC, FDDI e outros tipos. Para que dois programas concordem sobre o pacote, primeiro precisam concordar sobre esse contexto e sobre a ordem dos inteiros, todos gravados com o byte mais significativo à frente.

Depois vêm registros de tamanho variável. Cada um abre com seis inteiros de 32 bits, vinte e quatro octetos de descrição. O primeiro informa o comprimento original do pacote recebido da rede. O segundo informa o comprimento incluído no arquivo. Quando o segundo é menor, houve truncamento na captura. O analista pode enxergar um belo cabeçalho e mesmo assim não possuir o fim do pacote. A ausência não é um defeito do programa que abriu o arquivo; ela já foi escrita no próprio recibo.

O terceiro valor é o comprimento total do registro, incluindo descrição, bytes salvos e eventual preenchimento. Ele aponta para o início do próximo. Trocar esse número pelo comprimento incluído faz o leitor tropeçar no preenchimento e chamar ruído de dado. O RFC torna o formato útil justamente ao eliminar esse improviso. Não basta reconhecer a palavra snoop; é preciso andar pelas fronteiras exatas de cada registro.

O quarto valor merece uma cadeira na mesa de revisão: descartes acumulados. Ele conta pacotes perdidos pelo sistema de captura entre o primeiro registro e o atual. O texto avisa que algumas implementações não têm como contar e podem colocar zero. Portanto, zero não traz certidão de ausência de perdas; pode ser apenas o jeito mais arrumado de registrar uma incapacidade. Além disso, a métrica pertence à captura. Não descreve automaticamente o que ocorreu em uma aplicação ou no outro extremo da conexão.

Os dois valores finais registram o instante de chegada: segundos desde 1º de janeiro de 1970 e microssegundos. Eles ajudam a ordenar os pacotes que ficaram. Para explicar o incidente inteiro, ainda será preciso relacionar a captura com outras observações. O RFC 1761 foi uma vitória discreta: deu a ferramentas diferentes uma gramática comum e deixou, nos próprios campos, pistas sobre aquilo que a gramática não conseguiu guardar.