Resumo

  • O conjunto ativo podia ignorar protocolos, inverter origem e destino, mascarar endereços, empurrar apenas alguns atributos e definir as colunas coletadas pelo NeMaC. A linha resultante era uma observação configurada.
  • O NeTraMet compilava grupos de testes em buscas por hash e substituía máscaras completas por índices de um byte; os limites da compilação também condicionavam o significado do dado.
  • Perto da capacidade, o medidor podia abandonar regras de produção por regras standby mais grossas e, no FloodMark, pelas regras default. Depois de reiniciar, também começava pelo default até o gestor restaurar a política.

Toda contagem começava com uma pergunta

Publicado em março de 1997 como Informational, o RFC 2123 registrou três anos de experiência com a arquitetura RTFM. O desenho separava quatro papéis: o meter observava pacotes; o meter reader transportava dados; o manager configurava o sistema; e aplicações de análise montavam relatórios.

Na implementação descrita, o NeTraMet era o medidor. O NeMaC acumulava gestão e leitura. Antes de surgir uma linha no arquivo, o NeMaC baixava um rule set para o Packet Matching Engine. As regras testavam atributos, inseriam valores escolhidos no fluxo, ignoravam pacotes, saltavam para outro trecho ou repetiam a correspondência com as direções trocadas. O próprio arquivo de regras declarava o formato que seria coletado.

Por isso, origem e destino não eram necessariamente uma orientação universal preservada do fio. A direção podia ser normalizada em torno de uma rede local, um gateway ou uma porta conhecida. A convenção facilitava o relatório, mas precisava acompanhar a cifra.

O registro do RFC Editor e o IETF Datatracker mantêm a fronteira: experiência de implementação, não padrão da Internet nem prova sobre todo produto. A consulta oficial de errata do RFC 2123 não encontra entradas no momento; isso não certifica binários ou interpretações posteriores.

O tráfego descartado não deixou comprovante negativo

Se apenas IP interessava, processar Novell ou EtherTalk era desperdício. O NeTraMet examinava as regras e identificava os Peer types de interesse. Um protocolo fora desse conjunto era abandonado logo após a identificação. Se endereços adjacentes nunca eram testados, tampouco precisavam ser copiados.

O ganho de memória e CPU era real. Também era real a perda da pergunta futura. Um arquivo IP completo não demonstrava ausência de outros protocolos no segmento. Demonstrava a execução correta de um filtro. A arquitetura do RFC 2063 já colocava a redução perto do ponto de observação para diminuir transporte e análise. O RFC 2123 mostrou que aquilo que não atravessou essa redução não podia ser recuperado depois.

O compilador fazia parte da proveniência

Grupos de classificação podiam conter centenas de testes de endereço. Em vez de percorrê-los sempre, o NeTraMet agrupava regras com o mesmo atributo e máscara em tabelas hash preparadas antes da ativação. Grupos pequenos permaneciam sequenciais; o tamanho mínimo era uma opção de compilação.

Também era necessário lembrar a máscara usada, pois um bit zero real e um bit ignorado não significavam a mesma coisa. A versão relatada criou uma tabela de máscaras e guardou apenas um índice de um byte em cada fluxo. O número máximo — até 256 — era definido na compilação.

Essas soluções tornavam a medição prática. Ao mesmo tempo, ligavam o registro à representação executável. Um endereço já chegava mascarado, uma classe refletia um caminho de regras e uma ausência podia ter ocorrido antes da tabela. Separar o número desse contexto era perder a pergunta original.

A pressão de memória trocava resolução por continuidade

O tamanho máximo da tabela era escolhido quando o NeTraMet iniciava. Um coletor incremental recuperava fluxos inativos após o avanço dos readers conhecidos. Caso a coleta se atrasasse, a tabela ainda podia ficar cheia.

Acima de HighWaterMark, o medidor podia adotar um rule set standby. Em Auckland, as regras de reserva eram semelhantes às de produção, mas guardavam muito menos informação. Em alguns episódios, isso manteve o meter ativo por um ou dois dias depois da falha de um reader e permitiu colher os totais acumulados quando ele voltou.

No FloodMark, o NeTraMet mudava para o conjunto default para evitar que o garbage collector consumisse tanta capacidade que o manager deixasse de receber resposta. Os 65% e 95% citados para as duas marcas eram valores que funcionaram naquela experiência, não limiares universais.

O processo podia permanecer disponível enquanto a semântica mudava. Produção, standby e default produziam linhas válidas, porém com granularidades distintas. Uptime não era prova de cobertura invariável.

O reinício abria um intervalo de política diferente

Depois de uma queda de energia, o medidor começava pelo rule set 1 incorporado. O NeMaC comparava sysUptime com a leitura anterior; um valor menor revelava reinício. Só então baixava os conjuntos de backup e produção e solicitava o retorno ao último.

O exemplo operacional usava keepalive de cinco minutos e coleta a cada quinze. O RFC diz que até cinco minutos de dados podiam ser perdidos antes do download. O número era consequência daquela escolha local. Durante o intervalo, o conjunto default também podia classificar de modo diferente.

Portanto, um contador novamente crescente não costurava as séries. Eram necessários uptime, momento de detecção, conclusão do download e identidade das regras.

FlowIndex era uma vaga reutilizável

Uma posição recuperada pelo garbage collector podia receber outro fluxo com o mesmo FlowIndex. O RFC 2123 exigia a combinação de FlowRuleSet, FlowIndex e StartTime para uma identidade única. O índice sozinho não era uma entidade persistente.

A leitura por colunas tampouco congelava a tabela. Uma linha podia tornar-se ativa depois que uma coluna anterior já fora lida; o NeMaC a deixava para a próxima coleta. O Meter MIB do RFC 2064 dava os objetos de controle. A arquitetura posterior do RFC 2722, de 1999, pertence a outra versão histórica e não prova o comportamento de todo site em 1997.

As medições de desempenho também eram locais: cerca de 750 pacotes por segundo num 286 de 10 MHz, 1.250 num 386SX de 25 MHz e relatos de picos de 3.000 num 486 de 40 MHz sem perda. Isso não demonstrava completude, validade de cobrança, integridade ou sigilo universais. O RFC deixava integridade e confidencialidade aos protocolos de gestão e coleta.

O ensaio posterior de Lu Heng sobre primazia do código em execução sugere a pergunta certa: qual configuração de fato rodou? A especificação inicial mínima impede que uma escolha local ganhe autoridade universal. As camadas de realidade separam documento, código, registro e resultado. São lentes analíticas posteriores, não evidência da intenção do autor do RFC.

O legado do RFC 2123 é uma cadeia de custódia: manager define a pergunta; meter projeta; escassez reduz detalhe; reader recolhe uma visão não atômica; análise formula a conclusão. O registro vale porque a cadeia pode ser auditada, não porque a linha imita uma cópia neutra do fio.

Fontes