• 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

  • http://mailman.argo.es/pipermail/irc-dev/2003-December/003466.html

• 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
• 22/Mar/04: 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. Asignado: mount

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

• 25/Mar/04: Cuando se hace un "rehash" en un nodo con k-lines/g-lines y algún usuario en proceso de conexión dispara la k/g-line, aparece el mensaje "Notice -- K-line active for ", pero no pone nada más. Ni IP, ni nombre de usuario, ni nada. Se puede corregir eso o bien no procesar k/g-lines de usuarios en proceso de conexión; ya les saltará la expulsión cuando completen su entrada. Asignado: RyDeN
• 05/Abr/03: URGENTE: El SETTIME es un comando peligroso cuando hay lag en la red, ya que cada máquina sincronizará con una hora atrasada en función de su lag, y si el desfase supera la ventana de conexión, la red no consigue reenlazar. Pensar en un algoritmo e implementarlo. Asignado: N3TKaT

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).
• 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".
• 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()".
• 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, porque 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.
• En plataformas UNIX antiguas, que no tienen "vsnprint", al hacer el "./configure" (con la nueva zlib 1.2.1) aparece el siguiente texto:

    WARNING: vsnprintf() not found, falling back to vsprintf(). zlib
    can build but will be open to possible buffer-overflow security
    vulnerabilities.
   

• URGENTE: El SETTIME es un comando peligroso cuando hay lag en la red, ya que cada máquina sincronizará con una hora atrasada en función de su lag, y si el desfase supera la ventana de conexión, la red no consigue reenlazar. Pensar en un algoritmo e implementarlo.
• Cuando un nodo entra en la red, inyecta su "netburst" en ella. Si otro nodo de la red tiene un caudal limitado, puede tardar varios segundos en "tragarse" dicho burst, consumiendo considerables recursos en el proceso. Si mientras tanto el nodo original ha desconectado de la red, el hub debería limpiar el burst pendiente de "restos" de ese nodo original, para no consumir recursos de forma innecesaria. Esto es especialmente importante cuando la red está inestable y los nodos están entrando y saliendo constantemente. La carga que supone este hecho carga más aún las lineas, generando un efecto multiplicador fatal.
• Los mbuf deberían tener un contador de referencias, para poder compartir mbufs que se mandan a varias conexiones. Hay que tener cuidado con el tema de la "causalidad" de los mensajes.
• Verificar y solucionar esto:

  1078688012 JaNzUn buenas
  1078688110 JaNzUn al quitar el soporte para BDD_VIP en el config del hispano... qué más hay que deshabilitar para que no pete al compilar?
  1078688130 JaNzUn en concreto cuando lo quito tengo este error:
  1078688142 JaNzUn list.c: In function `free_user':
  1078688142 JaNzUn list.c:211: error: structure has no member named `virtualhost'
   

• Los comandos que solo los puede ejecutar un IRCop deben dar un error cuando los intenta usar un usuario normal. Por ejemplo, "rping".
• 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".

Para la próxima actualización

• Comprobar que el VULCAN el modo "+x" funciona correctamente. Es decir, que los usuarios sin IP personalizada NO tienen +x, y los que la tienen personalizada, sí.