Resumo

  • A RFC 891 reaproveitava uma troca HELLO para medir atraso de ida e volta, escolher caminhos e carregar o offset de relógio associado, com filtros diferentes para cada efeito.
  • O caminho de menor atraso transportava a observação; quem identificava o mestre era a configuração CLOCK-HID, não uma eleição pela métrica.
  • Pacotes de mesmo tamanho, validade de data, retenção de rota e procedimento de ajuste impediam que “recebido”, “aceito” e “aplicado ao relógio” fossem sinônimos.

Há um momento contraintuitivo na RFC 891: uma máquina pode aprender uma rota melhor e, na mesma operação, decidir que não recebeu uma nova medida de tempo utilizável. Basta que o último HELLO enviado e o recebido tenham tamanhos diferentes.

Esse detalhe mostra que a integração entre roteamento e hora não era fusão de autoridade. Era reaproveitamento disciplinado de evidência.

O cenário era o DCN, uma rede local com até 256 hosts e gateways, formada em grande parte por Fuzzballs PDP-11 e LSI-11. Os enlaces podiam ser ponto a ponto ou multiponto. Cada host trazia funções completas de comutação, gateway e serviço, sem um líder local separado para distribuir rotas.

Uma linha da tabela servia a duas rotinas

A Host Table guardava o processo de saída, o atraso de ida e volta, o offset do relógio, o instante da atualização e um contador de vida. Vários hosts virtuais podiam existir na mesma máquina física. A Net Table, separada, mapeava redes externas para gateways e era em geral propriedade da configuração, salvo alterações por GGP ou EGP.

HELLOs entre membros da mesma rede usavam o protocolo IP 63 e levavam atraso e offset. O registro de números de protocolo da IANA mantém hoje o 63 como “any local network”. A linha prova a coordenação do número, não uso atual do DCN.

O cálculo de ida e volta ligava um HELLO recebido ao próximo transmitido. Não exigia relógios já acertados nem periodicidade exata; perdas e reflexões não anulavam o método. Era justamente o que permitia iniciar o roteamento antes de resolver a hora.

Formato inválido e checksum ruim eliminavam o pacote. Depois disso, cada consumidor ainda aplicava seus próprios critérios. Para um offset preciso, os comprimentos do último envio e recebimento tinham de coincidir. A rota podia mudar mesmo quando o campo horário permanecia antigo.

A métrica não concedia o título de mestre

O receptor somava o atraso até o vizinho ao valor que ele anunciava para cada destino. O caminho atual só era trocado quando o candidato o superava por uma margem configurada. O texto registra valores de implementação como cerca de 100 milissegundos de limiar, 120 segundos de retenção e 30 segundos de atraso máximo. Eles não são parâmetros obrigatórios para todos os tempos.

Ao aceitar um caminho, o host guardava também o offset que veio por ele. A rota mais rápida se tornava o meio de transporte da observação. Mas CLOCK-HID, configurado com um host ID, é que dizia qual host era o relógio mestre.

Um nó próximo podia anunciar excelente atraso sem adquirir direito de corrigir a hora. E uma observação do próprio mestre ainda precisava trazer data válida e passar pela lógica local de ajuste. Caminho, identidade e consequência ficavam em mãos diferentes.

A origem do caminho alterava o anúncio

Uma métrica aprendida num enlace não podia voltar por ele como se fosse informação independente. RFC 891 enviava MAXDELAY nessa direção para inibir loops. A RFC 2453 usa mais tarde as expressões split horizon, poisoned reverse, atualizações disparadas e contagem ao infinito.

São termos úteis para comparação, não prova de que RIP descendeu diretamente de Hellospeak. O ponto verificável é que o mesmo número assume risco diferente quando se perde a informação sobre o enlace de origem.

O contador de vida e o hold-down também impediam uma rota desaparecida de voltar como se nunca houvesse existido. A validade do caminho, a atualidade do offset e a capacidade do relógio local seguiam estados próprios.

Um salto de hora interrompia o próprio instrumento

O documento separava relógio físico, aparente e efetivo. Pequenas diferenças eram absorvidas aos poucos pela transferência de uma fração de CLK.DELTA. Com os parâmetros sugeridos, a taxa máxima ficava abaixo de aproximadamente dois milissegundos por segundo.

Uma diferença grande podia causar salto no relógio aparente. Em seguida vinha um intervalo em que timestamps de temporização eram declarados inválidos. O sistema não fingia que uma medição atravessando a descontinuidade tinha a mesma qualidade de uma medição comum.

O relógio aparente dava a volta à meia-noite UT, portanto precisava receber ao menos uma atualização diária válida de data e hora do mestre. Encontrar uma rota até CLOCK-HID não bastava para manter o calendário.

A RFC 778 já descrevia um serviço de relógio DCNET com três timestamps por ICMP e GGP. A RFC 891 inseriu medida, offset e alcançabilidade na manutenção contínua da mesma tabela local.

Hellospeak influenciou NTP sem ser NTP

A RFC 1059 deu ao protocolo Fuzzball o nome “Hellospeak”, declarou que sua incorporação de tempo ao roteamento influenciou fortemente o NTP e também disse que ele não servia fora do ambiente local.

A proposta inicial da RFC 958 colocou NTP sobre UDP e definiu hierarquia e representação, mas não algoritmos de sincronização e filtro, descoberta de pares ou autenticação. A RFC 1305 depois apresentou seleção e filtragem de múltiplos servidores, limites de erro e um relógio lógico derivado do trabalho nos Fuzzballs.

Existe influência documentada, não identidade. O salto histórico foi dar ao tempo uma superfície própria de seleção e correção, adequada a uma escala que o pequeno DCN não pretendia alcançar.

Fontes e limites

Este texto usa RFC 778, RFC 891, RFC 958, RFC 1059, RFC 1305, RFC 2453 e o registro IANA. As fontes não provam implantação atual do DCN, parâmetros uniformes, autenticação do mestre, simetria do atraso, linhagem direta até RIP ou que a menor ida e volta sempre produza o menor erro de relógio.