[IRC-DEV] Un par de detalles más sobre "chan2"

Jesus Cea Avion jcea at argo.es
Fri Jan 3 19:26:03 CET 2003


- Los canales registrados son "persistentes". Es decir, cuando un canal
  registrado se queda vacío, no se elimina de memoria, sino que se
  conserva. Se guarda información como su fecha de creación, su "topic",
  los baneos del canal, los modos, etc.

- Los canales registrados "vacíos" se pasan también en los "netjoin".

- Cuando un usuario entra en un canal registrado, vacío, se debe
  propagar un "JOIN", no un "CREATE". Tampoco se le debe dar "op" de
  forma automática, ya que ello lo marcarán los permisos del canal.

- Si un usuario *LOCAL* crea un canal que resulta que está en la "BDD"
  como registrado, se toman esas mismas medidas, aunque no haya
  constancia de su existencia previa.

- Al contrario que ocurre con la BDD de nicks, los cambios de
  registro/desregistro de un canal, y sus modos obligatorios o
  prohibidos, vía BDD, son procesados al momento.

- Los cambios +r/-r son enviados SOLO a los usuarios locales, no a
  los nodos.

- Cuando a un nodo le llega un cambio en los modos obligatorios o
  prohibidos de un canal registrado, debe enviar primero el nuevo
  registro a su nodos vecinos y, DESPUÉS, propagar el ajuste de modos
  en el canal. Ese ajuste de modos será recibido también por los nodos
  vecinos, que habrán recibido previamente también el nuevo registro.

  La resolución de conflictos de modos de canal en diferentes nodos
  se gestionará de forma "normal".

- En un netburst, el modo +r se transmite, pero se ignora en el
  receptor. Un nodo considerará un canal +r EXCLUSIVAMENTE en función de
  su BDD local.

En cuanto a BDD, se separa la base de datos de canales registrados y
modos permitidos, 'c', de la base de datos de topics, welcome y usuarios
registrados, 'd'. Esto se hace así porque el correcto funcionamiento del
sistema depende del contenido actualizado de la tabla 'c'. Separando esa
tabla, la fusión de la misma en un "join" es mucho más rápida. La tabla
'd' no es tan crítica.

Si un nodo tiene una BDD corrupta, puede contener modos
obligatorios/prohibidos que son inconsistentes con el resto de nodos.
Esto puede ocurrir de forma puntual y transitoria si un nodo se
reunifica con la red y su BDD está muy desactualizada. Cuando su BDD
está al día, todo funcionará con normalidad. No obstante si el nodo
tiene una BDD corrupta, puede ocasionas muchos problemas, ya que puede
crearse un BUCLE entre dos nodos, uno cambiando los modos de otro "ad
infinitum". Esto debería detectarse y cantarse por "wallop".

Es conveniente que Olimpo realice sondeos periodicos para comprobar la
integridad de las BDD.

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




More information about the IRC-Dev mailing list