[IRC-DEV] Sobre SETTIME

[Jesus Cea Avion]

Actualmente el comando SETTIME del IRCD permite que un nodo de control
fuerce una sincronización precisa de toda la red, algo necesario para su
buen funcionamiento. Lamentablemente ese comando presupone que la
propagación y procesamiento por parte de los nodos es instantanea, lo
que no es el caso por muchos motivos: lag, carga de CPU, pérdida de
paquetes en la red, etc.

El efecto neto es que cuando la red está en su peor momento, cada nodo
procesa el SETTIME en un momento distinto. En situaciones críticas el
desfase entre los nodos puede superar la ventana de conexión fijada en
el IRCD, que es de 30 segundos. En ese momento estamos jodidos, porque
una vez que se "desfasa", si el enlace se rompe es muy difícil que se
pueda volver a unir sin ayuda externa o pura suerte.

Para solucionar esto, hay varias posibilidades. La ideal sería usar NTP
en todos los nodos y grabar horas coreectas en los relojes hardware,
pero la experiencia nos ha demostrado (en IRC-Hispano) que ese es
confiar demasiado, sobre todo cuando se reinicia la máquina.

La otra posibilidad es no aceptar SETTIMEs en situaciones de
inestabilidad de la red. Ideal, pero detectar la "inestabilidad" no es
algo fácilmente "programable".

Yo hago la siguiente propuesta:

1. Sustituir "SETTIME" por tres comandos: "A", "B" y "C".

2. Periódicamente, un nodo de control manda un comando "A". Ese comando
es "broadcast" y lo reciben TODOS los nodos.

3. Cuando un nodo recibe un "A", envía al nodo origen un comando "B
TS1", donde TS1 es su "timestamp" actual, con una precisión de un
milisegundo.

4. Cuando el nodo de control recibe un comando "B TS1", lo responde con
"C TS1 TS2", donde TS2 es su "timestamp" actual, con una precisión de un
milisegundo. Esta hora será exacta y es la referencia oficial de la red,
que para eso se trata del nodo de control.

5. Cuando un nodo recibe un comando "C", calcula TS3, que es su
"timestamp" actual, con una precisión de un milisegundo.

  El nodo calcula W=TS3-TS1, que es el intervalo de confianza de
  la hora TS2. Es decir, la hora real, cuando llega "C" al nodo,
  estará dentro del intervalo [TS2,TS2+W]. Esto lo podeis ver
  pensando un poco los dos casos extremos que hay, que son que el
  lag se concentra exclusivamente en una dirección u otra.

  El servidor de IRCD actualizaría su hora local SOLO si la ventana W
  es inferior a la ventana de conexión que se haya fijado, típicamente
  30 segundos.

  La hora fijada será (TS2+W/2), a falta de un mejor estimador de LAG
  en la red.

¿Ideas?. ¿Sugerencias?. ¿Comentarios?. ¿Propuestas de estimadores de
lag?.
  
-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz