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

Fase 2: Nodo Modular

Última Actualización: 27 de Diciembre de 2001 - Viernes

Aunque el objetivo final es implementar un esquema distribuido, para acelerar el nacimiento de la red se ha empezado por utilizar un esquema centralizado empleando las facilidades proporcionadas por los servidores IRCd de Undernet.

En estos momentos los nodos de control son:

• OLIMPO: Este es el nodo principal de la red
• ORACULO: Nodo secundario y de pruebas

Las operaciones que cubren esos nodos son:

1. Control de clonos: La red sólo permite dos conexiones por IP
2. Control de OP: Permite dar y quitar OP en los canales
3. Control de las Bases de Datos Distribuidas: Puerta de entrada para las BDD de clonos, nicks, opers, IPs virtuales, etc.

Fase 1: El Nodo de Control

Fase 3: Nodo Multitarea

Módulos Implementados

• 29/Feb/00 Versión 32

  • Solucionado un problema de memory leak debido a que se abría el entorno de base de datos con frecuencia, pero no se llegaba a cerrar nunca.

  • Enlazado de la libería DB de forma dinámica.

  • Añadido comando "dbadd" para añadir y borrar nuevos registros en las bases de datos distribuídas, sin necesidad de utilizar los comandos "raw".

  • Con "stats" se muestra el estado de todas las tablas soportadas por el IRCD. En este momento, son "b", "i", "n", "o", "t" y "v".

  • El 80% del código de Olimpo se carga ahora como librería compartida, para que cuando se carguen otros módulos, estos tengan acceso a las rutinas.

  • Se implementa la API PRIVMSG "1", en estado de cambio constante. Ahora ya es posible escribir módulos sencillos, que se comunican vía privmsg con el mundo exterior.

  • Cada módulo puede definir los nicks que desee.

  • Olimpo soporta un máximo de 63 nicks, sumando todos los módulos cargables.

  • Implemento un módulo simple, SALUDA, que sencillamente te saluda cuando le envías un privado.

  • Para mayor comodidad, el comando "users" muestra los nodos ordenados por orden alfabético.

• 01/Mar/00 Versión 33

  • Eliminados varios warning al compilar Olimpo.

  • Implementados los comandos "dlload", "dlunload" y "dllist". La carga y descarga de librerías está limitada a mí, pero el listado es accesible para los operadores.

  • Las librerías pueden especificar un comentario para que aparezca en "dllist".

  • Se exporta el entorno de base de datos, para que las librerías puedan operar con sus bases de datos, en modo Concurrent Data Store.

  • API extendida para que un módulo pueda obtener los flags de un nick.

  • API extendida para que un módulo pueda obtener el nick textual de un identificador.

  • Cuando se hace un "dllist" también se listan los nicks registrados por cada módulo.

  • Creación del módulo AGENDA:

    • Solucionado un error de corrupción de memoria en la gestión de la base de datos: no se especificaba el flag "DB_DBT_MALLOC", por lo que la librería hacía un "malloc" local y luego se intentaba liberar desde fuera.

    • Solucionado un problema con el borrado de registros, ya que se estaba reutilizando memoria antes de haber terminado con ella :-).

    • Imprime la versión de la base de datos en el "dllist".

  • Se imprime en pantalla el aviso de la apertura inicial de la base de datos, para poder detectar si está bloqueada.

• 01/Mar/00 Versión 34

  • Actualización de la base de datos de clones en disco cada cinco minutos.

  • Eliminado un warning cuando se compila Olimpo en modo desarrollo.

  • Ampliada la API para que los módulos puedan hacer logs de los comandos que les envían los usuarios.

  • El sistema de logs permite identificar también qué módulo ha generado la salida.

  • Módulo AGENDA:

    • Actualización de la base de datos en disco cada minuto, si hay algún mensaje.

    • Utiliza la ampliación de API para hacer log de los comandos que se le mandan.

• 02/Mar/00 Versión 35

  • Definida una nueva API, llamada "Notify", para recibir notificaciones de entradas, salidas, splits y cambios de nick de usuarios. En esta versión se implementa sólo la función para notificar la aparición de nicks registrados.

  • La tabla de módulos cargados no inicializaba correctamente la API "PRIVMSG" si el módulo cargado no la utilizaba.

  • Corregido un problema con la función de la API "PRIVMSG" "nuevo_nick".

  • Módulo AGENDA:

    • La agenda reconoce cuando un usuario sin nick registrado pasa a estar con nick registrado, y:

      • Le indica las entradas para la semana en curso.

      • Le recuerda el uso de la ayuda.

    • También avisa cuando se trata de un nuevo usuario, no de un cambio de nick.

• 02/Mar/00 Versión 36

  • Creado el programa "agenda_lista", que lista los registros contenidos en la agenda. Útil para poder hacer backups.

  • Cuando se invoca a un módulo a través de la API "NOTIFY", toda la información relativa al nick en cuestión ya ha sido actualizada.

  • Cuando se compila Olimpo en modo desarrollo no carga ningún módulo dinámico al arrancar, pero cuando se compila como "estable", sí.

  • Cuando un módulo declara un nuevo nick, le puede dar los modos de usuario que desee.

  • Módulo AGENDA:

    • Añado mensajes de error cuando:
      • Se llena la agenda. Actualmente, se permiten 200 entradas por nick.
      • El usuario introduce un mes inválido.
      • El usuario introduce un día inválido.
      • El usuario introduce un parámetro o más, pero menos de los necesarios.
      • Si el usuario introduce un comando desconocido, se le insta a usar la ayuda.
      • Se intenta borrar una entrada inexistente.

    • Añadido un texto explicativo sobre el objetivo de agenda cuando se pide ayuda.

    • Cuando se borra una entrada y el registro de ese día se queda vacío, en vez de guardar el día vacío sencillamente se borra el registro completo. De esta forma se genera menos basura en la base de datos.

    • Elimino toda la información relativa a la agenda de un nick determinado, cuando la agenda en cuestión queda vacía. De esta forma se genera menos basura en la base de datos.

    • El módulo de agenda es cargado de forma automática al arrancar Olimpo, si se trata de la versión "estable", y no la versión de desarrollo.

    • En vez de imprimir toda la semana, agenda sólo imprime dos días cuando recibe un evento a través del API "NOTIFY".

    • Si el usuario especifica un comando inválido, la agenda no responde. De esta forma evitamos bucles entre bots.

• 06/Mar/00 Versión 37

  • Defino una nueva base de datos que va a contener nicks de los que se han hecho drop, de forma que los módulos que tengan bases de datos asociados a nicks puedan eliminar los registros cuando se da de baja un registro de nick.

  • Defino la API "NOTIFY_DB" para informar de estos casos.

  • El sistema permite dar de baja nicks aunque no estén cargados todos los módulos. Cuando se carga un módulo que requiere este tipo de notificaciones, se le envían todas las bajas recibidas que todavía no hayan sido procesadas por el módulo.

  • Las notificaciones de nicks eliminados atrasadas son enviadas cuando termina la rutina inicio del módulo, si anuncia soporte para esta API en ella.

  • Cuando un módulo recibe una notificación de drop de nick registrado, recibe el nick normalizado.

  • Módulo AGENDA:

    • Cuando se recibe un drop, eliminamos las entradas de la agenda para ese nick.

• 14/Mar/00 Versión 38

  • Ahora que Olimpo se está utilizando para aplicaciones críticas, muevo todo el sistema de base de datos a transacciones, en vez de aplicaciones concurrentes. Entre otras cosas ello obliga a detectar y corregir situaciones de deadlock. Poco probables, pero posibles...

  • Hay que reprogramar los programas de apoyo para que soporten transacciones. Lo hago de forma tal que tengan menos prioridad; es decir, si uno de estos programas intenta bloquear un objeto actualmente bloqueado, aborta. De esa forma evito en lo posible los "deadlocks", aunque sea a costa de tener que repetir la ejecución de estos scripts varias veces.

  • Examinando el estado de las bases de datos puedo ver que las estadísticas muestran transacciones abortadas, aunque muy pocas. Tras dedicar algunas horas y estudiar el tema con calma, incluyendo analizar el código fuente de la librería de base de datos, llego a la conclusión de que no es un problema, ya que se trata de transacciones implícitas realizadas por la librería de base de datos cuando se le indica que debe crear la base de datos si ésta no existe. ¡¡Esa es la razón!!. Es un poco confuso, pero lo ignoramos.

• 21/Mar/00 Versión 39

  • Modificadas algunas cosas para que compile y se ejecute bien tanto en ESNET como en IRC-Hispano.

  • La gestión de transacciones en la base de datos debería detectar y solucionar correctamente el problema de los "deadlocks". Normalmente no se producen, salvo que el servidor se muera en estado inconsistente. Si podemos detectar los "deadlocks" no necesitamos realizar un "db_recover" cada vez que el servidor muere durante el desarrollo de nuevos servicios.

    Configuro el sistema para que en caso de bloqueo se aborte la transacción más antigua, con la idea de que la transacción abortada se corresponda con una invocación de Olimpo que murió de forma "trágica".

    Este sistema puede resultar potencialmente problemático cuando se accede a las bases de datos a través de las herramientas externas de Olimpo, ya que en ese caso no está tan claro qué transacción se va a abortar. Para evitar problemas, las herramientas externas deberían acceder a la base de datos en modo de muy baja prioridad, indicando en su gestión de la BD que el sistema debe abortarlas en cuanto se detecte cualquier tipo de conflicto. Ese es el flag "DB_TXN_NOWAIT".

• 12/May/00 Versión 40

  • Implemento gestión dinámica de clones, a partir de nicks registrados.

  • En memoria se trabaja con dos tablas: una que asocia "IPs" a "nicks cabecera", y otra que asocia "número de clones" a "IPs". Esas tablas sólo existen en memoria, y no son persistentes entre ejecuciones de Olimpo.

  • La base de datos de I-lines se utiliza también para reflejar la asociación "nick cabecera -> número de clones". La sintaxis es la misma de siempre, salvo que en vez de una IP o de un nombre de máquina, la clave es un nick normalizado.

  • Cada vez que entra un usuario, se comprueba si está en "IP -> clones". Si es así, se devuelve ese valor de clones, sin buscar Iline estática.

  • Cuando el usuario ya está dentro, se comprueba si es un "nick cabecera". Si es así, vemos si ya ha expirado su permiso de iline. Si ha vencido la expiración, se elimina el registro, se propaga una baja de iline y se eliminan las posibles entradas en "nick cabecera -> IP" e "IP -> clones". Si había entrada "nick cabecera -> IP", se eliminan todos los nicks conectados a través de esa IP.

  • Cada vez que entra un nick, se comprueba si está en la tabla "nick cabecera -> IP". Si es así, pueden ocurrir dos cosas:

    1. Si la IP coincide, no se hace nada.

    2. Si la IP no coincide, eliminamos la entrada de "nick cabecera -> IP" y "IP -> clones", eliminamos también el registro de iline temporal de la base de datos y propagamos una baja de iline por la red. Adicionalmente matamos todos los usuarios conectados desde la antigua IP.

       A continuación se pasa al punto siguiente.

  • Si entra un nick cabecera pero no tenemos constancia de él en la tabla "nick cabecera -> IP", creamos las entradas "nick cabecera -> IP", "IP -> clones", y propagamos un alta de Iline por la red. También añadimos un nuevo registro de iline en la base de datos, poniéndole una expiración ya vencida. Esto es útil por si reiniciamos a Olimpo, que caduquen las Ilines dinámicas en cuanto se conecta algún usuario a través suya.

  • Imprime las estadísticas HASH de las tablas internas "nick -> IP" e "IP -> clones" al hacer un "stats".

  • Va haciendo "checkpoint" de la base de datos cada 50Kbytes, en vez de un simple "sync". Ello reduce el tiempo de "commit" de horas a unos pocos minutos.

  ---

Ha sido un largo paréntesis...

• 27/Feb/01 Versión 41

  • Actualizacion del sistema para que soporte "numerics" extendidos:

    • Módulo de gestión de módulos.

      La intercomunicación módulo<->olimpo debe soportar el mayor rango de numerics permitido. Asimismo, la intercomunicación con el usuario también requiere el poder operar con numerics extendidos.

    • Módulo de gestión de privmsg.

      La intercomunicación con el usuario requiere el poder operar con numerics extendidos.

    • Módulo de gestión de comandos server<->server.

      Hay que reconocer la posibilidad de que los servidores se identifiquen con un numeric de dos caracteres, y no solo de uno.

    • Módulo de gestión del sistema de bases de datos distribuídas.

      Idem caso anterior.

    • Módulo principal Olimpo.

      Tenemos que contemplar que nuestro uplink directo utilice numerics extendidos.

    • Módulo de rutinas, datos comunes y estadísticas.

      Idem caso anterior.

    • Módulo de gestión de tablas internas y bases de datos.

      Esta parte es bastante truculenta, ya que hay que modificar todo el sistema de gestión de splits. Adicionalmente, hay que cambiar también el sistema de control de acceso y el sistema de gestión de estadísticas por nodo.

  • Eliminada una referencia a la GDBM, en el código. Hace años que no se utiliza. Actualmente utilizamos la Berkeley DB.

  • Solucionado un bug en la descarga masiva de módulos. Empleaba un puntero que residía en memoria que ya habíamos liberado con "free()".

  • Hago que Olimpo se desvincule del terminal desde el que se lanza, para que no se vea afectado por cosas como el cerrar su sesión "screen" o el sistema de control de trabajos.

  • Se amplía el tamaño de las tablas hash internas, para mejorar el rendimiento:
    • Servidores: de 3 a 67.
    • Nicks: de 157 a 32771.
    • numerics: de 157 a 32771.
    • IPs: de 157 a 32771.

    Los clones dinámicos siguen usando hashes de tamaño 31, ya que no se están utilizando.

• 19/Mar/01 Versión 42

  • Muevo todo el código de acceso a la base de datos a un módulos separado, para independizar todo lo posible Olimpo de la base de datos concreta que se esté utilizando.

  • Reprogramo las utilidades de apoyo a Olimpo, para que utilicen el nuevo módulo de acceso a base de datos, y así independizarse también de la base de datos concreta que se esté utilizando.

  • Elimino la utilidad histórica "ilines_alta", ya que estaba anticuada. El alta de nuevas líneas I debe realizarse a través de Olimpo.

  • El comando "reload", ahora que las bases de datos ya no se cargan en memoria, no tiene sentido como tal. Cambiamos su funcionamiento para que inyecte también nuevos datos en las bases de datos distribuídas. Ajustamos la ayuda.

  • En caso de conflicto de bloqueos entre herramientas, o entre herramientas y SuX, las herramientas siempre tienen la mínima prioridad. Para ello se programan de forma que si una herramienta necesita un lock que tiene otro sistema, aborta con un error, para que se pueda repetir manualmente las veces que sea preciso.

• 20/Mar/01 Versión 43

  • Hago una actualización "interim" de Berkeley DB 3.0.x a 3.1.x.

  • Actualización final de Berkeley DB 3.1.x a 3.2.x.

  • Las dos siguientes mejoras reducen el tiempo de procesado de "net join", con 30.000 usuarios, de un minuto y 50 segundos, a 44 segundos:

    • Hacemos los checkpoint cada 500 Kbytes, no cada 50Kbytes, para reducir la carga de memoria y de tráfico de disco.

    • Con el fin de mejorar el rendimiento en los "net join", penalizados con la versión nueva de SuX, tenemos una llamada para iniciar transacciones sin durabilidad garantizada, aunque mantengan las propiedades ACI (atomicidad, consistencia e independencia).

      Utilizamos esta funcionalidad para la actualización de los tiempos de acceso de las I-lines, que es algo en lo que la "durabilidad" no es un requisito.

  • Tras más de un año de uso de la librería Berkeley DB, la nueva versión "obedece" una directiva para pasar el tamaño de los ficheros de log para las transacciones de 10 megabytes a 2 megabytes.

• 21/Mar/01 Versión 44

  • En previsión de la carga futura, amplío el tamaño de la caché de la BerkeleyDB de los 256 Kbytes por defecto, a 4 Megabytes, en bloques de 512Kbytes.

    Este cambio también mejora el rendimiento en el "Net Join", ya que ahora toda la base de datos de Ilines cabe en la caché.

    Conjuntamente con la relajación de la propiedad de "durabilidad" de ciertas transacciones (ver versión 43), este cambio reduce considerablemente también el tráfico de escritura en disco, ya que ahora no es necesario hacer sitio en la caché enviando bloques "dirty" de la misma a la base de datos porque la caché no era lo bastante grande como para contener el "working set".

    Otra ventaja del cambio es poder hacer backups "en caliente".

  • Parece que el borrado de registros se refleja inmediatamente en la base de datos, haciendo un "write through" de la caché. Es más, da la impresión de que los borrados fuerzan un "checkpoint" del log.

    Tras investigar el tema con detalle, compruebo que el "flush" se produce cuando cerramos una base de datos sin hacerlo con una transacción. Estoy viendo el problema porque la herramienta "z4" que he hecho para expirar los clones caducados invoca, a su vez, a la herramienta "ilines_lista", que abre la base de datos de clones y luego la cierra sin transacciones.

  • Actualizo la ayuda de "ilineadd".

• 02/Abr/01 Versión 45

  • Integración del intérprete 2.0 de Python, para poder escribir módulos en este magnífico lenguaje.

    • El path de búsqueda de librerías no incluye el directorio actual, así que añadimos LIB_PATH al principio del mismo.

    • Defino los objetos de callback de Python hacia C dentro de la jerarquía Olimpo. Me encuentro con rutinas no documentadas en los manuales Python. Tomo nota de ello, para informar a sus autores.

    • Ya consigo llamar tanto al Python desde C como a la inversa.

    • Implemento las funciones del API básico de módulos: inicio(), especifica_fin(), comentario_modulo() y hace_log().

    • Implemento las funciones del API PRIVMSG: nuevo_nick(), envia_nick(), lee_flags_nick(), lee_nick() y lee_nick_normalizado. Cuelgan de Olimpo.privmsg.

    • Tengo problemas para definir funciones en la subjerarquía, ya que el import no parece tener efecto.

    • Por lo que parece, tengo que añadir a Olimpo, a mano, cada elemento de la subjerarquía.

  • Al enlazar las herramientas ilines_lista y agenda_lista, no lo hago contra la librería dinamica, sino contra el objeto que implementa el wrapper que envuelve la base de datos. Esto, no obstante, obliga a poner una función "dummy" "descarga_modulos()" para que el enlazado funcione correctamente. Esta función no es problema, porque esas herramientas no usan módulos.

  • El esquema del punto anterior no me convence. Prefiero enlazar directamente con el módulo "modulos.o". Lamentablemente dicho módulo tiene un buen número de dependencias con otros.

  • Dejo el enlazado como al principio. Para evitar los errores, enlazo también la librería python con las susodichas herramientas. Lamentablemente se trata de una librería estática, y su inclusión aumenta el tamaño de las mismas de forma considerable.

  • Para evitar que las herramientas crezcan tanto al enlazar, y mientras no dispongo de una librería python estática, opto por incluir la propia librería Python dentro del la librería dinámica "libolimpo.so". De esta forma lo que crece es la librería dinámica, no las herramientas.

  • ¡¡¡Pruebo lo que tengo hecho y funciona!!!. Me voy a dormir...

• 03/Abr/01 Versión 46

  • Algunas de las funciones de la interfaz Olimpo.privmsg entre Python y C estaban mal implementadas. Las reescribo.

  • Primer módulo de ejemplo en Python: saluda.py.

  • Cuando un módulo Python tiene una excepción no gestionada, guardamos el "traceback" en "olimpo_py_err.log".

    Este fichero se abre y se cierra cada vez que se almacena algo dentro, para hacer frente a truncamientos del fichero, cambios de nombre, etc. Asimismo, abrimos siempre con una máscara de acceso 0644.

  • La inicialización del módulo Python está escrita... ¡¡en Python!! :-). Cuando Olimpo arranca, ejecuta el fichero olimpo_init.py. Con esto, la flexibilidad es total.

  • Implemento las funciones del API NOTIFY: notifica_nick_registrado(). Cuelga de Olimpo.notify.

  • Solucionado un problema con el contador de referencias del objeto Py_None.

  • Resueltos varios Memory Leaks en el módulo Python.

  • Implemento las funciones del API NOTIFY_DB: notifica_db_nickdrop(). Cuelga de Olimpo.notify_db.

  • Amplío el API NOTIFY con notifica_server_join() y notifica_server_split(), para que los módulos puedan detectar entradas y salidas de nodos.

    Si el split se produce entre Olimpo y su HUB directo, se invoca una sola vez con notifica_server_split(NULL).

• 27/Abr/01 Versión 47

  • Meto los módulos "core" Python en "modulos_python_core". Los módulos en Python normales van en "modulos_python".

  • "make python" instala los módulos Python en el directorio estable.

  • Amplío "olimpo_init.py" para que pueda cargar wrappers de los módulos internos de Olimpo.

  • Hago una implementación superficial de la interfaz "BerkeleyDB", accesible a través de "Olimpo._BerkeleyDB". Hago un wrapper en Python, accesible en "Olimpo.BerkeleyDB", que es lo que utilizarán los módulos Python.

  • Definición de una nueva API para módulos: "mod_servmsg". Se utilizará para que un módulo pueda enviar comandos a un servidor, y leer sus respuestas.

  • Se amplía el API "notify" para que en las notificaciones de entrada de nuevos nodos se indique también su "numeric".

  • Solucionado un problema cuando un módulo registra más de un nick.

  • Ampliamos el API "notify" para añadir una orden de notificación de los nodos actuales de la red.

  • Escribo el módulo "net_v".

  • Amplío el API "notify" para que se informe de la causa de un "split".

• 25/May/01 Versión 48

  • Solucionado un "deadlock" ocasionado por un fallo de programación en el módulo Python que hace de interfaz entre la interfaz "BerkeleyDB" que ven los módulos y la implementación mínima interna.

• 18/Jul/01 Versión 49

  • Introduzco más "assert()" en el código de gestión de las bases de datos, para verificar situaciones imposibles.

  • Olimpo purga automáticamente los archivos de log de las transacciones de las bases de datos, para evitar tener que borrarlos a mano y que se llene el disco. El purgado se hace tomando las precauciones oportunas para poder recuperar las bases de datos en caso de surgir algún problema serio.

  • Elimino código en el módulo que hace de interfaz entre C y Python, ya que no estoy definiendo "docstrings".

  • Solucionado un problema con el sondeo de la base de datos distribuída, en los nodos.

  • Cuando se hace checkpointing de la base de datos, antes se toleraba un "DB_INCOMPLETE". Ahora no podemos tolerarlo, ya que nos interesa eliminar los ficheros de logs de transacciones cuanto antes, así que si al hacer checkpoint se nos indica que no se ha completado, lo reintentamos las veces que sea preciso.

    Esto puede suponer una pequeña pausa, típicamente inferior a uno o dos segundos, cada vez que se hace el checkpoint, operación que es infrecuente (en estos momentos, cada hora o cuando se acumulan 500 Kbytes de log, lo que se cumpla primero).

    La razón de "DB_INCOMPLETE" es no bloquear demasiadas páginas de la base de datos, y para no saturar el disco. Si se supera un umbral determinado de bloqueos, se completa un checkpoint parcial, se liberan los bloqueos y se devuelve el control. Con ello se pretende un mejor comportamiento en entornos con muchos procesos o threads utilizando la base de datos, y para no saturar el subsistema de disco. En nuestro caso, no obstante, lo que hacemos es reintentar la operación hasta completarla totalmente. Dado que cada llamada hace progresos de forma incremental, sabemos que el bucle se completa en algún momento. Todo lo más, un par de segundos.

• 23/Jul/01 Versión 50

  • Solucionado un problema con los "bindings" Python para la BerkeleyDB.

  • El "wrapper" Python para la BerkeleyDB tenía un problema durante la recogida de basura de transacciones no completadas. Solucionado.

  • Definición de una nueva API para módulos: "tools". Se trata de funciones comunes, sin cabida en otras API's.

  • Definición de una nueva API para módulos: "bdd". Se utilizará para interactuar con la base de datos distribuída.

  • Reescribo el sistema de gestión actual de I-lines (clones) y registro distribuído de nicks, para que utilice el nuevo API "bdd", al igual que los módulos cargables.

  • Reescribo el sistema de normalización de nicks, para utilizar el API "tools", al igual que los módulos cargables.

  • En los "bindings" Python para BerkeleyDB, cambiamos el método "del" de "db" a "delete", ya que se trata de una palabra reservada.

  • Con el nuevo API "bdd", cuando un módulo o un recurso interno elimina un nick, se notifica a todos los módulos, y se almacena de forma persistente.

  • Olimpo gestiona la invocación recursiva de funciones entre e intra módulos.

  • Solucionado un problema de implementación de la rutina de notificación de "NICKDROPS", cuando la rutina de gestión para un módulo determinado está escrita en Python.

  • Elimino los comandos "NICKREGISTER", "NICKFORBID" y "NICKDROP", ya que ahora se procesan dentro de un módulo y no es lógico tenerlos duplicados.

• 07/Ago/01 Versión 51

  • Se amplía la funcionalidad del módulo "privmsg" con una función para obtener el "numeric" a partir de un "nick", si está conectado.

  • Dado que el módulo "nick2.py" ya está bastante probado y en producción, lo cargamos automáticamente cuando se lanza Olimpo.

  • Dado el sistema de purga de logs de transacciones que he implementado, ya no hace falta hacer un "checkpoint" cada 500Kbytes de logs, así que elimino dicha funcionalidad. El "checkpoint" ya se hace cuando se verifica si podemos purgar o no ficheros de logs.

  • Para evitar un "deadlock" que ocurre a veces cuando usamos alguna herramienta que recorre la base de datos mientras Olimpo está funcionando, y que parece que introduje durante la programación de la purga de ficheros de logs, hago que solo se realice un "checkpoint" cuando no existen transacciones en curso.

  • Dado que ahora los "checkpoint" sólo se realizan cuando no hay transacciones en curso, cambio el orden de las funciones para que se intenten purgar los archivos de logs una vez que se haya cerrado una transacción, no antes.

  • Reduzco el tiempo entre intentos de purga de una hora a un minuto, ya que ahora los "checkpoint" se realizan aquí.

• 14/Ago/01 Versión 52

  • Cuando se envía una compactación de la base de datos, ya no se avisa erróneamente a los módulos que lo solicitaron, que se ha borrado un registro.

  • Solucionado un problema grave cuando se aborta una transacción iniciada desde un módulo Python. El problema no se detectó antes porque durante el funcionamiento normal nunca abortamos transacciones.

    Se detectó tras ocurrir un error interno durante el desarrollo de un módulo Python. El error abortó la ejecución del módulo, pero dejó transacciones abiertas, que fueron cerradas con posterioridad por el sistema de recogida de basuras. Tengo puesto que si una transacción se convierte en basura son haber sido comprometida, se aborte. ¡¡Qué gozada!!.

  • Con el crecimiento de las bases de datos, sobre todo la BD de nicks, me encuentro con un problema de superación del número de "locks" activos que, por defecto, está establecido en 1.000. Durante el uso normal del sistema no hay problema, pero cuando utilizamos las funciones de cursor para, por ejemplo, volcar las bases de datos a disco, superamos el número de bloqueos simultaneos.

    Por ello, amplío el número de bloqueos y el número de objetos bloqueados simultaneos de 1.000 a 10.000.

  • Solucionado un problema con el borrado de bases de datos distribuídas.

  • Solucionados unos problemas con los contadores de referencia en la interfaz C<->Python, concretamente en la gestión de los "callback".

  • Solucionamos un problema de cerrar cursores ya cerrados, en los módulos Python.

• 03/Oct/01 Versión 53

  • Uso el "dlmalloc", ya que la gestión de memoria nativa de Solaris es bastante floja. En Linux no haría falta, ya que el gestor de memoria de la LIBC es decentillo, pero usando un gestor explícito me aseguro de tener una buena calidad en todos los sistemas.

  • Trabajo con una caché interna de estructuras para pedir bloques de 1024 microestructuras de una vez. Se supone que esto es más eficiente en términos de memoria y de espacio.

  • El cambio anterior no mejora el rendimiento actual. Vuelvo a la versión antigua.

  • Compilo la librería "dlmalloc" con USE_MALLOC_LOCK, para darle capacidad multithread. Ahora mismo es algo que no estamos utilizando, pero puede ser útil en el futuro.

  • Colapso los datos almacenados en las tablas hash con las estructuras HASH en sí. De esta forma gestionamos la mitad de bloques de memoria. Además, al tener los datos y su estructura hash juntos, mejora el comportamiento de paginación y de caché. El único problema es una posible mayor fragmentación externa de memoria.

  • Añado el comando "MEMINFO", disponible solo para mí, que me muestra numerosa información sobre la gestión de memoria de Olimpo.

  • Ajusto código para que compile también sin problemas sobre Linux.

• 28/Nov/01 Versión 54

  • Cuando conectamos Olimpo a una red, puede ser que nos lleguen usuarios cuyos clones ya han caducado, pero ANTES de que Olimpo haya tenido ocasión de sincronizar sus números de serie de las BDD con su HUB. En casos así, y tratándose de clones, la solución más sencilla consiste en ignorar la entrada del usuario y no dar de baja los clones... de momento. Ya se darán de baja en su segunda conexión, o vía mi script "z4".

  • A tenor del cambio anterior, modifico los comandos "ILINEADD" y "ILINEDEL" para que sean ignorados si todavía no hemos podido sincronizar los números de serie. La "race condition" era minúscula (de hecho no se ha detectado ni una sola vez en tres años de servicio), pero existía.

  • Solucionados "memory leaks" en la lectura de objetos de la base de datos. Cada vez que se leía un objeto de la base de datos, se quedaba en memoria...

• 13/Dic/01 Versión 55

  • Cuando compilamos una versión de desarrollo de Olimpo, el proceso no debe desvincularse del terminal, para poder enviarle señales desde el mismo.

  • Soluciono un oscuro y complicado bug en Olimpo: Cuando un usuario tenía un "host" de solo uno o dos caracteres (en la práctica, esto solo ocurre son "services" "inyectados" por un nodo en la red), las llamadas API "PRIVMSG" "lee_nick()" y "lee_nick_normalizado()" devolvían nicks inexistentes.

  • Solucionado un problema en "JUPE" a nodos con numerics largos.

  • Es posible hacer log sin necesitar un nick remitente, a través de la nueva adición al API: "hace_log2()".

  • Añadidas al API "TOOLS" las funciones "get_entropia()" y "add_entropia()".

  • Añadida al API "NOTIFY" la función "notifica_servers()", para obtener la lista de servidores actuales.

  • Añadida al API "NOTIFY" la función "notifica_nicks_registrados()", para obtener la lista de usuarios "+r" actuales.

  • Añadida al API "NOTIFY" la función "notifica_timer()", para temporizaciones e invocaciones diferidas.

  • Solucionados diversos "Memory Leaks" cuando se cambian rutinas de notificación Python.

  • Solucionado un problema con la descarga de módulos. Se construía mal la lista doblemente enlazada de módulos cargados, y cuando se descargaba uno, según las circunstancias, podría ser que desapareciesen otros. El fallo era muy tonto, y como sólo se mostraba cuando se descargaba un módulo dinámico "del medio", y eso es una operación muy poco frecuente, no se había detectado.

• 27/Dic/01 Versión 56

  • Migro Olimpo de BerkeleyDB 3.2.* a 3.3.*.

  • Migro Olimpo de BerkeleyDB 3.3.* a 4.0.*.

  • Cuando abrimos un cursor a través del API "BERKELEYDB", podemos especificar un registro en el que empezar el recorrido.

  • Solucionado un problema en la invocación de llamadas temporizadas en Python.