Mi estado actual en Jabber/XMPP: - jabberES - jabber.org

IRC-DEV

PaginaDeEntrada ParchesIRCD ParchesIRCDNov2003

Usuario: Anonymous User

• 01/Oct/03: Pasar la tabla o a FLAGS individuales. Osea, cada bit, un flag. Asignado: N3TKaT
• 01/Oct/03: 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: mount
• 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
• DONE 04/Nov/03 - 29/Oct/03: Cuando se propaga por la BDD el registro que activa la inserción o la eliminación de la IP cifrada para los usuarios en la tabla "w", debe hacerse limpieza de la caché de IPs virtuales. Asignado: RyDeN
• 04/Nov/03: Las cadenas con tamaño estático en las estructuras de clientes, canales, etc., que no suelen aprovechar su tamaño (por ejemplo, se define un tamaño de X bytes pero se suele usar mucho menos; ejemplos: clave de canal, topic, nombre de canal, hostname del usuario, etc), pasarlas a malloc/free, con vista a migrarlas de nuevo al futuro "slab allocator". Asignado: RyDeN
• DONE 27/Nov/03 - 07/Nov/03: Cuando un nodo hace "bounce" de cambios de modos de un usuario, debe mandarle también un "-o" para quitar el op a dicho usuario y "curar" el desync. Ver si es necesario en otros comandos, como "topic" o "kick". Asignado: N3TKaT
• DONE 10/Nov/03 - 10/Nov/03: Cuando se pasa una nueva clave de cifrado de IPs virtuales, si existen usuarios a medio conectar, existe el riesgo de que falle un "assert()" en "elimina_cache_ips_virtuales()". Más concretamente en "BorraIpVirtual()". El problema es que comprobar "sptr->user" y "IsUser(sptr)" no son equivalentes. Es preferible la segunda comprobación, ya que es más "fuerte" que la primera. Asignado: jcea - Ver parche u2.10.H.08.78
• 10/Nov/03: En el MOTD aparece la fecha y la hora. Poner también el "timezone". Asignado: ABoR
• DONE 27/Nov/03 - 27/Nov/03: Cambiar todos los " puntero ? puntero : "" " por un macro. Asignado: RyDeN
• 27/Nov/03: Cuando se comprueba "invitado-123456", hacerlo "case insensible", y verificar que la segunda parte son todo números. Asignado: N3TKaT
• 29/Nov/03: Se declara en varios sitios "static void send_umode_out(aClient a, aClient b, int c, int d, int e);". Hacer limpieza. Asignado: N3TKaT

Parches pendientes de asignar

• DONE 07/Nov/03 - Cuando toda la red esté actualizada (u2.10.H.08.55), eliminar el registro "permite.nicks.largos.en.local".
• Reescribir el código para evitar los warning "dereferencing type-punned pointer will break strict-aliasing rules".
• Este problema parece complicado de reproducir:

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

• "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.
• 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.
• 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.
• Aclarar y documentar el uso de "simular_registrado" en "make_virtualhost()".
• 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_*".
• Eliminar las líneas "N". No tienen mucho sentido, hoy por hoy.
• 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.

• Ver la forma de simplificar y limpiar código para "not_sender".

  • http://www.argo.es/~jcea/wikis/irc-dev/logs/200311/irc-dev-20031107

• 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.
• Cuando forzamos un GHOST durante la conexión, no sale el destinatario que queremos que salga en el NOTICE:

   nick jcea!CLAVE
   :nick2!-@- NOTICE  :Sesión fantasma del nick jcea ha sido liberada.
   :nick2!-@- NOTICE jcea :Contraseña aceptada. Bienvenid@ a casa ;)
   

  Falta el destino del primer NOTICE. No tiene porque ser el nick del usuario, pero algo hay que poner.

• Limpiar el tema metido en u2.10.H.08.82.
• Ante cambios en la tabla "o", ajustar +h, -h apropiadamente, y el resto de modos.
• 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".

CambiosRecientes VerAyuda

editar esta página (requiere autentificación)