[IRC-DEV] Borrado de topics en los "netride"

[RooT]

Saludos:

>Plantéame un esquema "realista" para el caso del topic, por ejemplo. A
>ver si hay "huevos" };-).

Siento el retraso pero el curro me tiene hasta arriba. :)

Esquema "realista": ( Explico un poquito todo para organizar, y organizarme
las ideas )

El problema que se me plantea es el de compartir los topics tras un netjoin,
ya que en estas "uniones" entre servidores no se comparten los topics para
ahorrar ancho de banda ( y/o tiempo ). Mi solucion, la veo por instalar unas
"trampas" o triggers como querais llamarlos, que en una accion determinada
( un usuario entra a un canal ) y tras un netjoin actualize el topic del
canal donde ha saltado el trigger. Esto a mi modo de ver es una solucion
practica y realista, es estadisticamente muyyyy dificil que de 20.000
canales, tras un netjoin entren usuarios a los 20.000 canales, por ello los
trigger iran actualizando los topics poco a poco, evitando hacer mas largas
las sincronizaciones ( y tambien ahorrara algo de ancho de banda, ya que
habra canales que desaparezcan porque solo tienen un usuario y este sale,
por lo tanto ese topic no debe actualizarse ).

El problema: ( Posteo )
>Piensa, por ejemplo,en qué ocurriría cuando te hago un whois (tras un
netjoin), la red >tiene lag y mi nodo, que lo tengo a 10 ms, debe preguntar
a tu nodo (vía una
>red en lag) si estás away o no. Imagina que tras 3 minutos esperando a que
mi nodo >responda, hay un split de tu nodo.

Veo dos maneras de solucionar este "temible" problema, o bien usamos unos
pequeños retardos antes de activar los trigger, o por llamarlo de alguna
manera una "lista de actualizacion" ( acojona? xD ). La primera es la que
veo mas practica y facil de implementar, y explico un poco mi esquema
"realista".

El primero es simple, activamos los trigger pasado un tiempo del netjoin,
del cual consideremos que la red es segura, en caso de que haya otro split
los desactivamos. Realmente para los aways lo haria de otra manera, ya que
un topic se envia la peticion, si llega el nuevo topic listo, sino, no le
veo problema ninguno seguimos con el trigger activado hasta nuevo topic. En
los aways, tenemos que enviar una informacion al usuario, no podemos esperar
a que llegue ese away o no, por ello pondria algun tipo de timeout, si tarda
mas de x, no lo distribuimos y mantenemos el trigger.

P.D: El segundo es algo mas complejo en cuanto a implementacion y de
esquema. Queria resaltar que no es mas que una pincelada de la idea, se
aceptan criticas y "matanzas" :P.

Sino me explicado bien ( que puede ser... ) ... pues preguntar.. XD

Saludos.