Resumo

  • O cliente SNTP comum da RFC 2030 normalmente usava um só servidor. Quatro carimbos de tempo permitiam estimar atraso e diferença de relógio, mas não reproduziam a escolha entre fontes e a rejeição de relógios defeituosos do NTP completo.
  • A simplificação tinha endereço: cliente na folha, sem dependentes; servidor apenas na raiz, diretamente ligado a uma referência confiável. No meio da árvore, uma falha local passaria a organizar o tempo de terceiros.
  • No anycast descrito pela RFC, o cliente se vinculava à primeira resposta e prosseguia por unicast. Chegar primeiro uma vez não comprova proximidade, precisão, autenticidade ou identidade persistente.

A RFC 2030 não tornou o tempo simples; tornou simples uma conversa sobre o tempo.

Publicada em outubro de 1996, ela preservou o formato das mensagens NTP e eliminou grande parte dos estados e algoritmos usados pelo NTP completo para comparar várias fontes, detectar as ruins e disciplinar o relógio ao longo do tempo. O ganho atendia dispositivos pequenos. O que desapareceu do protocolo precisava reaparecer como limite operacional.

A folha continha a falha

O texto recomenda SNTP somente nas extremidades da sub-rede de sincronização. O cliente fica na folha, no maior stratum, e nenhum cliente NTP ou SNTP deve depender de outro cliente SNTP. Se uma única fonte enganar a folha, o efeito termina ali. Se a folha distribuir tempo, sua ausência de comparação vira propriedade de toda a cadeia.

Na raiz, a exceção também é estreita: servidor SNTP de stratum 1 diretamente ligado a uma fonte de rádio ou modem confiável, sem outra fonte disponível. A própria RFC explica que um servidor primário realmente confiável costuma exigir referências redundantes, caminhos diferentes e algoritmos específicos. Ter muitos consumidores não transforma uma origem em várias.

Uma equação não traz a procedência

T1 é o envio do cliente, T2 a recepção do servidor, T3 o envio da resposta e T4 a chegada ao cliente. O atraso correto é d = (T4-T1) - (T3-T2); a diferença, t = ((T2-T1) + (T3-T4))/2. A Verified Errata 517 corrige a inversão de sinais impressa na fórmula de atraso da RFC.

O originate da resposta deve repetir o transmit do pedido, ligando os dois pacotes. Isso não liga para sempre um endereço a uma identidade. Tampouco comprova simetria de caminho, qualidade da referência ou repetição do mesmo servidor na consulta seguinte.

LI=3 anuncia servidor não sincronizado e exige descarte. Stratum, transmit não nulo e originate coerente ajudam a rejeitar mensagens ruins. Mas não encontrar um defeito não autentica toda a origem. Os campos de referência continuam sendo declarações do emissor.

Serviço sem estado, operação com memória

Uma solicitação podia deixar quase todos os campos zerados. O servidor respondia sem manter estado persistente por cliente, num padrão comparado a uma chamada remota sem estado. A troca ficou barata e reproduzível.

A memória, porém, migrou para fora do pacote. O operador precisa registrar qual fonte foi escolhida, como o nome resolveu, por onde a resposta veio, quando o ganhador mudou, quais alternativas existiam e o que fazer diante de divergência.

A “especificação inicial mínima” de Lu Heng separa bem esses planos: formato e validações determinísticas pertencem à camada comum; diversidade, failover e tolerância pertencem à decisão local. A primazia do código em execução impede outra confusão: documento publicado, implementação, configuração e adoção observada são fatos diferentes.

O primeiro retorno ganhou uma disputa invisível

No modo anycast da RFC 2030, o cliente enviava a um grupo de broadcast ou multicast. Servidores respondiam com endereços unicast individuais; o cliente escolhia o primeiro e continuava a conversar com ele.

Esse vencedor podia refletir rota, fila, carga, perda concorrente, escopo de multicast ou jitter. O pacote comprova uma ordem de chegada naquele observador, não a causa. RFC 1546 já tratava da separação geral entre endereço de serviço e servidor. Aqui, o ponto específico é a transformação da primeira chegada em vínculo temporário.

A extensão de autenticação citada para multicast e anycast não resolve retrospectivamente a identidade: a RFC dizia que seria publicada depois e que o desenho era provisório.

Um pacote válido não é uma cronologia válida

Validade sintática, troca calculável, relógio disciplinado e evento de negócio ordenado são camadas diferentes da realidade. Uma pode estar correta enquanto a seguinte falha. O valor da RFC 2030 foi reconhecer que a simplificação reduz o conjunto de alegações possíveis.

Se uma máquina precisa servir dependentes, resistir a uma origem ruim ou provar identidade duradoura, ela precisa de fontes independentes, rotas diversas, procedência, histórico persistente e resposta testada ao desacordo. Renomear uma folha não devolve os controles removidos.

A RFC tornou uma resposta legível. Sua cautela foi não chamá-la de consenso.

Fontes