• 01/Oct/03: Pasar la tabla o a FLAGS individuales. Osea, cada bit, un flag. Asignado: N3TKaT
• 10/Oct/03: La parte final de "set_mode_local" y "set_mode_remoto", que es la que activa y propaga modos, es común para ambas rutinas y puede sacarse "factor común". Asignado: jcea
• 10/Oct/03: En "set_mode_*" hay muchas confusiones en el código original entre "sptr" y "cptr". Es un milagro que no haya fallado nunca. Asignado: jcea
• 10/Oct/03: En "set_mode_remoto" se puede limpiar código de "IsOperOnLocalChannel" y "OPER_MODE_LCHAN". Asignado: jcea
• 10/Nov/03: En el MOTD aparece la fecha y la hora. Poner también el "timezone". Asignado: ABoR
• 16/Dic/03: Aclarar y documentar el uso de "simular_registrado" en "make_virtualhost()". Asignado: N3TKaT
• DONE 03/Feb/04 - 18/Dic/03: Eliminar las líneas "N". No tienen mucho sentido, hoy por hoy. Actualizar todo lo necesario, incluyendo "make config" o "chkconf". Asignado: N3TKaT
• DONE 03/Feb/04 - 27/Ene/04: No se ve lo mismo si no hay MOTD local que si no lo hay pero existe una única linea "%LOCALMOTD" en el MOTD de la BDD. Asignado: mount
• DONE 03/Feb/04 - 03/Feb/04: Reparar un assert (1075334016 zoltan ircd: ircd.c:521: open_debugfile: Assertion "cptr->sockhost" failed.) que falla al compilar el ircd en modo debug. Asignado: RyDeN
• 03/Feb/04: Ante cambios en la tabla "o", ajustar +h, -h apropiadamente, y el resto de modos. Asignado: mount
• 03/Feb/04: Crear una rutina que sea invocable por "m_nick_local" y "m_rename" que se encargue de poner un nick nuevo a un usuario, ponerle un nick "invitado" y se encargue de todo el tema de ajustar modos apropiadamente. Debe ajustar correctamente también los contadores de +h, etc. Asignado: N3TKaT
• DONE 05/Feb/04 - 05/Feb/04: Comprobar todos los bucles que buscan entre todos los usuarios de la red para posibles fallos relacionados con la migración de memoria. Asignado: RyDeN
• DONE 05/Feb/04 - 05/Feb/04: Ver la forma de simplificar y limpiar código para "not_sender". Asignado: RyDeN
• 26/Feb/04: Este problema parece complicado de reproducir: Asignado: mount

   [17:13] <[_-NeO-_]> chkconf.c:67: redefinition of `struct Client'
   [17:13] <[_-NeO-_]> make[1]: *** [chkconf.o] Error 1
   

Parches pendientes de asignar

• Reescribir el código para evitar los warning "dereferencing type-punned pointer will break strict-aliasing rules".
• "Slab allocator" para cadenas cortas.
• Cuando se carga la BDD de disco duro, al arrancar el IRCD, no hay ningún usuario conectado. Aprovechar ese hecho para optimizar el tema de regenerar las IPs virtuales, nicks prohibidos/suspendidos, etc.
• Pensar qué debe pasar con la caché de IPs virtuales cuando se cambia la clave de cifrado de IPs de la red. ¿Se borra toda la caché?. ¿Se comunica las nuevas virtuales a los usuarios?.
• Cuando hay varias lineas C/N en varias clases, con tiempos de conexión diferentes para simular prioridades, si se conecta una linea de alta prioridad y la conexión se corta (por ejemplo, clave incorrecta), pues persiste en reconectar con esa conexión de alta prioridad, en vez de probar otras.
• Si hay varios %LOCALMOTD en el MOTD distribuido por BDD, sólo se muestra el primero. Solucionarlo o documentarlo.
• Documentar o eliminar el uso de la variable "count" en la rutina de MOTD.
• Los admins no deberían tener acceso a la BDD de nicks, aunque las claves estén "hashed". No lo necesitan.
• "Numerics" generados por servidor. Máscara larga, para que no se repitan "numerics" aunque haya mucho lag en la red.
• En el "make config", el texto del "watch" tiene al menos una errata.
• Completar lo comentado en el parche "u2.10.H.08.76". "IsUser()" debe ser TRUE en el lugar correcto de "m_nick_*".
• Limpiar cachés de IPs virtuales, caché de claves de cifrado, etc cuando se recibe un borrado de registro (sin alta nueva) o cuando se borran las tablas por completo, por orden externa o por corrupción.
• Para pensar: un nodo "jupeado" debería informar de ello a sus usuarios, indicándoles que entren por otro nodo de la red. ¿Usar la infraestructura de MOTD distribuido?. ¿Darle la apariencia de un bot?. ¿Riesgos de que lo suplante un usuario?. ¿NOTICE de servidor cada "x" segundos?.
• VERIFICAR: Cuando hay una colisión de nicks (en un "net join"), se deben indicar las IPs virtuales, no las reales (si los usuarios tienen +x).
• Para convivir bien con el futuro "slab allocator", hay que comprobar que "LOGFILE" tenga un tamaño "razonable".
• Para convivir bien con el futuro "slab allocator", hay que comprobar que "ttyname(2)" tenga un tamaño "razonable".
• Para convivir bien con el futuro "slab allocator", hay que comprobar que "aconf->host" tenga un tamaño "razonable".
• Para convivir bien con el futuro "slab allocator", hay que comprobar que "aconf->name" tenga un tamaño "razonable".
• En el parche u2.10.H.08.79 hay algo que no me gusta:

  +    if (cptr->name != NULL)
  +      RunFree(cptr->name);
  +
  +    if (me.name != NULL)
  +    {
  +      cptr->name = (char )RunMalloc(sizeof(char)(strlen(me.name)+1));
  +      strcpy(cptr->name, me.name);
  +    } else {
  +      cptr->name = (char )RunMalloc(sizeof(char));
  +      (cptr->name) = '\0';
  +    }
   

  No veo ni entiendo la necesidad de pedir un byte para una cadena vacia, en vez de usar un puntero NULL, simplemente.

  Hay otro caso parecido en u2.10.H.08.106.

• Una pequeña optimización de u2.10.H.08.79 es que si un usuario cambia de nick, y dicho nick mide lo mismo que el anterior, no se haga un nuevo malloc. Ver si ello es ventajoso con el futuro "slab allocator".
• Todos los cambios que se están haciendo en la gestión de memoria alteran la fiabilidad de informes como los proporcionados por "/stats M" o "/stats z". Cuando se complete el sistema, hay que revisar todo esto.
• Limpiar el tema metido en u2.10.H.08.82.
• Listar los canales de un usuario por orden alfabético.
• Si "desuspendemos" un nick en uso, se le hace un "rename". Es posible que convenga dejarlo de momento por compatibilidad con "nick".
• Para mediados de 2004: Permitir los nicks "inv123456". Hay que quitarle también el rechazo en "nick".
• Integrar ZLIB 1.2.1.
• Valorar si conviene meter el "timezone" en el "/info".

  • http://www.argo.es/~jcea/wikis/irc-dev/logs/200312/irc-dev-20031203

• Adaptar el ircd para que soporten las funciones *printf_irc un límite del ancho del buffer para el futuro "SlabStringAllocDupFmt()".
• Modularizar la gestión de sockets para que se soporten fácilmente (y con la mínima intrusión) diferentes paradigmas: select, poll (los actuales), kqueue, epoll, etc.

  • http://mailman.argo.es/pipermail/irc-dev/2004-January/003513.html
  • http://www.kegel.com/c10k.html

• Una vez que la gestión de sockets esté modularizada, implementar gestión por RT signals (Linux 2.4).

  • http://mailman.argo.es/pipermail/irc-dev/2004-January/003513.html
  • http://www.xmailserver.org/linux-patches/nio-improve.html (Benchmarks)

• Una vez que la gestión de sockets esté modularizada, implementar gestión por epoll (Linux 2.6).

  • http://mailman.argo.es/pipermail/irc-dev/2004-January/003513.html
  • http://www.xmailserver.org/linux-patches/nio-improve.html (Benchmarks)
  • http://epoll.hackerdojo.com/

• Una vez que la gestión de sockets esté modularizada, implementar gestión por /dev/poll (Solaris).

  • http://mailman.argo.es/pipermail/irc-dev/2004-January/003513.html
  • http://www.kegel.com/dkftpbench/Poller_bench.html (Benchmarks)

• Una vez que la gestión de sockets esté modularizada, implementar gestión por kqueue (*BSD).

  • http://mailman.argo.es/pipermail/irc-dev/2004-January/003513.html
  • http://www.kegel.com/dkftpbench/Poller_bench.html (Benchmarks)

• En la rutina "m_server" de "s_serv.c", hay cierta confusión en el uso de "aconf" y "bconf", probablemente derivado del uso de N-LINES, que ya no existen. Hacer algo de limpieza al respecto.
• Ante cambios en la tabla "n", ajustar +r, -r apropiadamente, y el resto de modos. "glog" me ha confirmado (jurando por Snoopy y Mafalda :-) que ésto no será un problema para los services.
• Eliminar "PunteroACadena" que sobran, poruqe hay un campo que nunca es NULL.

  • http://www.argo.es/~jcea/wikis/irc-dev/logs/200401/irc-dev-20040127

• Estudiar la posibilidad de utilizar funciones "mmalloc".
• Hacer un "indent" en "persistent_malloc.c" da errores. Ver si el problema es de "indent" o de "persistent_malloc.c" y, en ese último caso, solucionarlo.
• Cuando un usuario no tiene DNS inverso, podemos ahorrar memoria en su "host", ya que sería innecesario. Evaluar. Ahora mismo (26/Feb/04 16:50) el 15'54% de las conexiones a IRC-Hispano no tienen DNS inverso.
• Puede ser interesante un sistema de IP->host mediante una tabla HASH, en vez de almacenar los datos en la estructura cliente. Evaluar. Útil si hay varios usuarios con la misma IP.
• Usar técnicas de "suffix sharing" para el "hostname" de los usuarios. Evaluar. Ahora mismo (26/Feb/04 16:50) hay una media de 2.88 conexiones por cada "sufijo", entendiendo por sufijo lo que sigue el primer punto en el "hostname". Si subdividimos el sufijo componente a componente el ahorro es brutal.
• En la ocultación de IPs (modo +x) la mayoría de las veces pocos usuarios van a ver la IP real o el HOST real de un usuarios. Aprovecharse de eso para ahorrar memoria.

Documentar para la próxima actualización

• DONE 18/Feb/04 - Las líneas "N" desaparecen.