[IRC-DEV] Re: [Ops-nick] A quien corresponda (jcea)

[Jesus Cea Avion]

Este mensaje está semi-offtopic en "irc-dev", pero me parece de interés.



> Buenas no se como esta el tema de los registros directos hacia la BDD
> pero me han llegado varios usuarios concretamente este es el 3º que me
> dicen que registran el nick y queda perfectamente registrado en NiCK2
> (BDD) pero NiCK no los ve como registrados:

"nick" y "nick2" van bastante por libre. "nick2" hace lo posible por
mantenerse en sincronía, pero poco a poco las bases de datos respectivas
van divergiendo.

El problema es el siguiente (no sé si será este caso concreto, pero es
un problema que se da):

- "nick" expira un nick no usado a los 30 días.

- "nick2" pregunta a "nick" si debe expirar un nick si ve que no se
  conecta en los últimos 30 días. Si "nick" le dice "aún lo tengo" (por
  ejemplo, está como "noexpire"), pues "nick2" se lo traga y no lo
  caduca. Si un "nick" se conecta con periodos de menos de 30 días,
  "nick2" no se molesta en preguntarle nada a "nick".

El problema es que aunque ambos bots caducan los nicks no usados a los
30 días, el instante EXACTO de hacerlo no coincide. En "nick2" voy
revisando 1000 nicks por minuto, por lo que repasarme los 140.000 nicks
que hay registrado con +r ahora mismo, supone dos horas y media, más o
menos. Osea, que puede pasar dos horas y media desde que se cumplan los
30 días EXACTOS hasta que "nick2" lo ve y consulta a "nick".

Por su parte "nick" también va a su bola. No conozco los detalles, pero
creo que expira todos los nicks en bloque cada media hora o así. Glog lo
sabrá mejor.

Entonces el problema es sencillo de ver: puede ser que "nick" caduque un
nick por inactividad y que, antes de que "nick2" llegue a él y lo
consulte, que el usuario conecte. En "nick" ya no existe, pero en
"nick2" sí, así que "nick2" actualiza su ultima conexion. Como hace
menos de 30 días, ya no pregunta a "nick". "nick2" se lo cargará cuando
el usuario deje de conectar 30 días, desde su perspectiva. En ese
momento "nick" le dirá que se lo cargó hace 6 meses, y "nick2" se lo
pasa por la piedra.

Aunque esta "ventana" es pequeña (un par de horas al mes), en una red
con medio millón de conexiones diarias, se ven casos así todos los días.
Esa ventana puede ser mucho más grande si "nick2" no ve a "nick" cuando
le toca hacer un sondeo, y el sondeo tendrá que esperar un ciclo
completo para ese usuario.

Otra fuente de desincronizaciones es si el usuario conecta a la red
cuando "nick" está en SPLIT (si es "nick2" el que está fuera, no hay
problema porqu ees mucho más listo que "nick", y le preguntará antes de
cargarse a nadie). En ese caso, el usuario se ha conectado recientemente
para "nick2", pero "nick" no ha visto esa conexión y no la tiene en
cuenta.

Estos casos son raros pero, como digo, en una red tan grande como la
nuestra ocurren varias veces al día. En la mayoría de los casos el
problema se resuelve solo, ya que un usuario que se conecta muy de vez
en cuando y pilló la "ventana" por azar, probablemente la falle en la
subsiguientes expiraciones, si se sigue conectando de tarde en tarde.

Es un problema inevitable de mantener "nick" y "nick2" a la vez. En su
día se me ocurrió que periódicamente (digamos, cada tres meses), "nick2"
pregunte a "nick" sobre TODOS los usuarios que tiene, aunque se hayan
conectado recientemente, y así sincronizar de nuevo la base de datos,
pero nunca lo implementé porque no considero el problema grave, y
verificar 150.000 nicks a través de la red (que serán 250.000 en unos
meses) es muy costoso en cualquier metrica.

A ver cuando nos cargamos a "nick" definitivamente :-p

SOLUCIONES:

- Si el usuario no tiene nada en la agenda y no le importa perder la
  antigüedad, posibles "ipvirtuales", etc., lo más conveniente es un
  "drop" y que lo registre de nuevo.

- Si tiene algo en la agenda, puedo enviársela por email si se me avisa
  *ANTES* del DROP.

- Antiguamente, cuando el registro en "nick" y "nick2" iban por libre,
  el usuario podía registrar el nick en "nick" manteniendo su registro
  en "nick2". En la actualidad creo que te daría un error de "nick ya
  existente", pero si es un problema habitual, puedo hacer que "nick2"
  responda con un OK si el usuario tiene +r y está intentando
  registrar su propio nick del cual, obviamente, tiene registro y
  acceso a la clave.

  Esto tiene más miga de lo que parece, porque hay que tener en cuenta
  splits en la red, que haya nodos con bases de datos anticuadas o,
  sencillamente, manipuladas por sus administradores, etc.

Sinceramente, tiro por la opción del DROP. Si os da mucho por saco,
comentadlo y me puedo pensar lo de la resincronización mensual o que
responda con OK para un registro ya existente.

-- 
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