[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