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

Jesus Cea Avion jcea at argo.es
Sat Aug 23 18:29:51 CEST 2003


> Es una buena idea, pero aqui sigue el dilema: "¿Ancho y %CPU?"

A ver. En primer lugar, un par de precisiones:

- Por definición un "netburst" es muy traumático en CPU y BW.

- El borrado sólo se haría en canales en "NETRIDE", que deberían ser
"pocos". Es más, una vez que se empiece a usar "bien" la tecnología de
canales persistentes, este problema no existiría en los canales
registrados, que son la inmensa mayoría de los canales existentes en el
IRC.

El parche en sí sólo tendría que comprobar el TimeStamp que le llega con
el BURST con su valor interno. Si el canal que llega es más antiguo,
debe borrar el "topic" local del canal y propagar un borrado a los
usuarios de dicho canal.

El borrado en sí *NO* necesita propagarse por el resto de la red, porque
el resto de nodos, al ver el "BURST", harán lo mismo de forma "local".

Es decir, el consumo de CPU es mínimo y el de ancho de banda es
despreciable. Y considerando que el número de canales afectados irá a
menos a medida que usemos la "persistencia" de los canales, el parche es
un "win-win" (todo el mundo gana y nadie pierde nada).

El parche es interesante porque cuando hay un "netride" se supone que se
deshace TODO lo que haya hecho el "otro lado": se eliminan @ y +, se
ajustan los modos correctos, se borran los baneos, etc. El único resto
que queda es el topic. Y es lo que quiero solucionar.

¿Voluntarios?. ¡¡Es muy sencillito!!. El parche de Undernet está en
<https://sourceforge.net/tracker/?func=detail&atid=504082&aid=760425&group_id=63470>

> >> PS: Esto puede ser un principio de una futura (cercana) sincronización
> >> de "topics" y "aways" durante el "netjoin", a discutir próximamente.
> 
> ¿En UnderNet distribuyen topics/aways durante el BURST?

No que yo sepa.

> Respecto al tema de los aways... Ya se habló incluso de implementar un
> modo, para propagar AWAY's sin apenas gastar tráfico, es decir:

Sí, lo recuerdo. Es algo que estoy valorando con calma. No es algo que
me parezca urgente y hay otras cosas compitiendo por mis neuronas :-)

>  - El comando away pondría el modo digamos... "+u".
>  - Se propaga, el AWAY junto el MODE.
>  - Si se hace WHOIS al usuario, se comprueban los campos:
>        1. Si tenemos un motivo, lo ponemos...
>        2. No? Pues comprobamos si tiene el modo +u.
>        3. Evidentemente no está away, pasamos de todo.
>  - Idem para PRIVMSG y otros comandos que comprueban AWAY.
>  - Si hay un net.join, el nuevo servidor conocerá que un usuario está AWAY
> porque este, tiene modo +u, propagado por el servidor al que linka.
>  - El usuario se quita el away, manda AWAY para desactivarlo, y manda
> tambien MODE -u, para los servidores que hayan sido enlazados durante el
> periodo de ausencia de dicho usuario.

Sin que vaya a ser así, una idea que simplifica bastante la tuya:

En el netburst, el que lo manda marca los usuarios en AWAY. El que
recibe el BURST pone un "away" 'por defecto' en dichos usuarios.

No hacen falta modos extras, ni complejidades como comprobar las cosas
en dos sitios.

Una de las razones por las que no veo clara la "utilidad" de esto es que
mucha gente tiene un away que refresca automáticamente de forma
periódica, como puede ser el famoso "estoy comiendo - 1h20m" :-)

Para la gente que refresca su away cada 10 minutos, propagar el away en
el BURST sobra porque lo va a refrescar "pronto".

Para la gente que NO cambiamos el away, el poner un AWAY por defecto no
tengo claro si es bueno o malo :-p. Mis "aways" son muy literarios, y
una frase estándar por defecto no refleja la profunda reflexión que los
vió nacer };-)

-- 
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