[IRC-DEV] Seguimiento de redes IRC: Daemon IRCD Universal de Carlo Wood aka Run

[Jordi Murgo]

El mar, 12-02-2002 a las 23:14, Zoltan escribió:

>         Cambios en nicks, canales.
>         -----------------------------
>             Se ha cambiado el "NICKLEN", de por defecto, a 30 caracteres,
> siendo configurables en el "make config" los valores de "NICKLEN" del
> servidor y el máximo en la red. pudiendo ser diferentes en varios servidores
> de la red.

Unreal soporta esa misma longitud. 

Para que la experiencia sea positiva para los usuarios, al tema longitud
hay que añadirle el soporte LOCALE a los Nicks. A estas alturas, yo
eliminaría la equivalencia mayúsculas/minúsculas que impusieron en su
dia los finlandeses, y usaría el soporte LOCALE del sistema operativo.
Para Unreal tengo el patch funcionando en producción sin problemas,
estamos viendo como lo integramos en la negociación entre servers, pk es
importante que todos los servers de la red usen el mismo LOCALE. A los
clientes se les comunica con un 005 LOCALE=es_ES.ISO-8859-1
CHARSET=ISO-8859-1

>             Así mismo, se ha reducido el "CHANLEN" de 200 a solo 50, hay que
> tener en cuenta que hay clientes, como el mIRC, que no funcionan
> correctamente con canales más de 64 caracteres.

Unreal utiliza 64

>             El TOPICLEN de los canales ha sido aumentado de los 160
> habituales a 250 caracteres.

Unreal tiene 307, y lo sincroniza en los burst (lo cual no es ni
positivo ni negativo ni todo lo contrario, dependiendo de quien defienda
user-friendly-experence o ahorro-bandwith) :)

>         Nuevo modo de usuario (+h)
>         ------------------------------
>             Es el "helper mode", más conocido en nuestras fronteras como
> OPERador, por lo que he visto, solo puede ponerlo un IRCop a sí mismo, y no
> sale nada en el "WHOIS", tan sólo sale en el "WHO", con la letra "h".

Este ya lo teniamos implementado, es el mismo que usan otros daemon
(Unreal también)

>         Nuevo modo de canal (+D)
>         ----------------------------

Es el equivalente al modo +u de Unreal (auditorium mode)

Esta implementación es mucho mas elegante, al mantener el estado de
delayed en el chanuser, y es absolutamente consistente en protocolo
server-usuario. Personalmente le añadiria un simulacro de "massive-part"
de los usuarios existentes en el canal sin voice/halfop/op en el momento
de poner el modo +D (poniendolos delayed), para que te vieras solamente
acompañado de los "VIPs" del canal. El resto lo dejaria tal como lo ha
hecho el equipo de Run. 

>             Posibilidad de que sólo los IRCOPS puedan crear los canales,
> esto es ideal para redes de chat vía webchat con canales fijados. En este
> caso, si un usuario intenta hacer un "JOIN" para crear un canal, saldrá un
> mensaje de que no existe el canal, y que haga un /list para listar los
> canales.

Yea, en Unreal 3.2 se hace con una lista de allowed channels, así no
tienes que dejar a nadie dentro de los canales para que los usuarios
puedan seguir entrando en ellos. Ademas, la lista de allowed channels
usa regexp's:

	#canales_privados_.*


>             En canales moderados (+m), los usuarios que no pueden hablar,
> tampoco pueden cambiar de nick. Como en Dal.Net

En Unreal han añadido además un modo +N de canal, que impide que te
cambies el nick si estas en un canal +N

Buen trabajo el de Run.

Voy a bajarme el código, a ver si ha implementado ya POSIX RT signals
para le manejo de eventos de red, en substitución de select/poll. Con
Unreal conseguimos un 50% más de capacidad en los experimentos de stres
al implementar kevent/kqueue de FreeBSD, y calculo que con las colas de
señales RT será equivalente. No he llegado a ponerlo en producción, pero
ircd es el target perfecto para aplicar estas técnicas basadas en cola
de eventos por cambio de estado de los sockets.

Bajo linux, con poll o select, al alcanzar los 2000-2500 sockets la
maquina se pone practicamente al 100% de CPU, y quien consume es el
kernel, buscando los estados de los sockets. 

Con select() tenemos, además, que preparar el fdset, recorriendo todas
nuestras sesiones, hacer el select, y recorrer de nuevo todas las
sesiones comprobando el fdset. Cuando hablamos de 2500 sesiones este
tiempo YA es apreciable.

Con poll() nos ahorramos la primera parte, pk la vamos preparando en
base a los eventos acaecidos. Y la segunda parte es optimizable,
montando una tabla Client *fdtable[64*1024] de descriptores de fichero
apuntando a su sesión. Pero nadie nos mejora el tiempo perdido por el
kernel. 

kevent y RT signals trabajan por cambio de estado, solo tenemos que
declarar cuales on nuestros intereses sobre un fd, y nuestro bucle de
recepcion de eventos va atendiendo a medida que nos llegan. 

kevent tiene la ventaja de que con los eventos puede retornarnos un
opaque, que puede ser un puntero a nuestra sesion, mejorando tanto la
velocidad en kernel como en la capa de usuario. La desventaja es que
solo está disponible en algunos *BSD

RT signals tienen la ventaja de que podemos priorizar los eventos de
sockests server-server, sobre los de accept, y estos sobre los de
server-client. Es un standard POSIX. La desventaja es que nos obliga a
mantener el codigo poll/select anterior, para cuando se produce una
excepción de cola de eventos llena.

Salut,		<jordi/>

-- 
Jordi Murgó i Ambou
Internet Web Serveis, S.L.
Lleida / Catalonia / Spain
Tfn: +34-973234106