			*Últimos Cambios*

Mi estado actual en Jabber/XMPP: - jabberES - jabber.org

Canales masivos

Última Actualización: 30 de Noviembre de 2.000 - Jueves

Motivación

Un canal masivo es un canal en el que el número de ocupantes del mismo es muy alto, normalmente ocasionado por una entrevista online, un atentado (caso de #lazo_azul), un juego, etc.

Con un servidor de IRC normal, un canal masivo tiene los siguientes problemas:

Si el canal es lo bastante grande, cuando alguien entra se puede caer por flood, sencillamente al recibir el listado de nicks. Este tráfico también supone un consumo de ancho de banda importante.
Aunque el canal esté moderado, la entrada y salida constante de usuarios, sus cambios de nick, etc., suponen un tráfico que hace casi imposible la comunicación en el canal. Asimismo, nuevamente, se trata de tráfico extra a canalizar.

Obviamente ambos problemas son graves en una red de las dimensiones de IRC-Hispano (en el momento de escribir el documento original, picos de 25.000 usuarios simultaneos, con canales con eventos multitudinarios varias veces por semana), y hay que buscar e implementar una solución.

La solución actual pasa por limitar el tamaño del canal con el modo "+l". Habrá gente que no pueda entrar, e incluso las que consigan colarse tendrán que enfrentarse a los problemas descritos. Comentaré, por curiosidad, que es posible que entren más usuarios en el canal que los que se haya indicado con "+l", sobre todo en situaciones de lag y de net joins.

Propuestas

Existen varias posibilidades, más o menos explicadas a continuación. No se dan excesivos detalles porque mi intención es mostrar la idea general.

Canales "alias"
Cuando un usuario entra en un canal, el servidor lo introduce realmente en un canal aleatorio de entre una serie de ellos. Por ejemplo, si el usuario entra en el canal "#entrevista_*", el servidor le introduce al azar en un canal de entre "#entrevista_1" a "#entrevista_9". Los canales "*" sólo pueden ser creados por un service.
- Ventajas:
  - El coste de implementación es muy bajo.
- Inconvenientes:
  - Los problemas iniciales se reducen, pero no se eliminan.
  - Es necesario un mecanismo para que un bot pueda entrar en todos los canales "*", mostrar en ellos mensajes, permitir la realización de preguntas, etc. Esto prácticamente obliga a que dicho bot sea, realmente, un service.
Canales "ciegos":
Cuando un usuario entra en un canal, sólo se ve a sí mismo. El canal sólo permite escribir en el mismo a los usuarios con modo "+k" (Channel Service). El canal no tiene ni modos ni topic.
- Ventajas:
  - Sencillo de implementar.
  - Los usuarios pueden saber cuántos usuarios son mediante un service que vaya enviando dicha información al canal, de vez en cuando.
  - Anónimos. Nadie sabe que estamos en ese canal.
- Inconvenientes:
  - El canal no tiene topic, aunque se podría implementar un sistema por service
  - Hay que implementar algún sistema de "realimentación" para que los usuarios sepan que, realmente, no están solos.
  - Puede ser necesario reprogramar services que interactúan con los nombres de los canales.
Service o bot de suscripción
Con este sistema, los usuarios envían un mensaje a un ente informándole de su interés en recibir, o dejar de recibir, determinada fuente de información. El ente puede, por ejemplo, proporcionar un listado de las fuentes posibles y el usuario elige cuales desea recibir.
El usuario recibe las informaciones de las fuentes a las que está suscrito a través de mensajes privados.
- Ventajas:
  - Sencillo de implementar.
  - No requiere tocar ningún servidor.
- Inconvenientes:
  - Si se trata de un bot, éste no tiene forma simple de saber cuando un usuario ha cambiado de nick, se ha salido del IRC u ocurre un split.
  - Si se trata de un service, resulta complicado (pero factible) el "recordar" las suscripciones de los usuarios aunque ocurra un split. Se puede hacer, por ejemplo, por numeric y timestamp.
  - El ente debe enviar una copia del mensaje por cada usuario suscrito.
Service de suscripción "multicast"
Es un refinamiento del servicio anterior. Los servidores se modifican para aceptar "susbcripciones" de usuarios, provenientes de un service y a instancia del propio usuario. Es decir, cuando un usuario se suscribe a una fuente, el service envía a su servidor home una orden de suscripción de dicho usuario a esa fuente determinada. Técnicamente, el servidor home "inyecta" al cliente IRC del usuario un join a un canal "ciego" (ver más arriba).
La única forma de entrar en ese canal es a petición del service.
- Ventajas:
  - Sencillo de implementar.
  - Las ventajas del sistema de suscripción.
  - Las ventajas del sistema de canales "ciegos".
  - Las suscripciones no se pierden aunque haya splits, cambios de nick, etc.
  - Pueden ser fuente los usuarios "+k" (Channel Service) y los propios services.
  - La fuente sólo manda un mensaje, independientemente del número de usuarios suscritos.
- Inconvenientes:
  - Hay que implementar algún sistema de "realimentación" para que los usuarios sepan que, realmente, no están solos. Una forma sencilla sería que el servidor home informase al usuario de cuántas personas hay en el canal cuando se produce el join, y que los recordatorios corriesen a cargo de un service (por ejemplo, cada minuto). Esta opción debería ser optativa, ya que pueden existir canales en los que ni tenemos interés ni queremos que se sepa cuánta gente está dentro.
  - Puede ser necesario reprogramar services que interactúan con los nombres de los canales.
  - Algunos clientes podrían tener problemas, dependiendo de cómo se elija el prefijo de los canales.
Canales con "visión parcial"
La idea de estos canales es que los usuarios con op vea a todo el mundo, pero los usuarios sin op sólo se ven a sí mismo y a los usuarios con op.
Si no es posible dar o quitar op una vez que el canal se ha transformado a "visión parcial", la implementación puede resultar relativamente simple. Pero si se puede dar y quitar ops de la forma tradicional, el sistema se complica extraordinariamente, ya que es preciso "inyectar" artificialmente joins y parts para, por ejemplo, que un usuario que acaba de recibir op sea visible por el resto de la red, o para que dicho usuario, al perder el op "vea" como todos los demás usuarios sin op abandonan el canal.
- Ventajas:
  - El usuario puede "ver" en el canal a las fuentes.
- Inconvenientes:
  - Implementación extremadamente compleja, delicada y frágil.
  - Posibles desyncs, entre otras razones, porque es necesario crear un canal "normal" antes de pasarlo a "visión parcial" mediante un modo especial distribuído por un service. Esto crea infinidad de oportunidades para race conditions, especialmente en situaciones de lag, splits y net joins.

Historia

30/Nov/00: Primera versión de este documento.