Summary

  • RFC 778 describió un servicio horario ofrecido por los hosts de DCNET mediante mensajes de marca de tiempo ICMP y, durante la transición, respuestas Echo de GGP.
  • COMSAT-WWV recibía normalmente la hora WWVB con precisión de un milisegundo; otros hosts acumulaban desfases apreciables y la ruta descrita hasta una pasarela de BBN tardaba típicamente 550 ms en ir y volver.

El reloj más puntual de la sala no consigue que todos lleguen a tiempo. RFC 778, publicado por D. L. Mills el 18 de abril de 1981, describía esa diferencia con cables y números. El host virtual COMSAT-WWV recibía la referencia WWVB mediante un reloj de radio Spectracom, normalmente dentro de un milisegundo de la hora emitida. Los demás hosts DCNET calculaban correcciones de desfase y deriva con respecto a él. Aun así, los relojes ligados a la frecuencia de la red eléctrica en ciertas máquinas podían quedar habitualmente desviados una fracción apreciable de segundo. Había una fuente excelente y un conjunto de máquinas que necesitaba vigilancia.

El servicio servía principalmente para sincronizar relojes y medir retardos en un sentido con hosts de Internet que cooperaran. DCNET utilizaba las solicitudes y respuestas Timestamp del ICMP que entonces se proponía. Para conservar la compatibilidad con sistemas existentes, ofrecía temporalmente el mismo intercambio mediante Echo y Echo Reply del protocolo GGP. Mills animaba a otros hosts y pasarelas a probarlo. El documento dejaba a la vista tanto la instalación concreta como el trabajo que todavía hacía falta para extenderla.

La pregunta viajaba en un datagrama de 36 octetos, contando la cabecera Internet de 20 que indica la especificación. Tras tipo, código y secuencia había tres marcas: origen, recepción y transmisión. El emisor escribía su hora local en las tres antes de enviar. El receptor sustituía la de recepción cuando llegaba el paquete y la de transmisión cuando lo devolvía. En ICMP, el tipo 13 se convertía en 14; en el trayecto GGP, Echo tipo 8 volvía como tipo 0. Los valores contaban milisegundos desde la medianoche en tiempo universal, normalmente con aritmética de 24 horas.

Al recibir la respuesta, el remitente añadía el cuarto instante: la llegada a casa. La suma de los tramos de ida y vuelta restaba el tiempo de procesamiento interno del host DCNET. El desfase de los dos relojes se cancelaba en el total. Separar el viaje en dos direcciones exigía volver a mirar cómo estaban alineados esos relojes. Un mismo paquete podía ofrecer una cifra sólida para la vuelta completa y una pregunta más difícil para cada mitad.

El mapa del recorrido tampoco era abstracto. COMSAT-WWV residía en el host físico COMSAT-GAT, unido hacia la red ARPANET por una pasarela, Clarksburg SIMP y una línea de 4.800 bit/s hasta BBN. RFC 778 atribuye a ese trayecto hasta la pasarela de BBN un viaje típico de ida y vuelta de 550 milisegundos. La cifra pertenece a esa ruta de 1981. El reloj de radio podía acertar en un milisegundo y el mensajero tardar medio segundo: son partidas diferentes de la cuenta.

El operador disponía de instrucciones para comprobarlas. Primero, TELNET hacia COMSAT-GAT; SET HOST HOST devolvía una tabla de desfases por host. Después, SET WWV SHOW mostraba tráfico y la última respuesta del receptor Spectracom. Un espacio al principio de la línea de tiempo señalaba recepción correcta de WWVB; un ? indicaba problemas. El documento decía qué corrección sumar a las marcas de COMSAT-GAT o COMSAT-WWV para obtener la hora radiodifundida. Y terminaba con una petición tan humana como técnica: cerrar la conexión, «please!». Un signo de interrogación y una súplica por la sesión TELNET formaban parte del cuadro de instrumentos.

También se podía reconocer un fallo de la fuente. Si el reloj Spectracom dejaba de funcionar o se comportaba mal, el host virtual COMSAT-WWV quedaba inaccesible y, en el sistema descrito, llegaba una respuesta GGP de host no alcanzable. RFC 777, del mismo abril, fijaba los tipos ICMP Timestamp y Timestamp Reply y citaba a Mills; RFC 792, de septiembre, documentó la disposición revisada del mensaje. DCNET construyó sobre ese cambio de protocolo una práctica concreta de consulta y corrección.

Para usar la hora había que saber quién la proporcionaba, cuánto se había desviado el ordenador y qué había hecho el paquete por el camino. RFC 778 convirtió esas preguntas en datos visibles. Su reloj de radio no hablaba solo: los hosts presentaban sus desfases y el receptor podía levantar un ?. El servicio era más fiable precisamente porque enseñaba dónde podía dejar de serlo.