Resumo

  • O RFC 869 definiu uma forma comum para centrais de monitoramento consultarem hosts, relacionarem respostas, pedirem estados e estatísticas e receberem avisos espontâneos. Isso não fez cada equipamento relatar as mesmas informações.
  • O RFC 823 mostra como a distinção funcionava em um gateway: interfaces, vizinhos, redes alcançáveis, matriz de tráfego e contadores de descartes podiam ser observados, mas cada tipo de host mantinha seus próprios formatos de relatório e controle.

Análise

O gateway precisava revelar como operava

O Host Monitoring Protocol (HMP) não servia apenas para conferir se uma máquina respondia. A especificação de 1982 DARPA Internet Gateway descrevia a coleta de medidas e estados dos gateways por HMP. O estado incluía as interfaces do equipamento, os gateways vizinhos e as redes que ele conseguia alcançar. A Host Traffic Matrix contava datagramas por endereço IP de origem, endereço de destino e número do protocolo. Uma mensagem de vazão reunia contadores de tráfego recebido, encaminhado e enviado, além de descartes, detalhados por interface e vizinho.

Esses dados permitiam que outro ponto da rede enxergasse parte do que acontecia dentro de um gateway. A matriz ajudava a identificar quais combinações de origem, destino e protocolo passavam pelo equipamento; os contadores de descarte podiam localizar um tipo de falha. Mas nenhum deles, sozinho, demonstrava que a aplicação de um usuário chegava ao destino. O RFC descreve um projeto de engenharia, não um levantamento independente de todos os gateways que foram instalados.

A troca era comum; os significados, não

Publicado por Robert Hinden em dezembro de 1983, o RFC 869 substituiu a especificação anterior IEN 197. O texto descreve o HMP como um protocolo de transporte transacional e sem conexão. Seu cabeçalho inclui tipo de sistema, tipo de mensagem, número de sequência, um campo usado como senha ou como número de sequência devolvido e um checksum. A combinação entre tipo de sistema e tipo de mensagem indica como interpretar os dados. A lista inclui IMPs, controladores de acesso a terminais (TACs), gateways e outros sistemas; o HMP usa o número de protocolo IP 20.

Esse quadro comum tornava reconhecíveis as consultas e permitia relacionar cada resposta à pergunta correspondente. Ainda assim, os contadores de vazão de um gateway não se tornavam uma descrição universal para qualquer host. O RFC 869 diz que cada tipo de sistema definia mensagens conforme suas necessidades. Os apêndices trazem exemplos de mensagens de IMPs, TACs e gateways, mas a introdução deixa claro que esses exemplos não fazem parte do protocolo HMP. A especificação padronizava como consultar e identificar uma resposta; o formato próprio do equipamento continuava a definir o que ela queria dizer.

Alerta, estado e estatística não eram a mesma evidência

O RFC 869 atribuía boa parte da inteligência de monitoramento a uma central. O host coletava dados e os enviava quando solicitado ou espontaneamente; a central era responsável por garantir o recebimento correto do que pediu. Para estados e estatísticas, a central fazia polling e podia repetir a consulta depois de um timeout. Números de sequência ajudavam a relacionar resposta e solicitação e a identificar mensagens estatísticas duplicadas. As estatísticas ficavam armazenadas durante um intervalo para que uma resposta perdida pudesse ser solicitada novamente.

As traps seguiam outra regra. Quando ocorria um evento, o host enviava um datagrama, mas o HMP não previa confirmação nem retransmissão. Uma trap podia chegar depressa, mas não era um histórico garantido de eventos. O estado também tinha um limite claro: a central podia considerar o host ativo ou inativo conforme ele respondesse às consultas. Sem resposta, não era possível saber se falhou o host, o caminho, a consulta ou a resposta; uma resposta tampouco provava que um serviço de nível superior estava funcionando.

A central também podia alterar o host

Uma consulta não precisava apenas pedir dados. O RFC 869 permitia ler parâmetros do host ou enviar dados de controle. Entre os exemplos estavam configurar chaves e temporizadores das medições e controlar o próprio host com uma chave de reinicialização. O equipamento processava os dados e devolvia uma confirmação de controle, ou um erro se não pudesse tratá-los. Formato e significado dependiam do host. A confirmação registrava a troca prevista pelo protocolo; o RFC não a tratava como prova de que um serviço ao usuário funcionou depois da ação.

O RFC 1157, sobre SNMP, publicado em 1990, serve como contraste, não como prova de descendência direta do HMP. O RFC 1157 identifica o Simple Gateway Monitoring Protocol (SGMP) como antecessor do SNMP e descreve um modelo centrado em ler e alterar variáveis, com poucas notificações espontâneas. A história do HMP deve ser entendida por seus próprios termos: uma estrutura de mensagens comum permitia que equipamentos diferentes relatassem dados e recebessem comandos específicos para cada tipo.

Em abril de 1983, a lista de protocolos oficiais, RFC 840 classificou o HMP como “Elective” e registrou seu uso na monitoração de gateways da Internet e TACs, além da depuração de implementações em computadores pequenos e remotos. O RFC 869 também descreveu o uso em gateways e TACs, enquanto outras implementações ainda estavam sendo projetadas. Isso prova um uso contemporâneo delimitado, não adoção em toda a Internet. O detalhe histórico está na divisão que o protocolo preservou: a troca comum viabilizava a observação remota, mas o significado do relatório continuava ligado ao host que o enviava.

Fontes