[IRC-DEV] Canales masivos, dos soluciones.

[Zoltan]

> no recuerdo si fué idea de jcea, o de algun develepoer de otro
> daemon, pero recuerdo que el sistema que me pareció más
> correcto era el "delayed join".

En su día he comentado en la lista, el modo +D de "delayed join" en el
Universal IRCD de Carlo Wood...

Mail de 13 de febrero:
http://mailman.argo.es/pipermail/irc-dev/2002-February/000405.html

Posteo el trozo aquí, para facilitar mejor la lectura....


>>>>>>>
 Nuevo modo de canal (+D)
        ----------------------------
    Este apartado, a petición de jcea, será tratado con más detalle,
explicando a fondo su modo de funcionamiento.
NOTA IMPORTANTE: este modo está recibiendo actualizaciones en estos días, e
incluso a la hora de escribir las líneas ha llegado un parche nuevo, y me
obligó a actualizar vía CVS. Es una implementación que tiene menos de 10
días de vida.
    Es el "conference mode" o modo de conferencias, esta especialmente
pensado para dar charlas ante mucha gente, ahorrando caudal, de
"JOIN/PART/QUIT". La letra D del modo viene de "Delay Join", el
funcionamiento es lo siguiente:.
       - El modo +D lo puede poner o quitar cualquier OP del canal.
         Cuando un usuario entra en un canal con modo +D, su JOIN, solo sale
a si mismo. Los demás usuarios del canal, OP's incluidos, no se enteran de
su entrada al canal. En este caso, se le marca un flag al usuario (de forma
interna, en la memoria) que está en espera de join.
      - El dicho usuario, al entrar en el canal, solo recibe el NAMES de los
usuarios ya visibles, el resto (los de en espera de join) no
salen.
     - El usuario en modo de espera de join, puede ver los privmsgs, parts,
modes, etc.. de los usuarios visibles.
     - Cuando el usuario en estado de espera empieza a hablar en el canal,
entonces en este caso, se propaga el JOIN del usuario a los demás usuarios y
a continuación los privmsgs del usuario, y se le desmarca el flag al
usuario, que ya es visible por todos los usuarios.
    - Si se da voz o op a un usuario en modo de espera (sea un service o un
OP que tiene la certeza de que el usuario ha entrado al
canal), se propaga el JOIN a los usuarios, y a continuación el MODE
   - Cuando un OP o un service hace KICK a un usuario en estado de espera,
no sale nada ni a ellos, ni al resto de la gente del
canal. Solo verá el kick, el usuario "kickeado". (En mi opinión, debería
salir un JOIN + KICK, igual lo implementan en los próximos días. hay que
recordar que esta recibiendo continuos parches..)
   - Si un usuario en modo de espera, cambia el NICK, no se propaga nada a
los demás usuarios. Lo mismo con el QUIT
   - Cuando se quita el modo +D, se propagan los JOIN de todos los usuarios
en estado de espera.
   - En el WHOIS, los usuarios en espera de join (delayed join), salen con
un "<" al lado del canal.
   - Se ha añadido un nuevo parámetro al comando "NAMES", de momento solo
soporta el flag D, que es para sacar la lista de todos los usuarios del
canal visibles y en estado de espera.
   - Los services, (tenia un service P10 linkado y sacando por pantalla los
mensajes que llegaban), ven todas las entradas, como si no existiera el modo
+D
<<<<<<<<<<<<<

Entiendo que se podría mejorar algunas cosas de la implementación de Run.
Esto es muy válido para conferencias, etc... pero para canales de mucho
tráfico como los canales de ciudad, habría que pensar en otra solución,
porque muchísima gente entra al chat para hablar con otros..., pues "verían
poca gente", aunque con el método anterior, haciendo un "/names #canal D",
ya saldrían toda la gente en el "nicklist" del cliente de irc, pero no se
actualizaría... En fin, demasiados inconvenientes para canales grandes de
ciudades... A seguir con la discusión del tema.

Un saludo

zoltan