[IRC-DEV] Propuesta chan2

Mdk listairc at terra.es
Mon Jul 28 16:27:17 CEST 2003


En Undernet esta el bot X que casi todos sabemos que es un bot de control de
canales. Estuve el otro día en uno de los canales de Undernet, y vi que el
bot cambiaba constantemente el limite de usuarios del canal en el que
estaba, según sus entradas y salidas. Esta función del bot es regular las
entradas y salidas de un canal, para evitar entradas masivas (pudiendo ser
ataques de clones).

Mi propuesta es ¿porque no implementar un comando en chan2 que haga algo
parecido? se podría regular las entradas y salidas de un canal, así evitar
los ataques de clones, o en su defecto regular el trafico de usuarios de un
canal.

Me he estado documentando y he estado pensando como debería de funcionar
dicho comando. En principio, solo se podría usar por los administradores del
canal. Las variables como numero de entras, tiempo, etc... deben ser
reguladas por los administradores del canal, o si es preferible por los
usuarios con acceso al SET del canal.

A continuación, adjunto la documentación de los comandos implementados en X:

==============================================================

FLOATLIM - Activa o desactiva la opción del Floating-limit. Si está
activada, X restablecerá el límite del canal con un número predeterminado
por encima del número actual de usuarios en    el canal, y con un número
predeterminado de tiempo. Esta opción evita las entradas masivas al canal,
evitando inundaciones al canal. Esta opción se encuentra desactivada, si se
activara, en el comando "status" se mostrarán los modos en la línea de
"flags set". Por ejemplo: "FLOATLIM (MGN:3, PRD:20, GRC:1, MAX:0)." Esto
significa que FlOATLIM esta activado, con un FLOATMARGIN de 3, un
FLOATPERIOD de 20 segundos, un FLOATGRACE de 1, y sin FLOATMAX. Refiérase a
los comandos FLOATGRACE, FLOATMARGIN, FLOATMAX, y FLOATPERIOD para más
información.

/msg x set <#canal> floatlim <on|off>

FLOATGRACE - Fija el floating-limit de gracia del canal. Este número puede
ser entre 0 y 19. Ésto evita que X cambie el límite del canal si es menor
que el valor de gracia. En otras palabras, este valor corresponde al número
extra de usuarios que entren o salgan del canal antes de que X cambie el
límite. Como resultado, X no estará cambiando el límite a cada rato. El
valor predeterminado es 1.

/msg x set <#canal> floatgrace <0-19>

FLOATMARGIN - Fija el valor del floating-limit margen para ser usado en el
canal. Este número puede ser entre 2-20. El límite que X restablezerá será:
el número de usuario en el canal + el fijado en el FLOATMARGIN. El valor
predeterminado es 3.

/msg x set <#canall> floatmargin <2-20>

FLOATMAX - Fija el límite máximo para el floating-limit. Éste puede ser
cualquier número deseado, y prevendrá que X cambie el límite a un número más
alto que el número que usted determine. De este modo, es posible para un
canal limitar cuantos usuarios quieren en el canal en un tiempo deseado. El
valor predeterminado es 0, el cual desactiva esta opción.

/msg x set <#canal> floatmax <0 | máximo de  límite deseado>

FLOATPERIOD - Fija el periodo del floating-limit en segundos, para ser usado
antes de que X restablezca el límite del canal. Este número debe ser entre
20 y 200. El valor predeterminado es de 20 segundos.

/msg x set <#canal> floatperiod <20-200>

==============================================================

Este es el funcionamiento que tiene el bot, a continuación lo explico:

- Se debe de poner un limite de usuarios para que entren en el canal (por
ejemplo 4).
- Tiempo que debe de pasar (por ejemplo 20seg) antes de sumar los 4 usuarios
al total de usuarios del canal.
- Número extra de usuarios que entren o salgan del canal antes de que se
cambie el numero máximo de usuarios (por ejemplo 1).

Esos son los puntos mas interesantes a tratar. Además se debe de añadir, si
entran X usuarios en menos de X tiempo, dichos usuarios serán expulsados del
canal por ser considerado un ataque de clones, pero los valores de estas
variables deben oscilar entre los valores de las variables de los 3 primeros
puntos. Así si el limite de usuarios a entrar en un canal es 4 en 20
segundos, el valor de entrada máxima al canal seria de 4 usuarios en un
tiempo igual o inferior a 20 segundos (preferiblemente debería de ser un
numero menor de usuarios al definido, y superior a 2, y el tiempo debe de
ser mas o menos la mitad del definido en primer caso).

Pero hay cuestiones que surgen:

¿qué pasará cuando haya un split?

Cuando haya un split, dicho modo no afecta a la entrada y salida de los
usuarios del canal ya que los usuarios entran y salen forzados del canal por
el servidor así que no debe de impedir el paso de usuarios de un split. No
obstante los contadores del bot se deben de adaptar a este caso para que
cuente en caso de split.

¿se llenara el canal de cambios de modo +l?

Si, es probable que el canal se llene de cambios de modo +l, por eso
propongo que se cree un modo nuevo que limite el acceso de usuarios al
canal, pero que el cambio de dicho modo no se muestre en el canal y que el
mensaje de "no puede entrar el canal esta lleno" sea cambiado por "No se
puede entrar en canal en unos segundos, el canal esta sufriendo un ataque"
aunque tanto el mensaje como el nuevo modo esta en mano de los
desarrolladores.

¿impedirá el paso a los "clones" de los ataques masivos?

No se impedirán los ataques de clones al 100% porque eso depende de muchos
factores, lag del bot, entrada en el momento de un split... Pero se regulará
bastante, ya que la función principal de este comando es controlar el
trafico de usuarios de un canal.

La sintaxis del comando podría ser algo como:

/msg chan2 set #canal comando [limite de usuarios] [tiempo] [número extra de
usuarios]

Y el comando para complementar este (para "posibles ataques de clones")

/msg chan2 set #canal comando2 [limite2 de usuarios] [tiempo2]

Aunque dichos comandos pueden ser ampliados, modificados o suprimidos, todo
depende de los desarrolladores, y sobre todo de si se acepta la propuesta.
Pero eso ya depende de todos vosotros. Si hay alguna duda o no me he
explicado bien decídmelo.

Mdk




More information about the IRC-Dev mailing list