[IRC-DEV] Sobre SETTIME

[David A. Pérez]

> > Confiar demasiado? A que te refieres con eso y porque el problema es
> > mayor cuando se reinicia la maquina?
>
> La experiencia es que la gente no sabe montar ni operar NTP.

Ah, pero eso no es un problema intrinseco al IRCD ;)

> Esto se ve en IRC-Hispano semana a semana.

No hay politicas de red? Aunque claro ya nos estamos metiendo en politica y
esto es desarrollo...

> No hay que olvidar tampoco que el IRCD pilla la hora al arrancar, pero
> luego tiene una hora local PROPIA. Así, si hay un pequeño error y el NTP
> del servidor lo compensa, el IRCD no se entera.

Esa ya me parece una razon de peso... Si se opta por NTP habria que mirar la
posibilidad de que el IRCD se sincronizara con la hora de la maquina cada x
tiempo.

> > Mi opinion es totalmente ajena al desarrollo de IRCD pero no veo
> > porque hay que reinventar la rueda. Si protocolos como Kerberos usan
> > NTP no veo porque el IRCD no puede usarlo.
>
> Yo estoy a favor del NTP, pero el IRCD requiere mantener también una
> hora de red.
>
> Aunque no es excusa, el NTP requiere mantener dos servicios: el ircd y
> el NTP.
>
> Y, como ya he dicho, la experiencia de años muestra lo que muestra. Es
> triste, sí.

Mi mente no es capaz de asimilar una red donde los dispositivos tengan
distinta hora...

En todo caso, ahi va mi propuesta... Copiada inpunemente :P

jcea habia propuesto:

CONTROL: A
   NODO: B TS1
CONTROL: C TS1 TS2

W = TS3 - TS1

El problema que veo es que no sabes cuanto tarda el nodo de CONTROL en
procesar la respuesta. Prodia haber un desfase entre que se procesa y se
envia. Asi que...

RFC 2030 (http://www.faqs.org/rfcs/rfc2030.html)

[...]

      Timestamp Name          ID   When Generated
      ------------------------------------------------------------
      Originate Timestamp     T1   time request sent by client
      Receive Timestamp       T2   time request received by server
      Transmit Timestamp      T3   time reply sent by server
      Destination Timestamp   T4   time reply received by client

   The roundtrip delay d and local clock offset t are defined as

      d = (T4 - T1) - (T2 - T3)     t = ((T2 - T1) + (T3 - T4)) / 2.

Segun el RFC y la idea de jcea tenemos que:

TS1 = T1
TS2 = T2
TS3 = T4

Segun esto W = d si T2 = T3

Asi que mi mejora (mia??? :P) seria:

CONTROL: A
   NODO: B T1
CONTROL: C T1 T2 T3

El nodo de control envia los dos tiempos, el de recibido (T2) y el de
enviado (T3).

Tampoco veo la necesidad de usar tres comandos (A, B y C) cuando se puede
usar el mismo y distinguirlos en base al numero de parametros.

Por otro lado, y respondiendo al segundo correo:

> Un IRCD sólo fijará su hora si el W recibido es menor que la ventana de
> conexión *Y* si el "W" es MENOR que el W anterior. En ese caso, se
> actualizará la hora a (TS2+W/2) y se toma el nuevo intervalo de
> confianza W.

Totalmente sin acuerdo. W (en mi notacion "d") es una medida "exacta"
(perdoname Heisenberg), es el tiempo que tardamos en saber la hora correcta,
pero tiene un problema, no sabemos si el tiempo que tarda la señal en llegar
al servidor es el mismo que tarda en llegar al cliente. Un d muy pequeño no
es mejor que uno mas grande... El 90% de un d pequeño puede ser la parte
cliente/servidor y el otro 10% la parte servidor/cliente, y es mas inexacto
que un d 100 veces mas grande donde cada parte sea el 50%.

Salu2,

David A. Pérez

                              http://www.kamborio.com/
 _                       _                   _
| | __  __ _  _ __ ___  | |__    ___   _ __ (_)  ___
| |/ / / _` || '_ ` _ \ | '_ \  / _ \ | '__|| | / _ \
|   < | (_| || | | | | || |_) || (_) || |   | || (_) |
|_|\_\ \__,_||_| |_| |_||_.__/  \___/ |_|   |_| \___/
      El perdón es la venganza de los buenos (anónimo)