[IRC-DEV] Historia del parche de ampliación de tamaño de nicks

[Jesus Cea Avion]

El objetivo es ampliar el tamaño de nick de 9 a 15 caracteres. La
ampliación debe hacerse en dos etapas. En una primera etapa los nodos
aceptarán usuarios remotos de 15 caracteres, pero en local solo
permitirán 9. Una vez que toda la red esté actualizada, una segunda
actualización ampliará el límite local a 15 caracteres.

Para evitar dos actualizaciones del IRCD, se va a usar un registro
temporal de la nueva tabla "z" de la BDD. Es el registro
"permite_nicks_largos_en_local", de significado obvio. Los pasos, por
tanto, serán:

1. Actualizar Gaia con la nueva versión.

2. Seguir progresando en el ircd.

.... tiempo ....

3. Convocar una actualización obligatoria.

5. Cuando todos los nodos estén actualizados, propagamos el registro
"permite_nicks_largos_en_local".

6. Se crea un nuevo IRCD que no requiera dicho registro, trabajando
siempre con nicks largos.

.... tiempo ....

7. Cuando haya una actualización obligatoria nueva, podremos eliminar ya
el registro de la BDD, superfluo.

Voy a detallar cómo creo ese parche, para aprendizaje:

En primer lugar, cambio "NICKLEN" a 15 caracteres, y defino un
"NICKLEN_OLD" a 9. Con este cambio y una recompilación, el IRCD ya
aceptará nicks largos. El problema es que transmite nicks largos a la
red, donde el resto de nodos no lo soportan.

Es necesario tener un mecanismo para restringir el tamaño de los nicks
locales de forma temporal, mientras la red no está actualizada. Eso lo
detallo luego.

El primer paso es intentar localizar "problemas". Para ello se hace una
búsqueda de "NICKLEN" en el ircd:

* crypt/tea/cifranick.c: No toma el valor del IRCD propiamente dicho.
Actualizamos su valor.

* channel.c: No parece haber problemas.

* hash.c: "jupeTable" crece bastante de tamaño. Pasamos de 40Kbytes a
64Kbytes. No me parece un problema, de momento, aunque habría que
echarle un vistazo para simplificarlo. ¿Parche futuro?. Además, hoy por
hoy en IRC-HIspano el "jupeo" de nick se controla por BDD, así que todo
esto debería eliminarse.

* m_watch.c: El incremento de tamaño puede ocasionar un error de
compilación, dependiendo del "CLIENT_FLOOD" y del "MAXWATCH". Los
parámetros por defecto son 96*9= 864 (<1024). Pasando a 15, sería
96*15=1440 (>1024). Nos pasamos y va a fallar.

Hay tres opciones:

- No compilar con WATCH.

- Bajar MAXWATCH. Eso es peligroso, porque el mIRC tiene un bug que hace
que se "pierdan" los "notify" de los nicks que sobran.

- Subir el CLIENT_FLOOD: Es la opción que menos me gusta, pero no queda
más remedio. Subo el valor por defecto a 1536 bytes (1440<1536). Hay que
recordar, cuando se convoque la actualización recomendada, que hay que
subirlo. Para ello eliminamos la línea "CLIENT_FLOOD" en
"config/.config".

* send.c: Nada reseñable.

* whocmds.c: Nada reseñable.

* s_user.c: En el numeric "005" enviamos el tamaño permitido del nick.
Si ponemos "9", al cliente le pueden llegar nicks más largos de otros
nodos, y a saber lo que puede pasar (¿Casque¿). Si mandamos "15" y no
está activado "permite_nicks_largos_en_local", el usuario puede enviar
un nick largo y que el IRCD no va a aceptar. Eso parece preferible a que
casque el cliente, y sería un problema "temporal".

Tocamos un par de líneas de código en "m_nick" para recortar el nick si
es demasiado largo, buscando el registro en la BDD. Por cierto, durante
este periodo de transición es OBLIGATORIO compilar el IRCD con la BDD,
para que sepa cuando debe activar la segunda fase.

Echad un vistazo al CVS.

Con esto debería estar todo hecho. Solo falta hacer pruebas.

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