Resumen

  • El RFC 1165, de junio de 1990, propuso ejecutar NTP sobre el servicio de operaciones remotas de OSI. La asociación entre pares añadía estados explícitos: conectado, conectando, aceptando una conexión o desconectado.
  • NTP utilizaba un registro de respuestas de los ocho últimos intercambios para estimar la alcanzabilidad. En el experimento con conexiones, una línea abierta, rota o todavía en establecimiento daba directamente esa información; los datos NTP seguían ocupándose de la sincronización.

Saber si contestan antes de mirar la hora

Hay una diferencia entre poder hablar con un par y obtener de él una buena medida de tiempo. Los datagramas obligaban a NTP a inferir la primera condición a partir de las respuestas recientes. El RFC 1165 explica su registro de desplazamiento: recuerda los ocho últimos envíos y cuántos obtuvieron respuesta. Si ninguno responde, el par se considera inalcanzable. Es un pequeño libro de visitas. Cuando todas las casillas quedan vacías, toca dejar de llamar.

Crowcroft y Onions probaron otro entorno para NTP. Su propuesta experimental especificaba operaciones remotas y una sintaxis ASN.1 para llevar el servicio a una pila OSI. Querían dotar de sincronización a aplicaciones OSI, probar una especificación que pudiera revisarse y convertirse automáticamente en código, y explorar servicios orientados a conexión como X.25. En una conexión, el transporte ya sabe si la relación está establecida, rota o todavía en trámite. Esa noticia puede llegar antes de que el registro acumule ocho silencios.

El diseño añadió estados propios a cada par. Connected significaba que había conexión y circulaban datos de sincronización. Connecting describía un intento saliente. Accepting señalaba una solicitud entrante mientras aún faltaba completar la negociación de transporte y sesión. Disconnected indicaba que no se había podido contactar. Una llamada a larga distancia podía tardar segundos, por lo que el establecimiento se hacía de manera asíncrona. El demonio de tiempo podía seguir atendiendo a los demás pares mientras aquella línea acababa de abrirse.

La asociación empezaba con A-ASSOCIATE.REQUEST y una indicación al otro lado. Después llegaban invocaciones periódicas de la operación remota apropiada con parámetros NTP. La versión del protocolo o la precisión del reloj local suelen mantenerse durante la vida de una conexión; era posible conocerlas al establecerla y evitar repetirlas en cada operación. El RFC también contemplaba la autenticación al conectar cuando se utilizara. Los campos de datos temporales conservaban la forma de la especificación previa de NTP, de modo que un programa podía mantener estructuras internas conocidas y traducirlas a la codificación ROS/ASN.1.

Una conexión habla de contacto. La calidad de la hora depende del viaje de los mensajes. El RFC 1165 defendía una idea capaz de incomodar a un vendedor de líneas veloces: para sincronizar relojes cuenta mucho la variación del tiempo de tránsito. Un camino lento y regular puede rendir mejor que uno rápido cuyos retrasos bailen en cada envío. Los autores llamaron «herejía» a esa posibilidad. El chiste señala una confusión persistente: el ancho de banda luce en el folleto, pero el reloj siente cada variación del trayecto.

El ensayo salió del papel. El RFC registra varios centros británicos con una versión anterior de ROS sobre X.25; al menos uno mantenía pares británicos por esa vía y pares estadounidenses por UDP. La tabla del centro británico reúne dos pares JANET y tres estadounidenses, y presenta alcanzabilidad, retardo, desfase y dispersión. El documento no identifica por nombre todos los centros británicos ni ofrece cifras comparativas generales entre X.25 y UDP. Aun así, la configuración muestra a un mismo servicio de tiempo atendiendo a pares de dos arquitecturas, con dos maneras distintas de averiguar si seguían al otro lado.

El precio de esa noticia temprana era abrir y negociar la asociación. El RFC evita que un establecimiento remoto de varios segundos inmovilice al demonio: Connecting y Accepting avanzan de modo asíncrono mientras los demás pares siguen intercambiando datos. Si la asociación falla, el par pasa a Disconnected y se marca inalcanzable; si prospera, puede conservar versión y precisión conocidas al conectar en lugar de repetirlas en cada operación. El reloj conserva su empleo principal. Hacerlo además telefonista habría sido una promoción pésimamente pagada.