			*Últimos Cambios*

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

Módulo IP Virtual

Última Actualización: 02 de Agosto de 2002 - Viernes

Este módulo permite introducirle una IP virtual y nos devuelve la IP real.

Enlaces

Esta web tiene un contenido eminentemente técnico y "no apto" :-) para usuarios "de andar por casa". Si lo que quieres saber es cómo utilizar "IPVIRTUAL", para qué sirve y qué opciones y posibilidades tiene, te recomiendo las siguientes páginas web, más asequibles:

TO DO

Debería tomar por defecto la clave actual, sin necesidad de que se la tengamos que introducir cada vez.

Historia

Los números de versión que se indican se refieren a "commit" en el CVS interno. El número de versión cargado en Olimpo en un momento dado es visible usando el comando "dllist".

El código que sigue ha quedado completamente suplantado:

27/Feb/01 Versión 1.4

Implementa el comando "DESCIFRA".
Utiliza la verificación embutida dentro de la IP virtual para comprobar que la IP virtual y la clave que indicamos, "casan".

29/Ene/02 Versión 1.11

Aprovechando la ampliación del API Olimpo, amplío el módulo para que cambie las claves de cifrado de IPs de forma diaria. En concreto, todos los días entre las 04:00 y las 05:00 GMT.

01/Jul/02 Versión 1.24
- Reescribo todo el módulo anterior en Python, para poder hacer frente con facilidad a las nuevas necesidades inminentes de este módulo.
  En este momento, el módulo Python actual es equivalente al módulo C antiguo, aunque infinitamente más simple y flexible.
03/Jul/02 Versión 1.63
- Solucionamos un par de bugs en la regeneración periódica de la clave de cifrado de IPs.
- Cuando este módulo observa el borrado de un nick, elimita también su (posible) entrada en la tabla "w".
- Cuando este módulo arranca, se informa de los nicks que se hayan dado de baja y de los que no haya recibido notificaciones de baja aún.
- Añado un comando para generar "TOKENS" a cuenta de un miembro de la asociación.
- Llevamos estadísticas de los "TOKENS" generados, por miembro de la asociación.
- Añadimos un comando, disponible para IRCops que sean Opers también, para ver las estadísticas de generación y consumo de "TOKENS", mes a mes y miembro a miembro.
- Solucionado un problema de bucle infinito en la generación de "TOKENS".
04/Jul/02 Versión 1.91
- Añado el comando "ACTIVACION", que activa una IP virtual si se le proporciona un "TOKEN" correcto.
  - Consume el "TOKEN".
  - Actualiza correctamente las estadísticas del mes en curso.
  - Guarda el registro del usuario en cuestión en la base de datos, para saber qué miembro le dió el "TOKEN" y cuándo debe expirarlo.
- Cuando se da de baja un nick, damos de baja también su entrada en la base de datos de IPs virtuales, si existe.
- Creo un comando "PROMOCION" que da un "TOKEN" de forma gratuita cada minuto. Para ello el nick que lo solicita debe ser "+r", y no haber pedido otros "TOKENS".
- Para poder activar una IP virtual, el nick debe ser "+r".
- La IP virtual que pide un usuario no puede medir más de 35 caracteres.
08/Jul/02 Versión 1.107
- Cuando se cambia la clave cifrado de IPs virtuales, envía el fichero de histórico de claves por email a mí mismo y a Sisco Sapena (Presidente de IRC-Hispano).
  Si ocurre algún problema catastófico, no pasa nada: la próxima vez que se regenere la clave, se enviará el histórico completo.
- Cerramos correctamente una transaccion stale que se crea al cargar el módulo.
- Implemento los comandos "LISTFILTRO", "ADDFILTRO" y "DELFILTRO", a disposición mía y de Sisco Sapena.
- Conservo: filtro en sí, nick que lo activa, fecha de activación.
- Internamente conservo también el filtro precompilado.
- Se implementa la verificación de los filtros cuando un usuario desea activar una IP virtual. Contra mi criterio, pero es un requisito del diseño original... :-(
10/Jul/02 Versión 1.131
- En vez de generar "TOKENS" de 64 bits y 12 caracteres de un amplio repertorio, restrinjo la generación de "TOKENS" a números de 15 dígitos. Ello me proporciona unos 49.8 bits de entropía. En realidad, es algo menos, ya que hay un ligero bias en los dígitos, pero sigue teniendo una calidad bastante aceptable.
  Ello permite, por ejemplo, que un "TOKEN" se pueda comunicar fácilmente por teléfono, y que no sufra de ambigüedades según el juego de caracteres que se use.
- Defino una clase para poder definir varios eventos diferidos simultaneamente, con diferentes instantes de activación.
- Cada minuto, escanea 100 usuarios con la IP Virtual Personalizada activada, para ver si es necesario dar de baja a alguno. Este escaneo solo se realiza si la base de datos distribuída correspondiente tiene el "grifo abierto". Si no es así, se espera al minuto siguiente.
- Si cuando cargamos este módulo, detecta que se han desregistrado nicks, pero el flujo de la tabla "w" está cerrado, va encolando los borrados. Los borrados se harán efectivos cuando se reciba un nuevo "NICKDROP" proveniente del framework Olimpo, y el flujo de la Base de Datos Distribuída "w" esté abierto.
- Solucionado un problema crítico: se cerraba una transacción ANTES de cerrar el cursor asociado a ella.
11/Jul/02 Versión 1.151
- Dado que verificar la expiración de IPs virtuales personalizadas es una tarea relativamente lenta, en vez de consumir CPU minuto a minuto, realizo el siguiente cambio algorítmico:
  - En todo momento, el sistema de control de expiraciones está en uno de dos modos de operación: revisión de la base de datos o expiración de la caché.
  - Cuando el módulo se arranca, inicia en modo "revisión de la base de datos". En ese modo se revisan 100 IPs virtuales personalizadas por minuto. Las que ya han expirado, se eliminan. Las demás se van metiendo en una caché, con una capacidad de 1000 elementos. Cuando se llena la caché nos quedamos con los 1000 elementos cuya expiración está más cercana.
    Este modo se mantiene hasta que se revisa la base de datos completa. En ese momento se pasa al modo de expiración de caché.
  - En el modo de expiración de caché, vamos eliminando las IPs virtuales que tenemos en caché, ordenadas por fecha de expiración, a medida que van caducando. Mantenemos este modo hasta que la caché se queda vacía.
  Este cambio supone un gran ahorro de CPU a costa de un pequeño incremento en el consumo de memoria, consumo regulable en función del tamaño de la caché que usemos, completamente bajo nuestro control.
  Algunos posibles problemas son:
  - Si algún nick se da de baja, no lo eliminamos de la caché. Ello no es problema, porque cuando se empieza a caducar la caché, se comprueba el registro real. Si no existe o no debe expirar aún, no se hace nada.
  - Si un nick en la caché de expiración renueva su IP virtual, no lo quitamos de la caché. No es problema, ver el caso anterior.
  - Dado que el repaso de la base de datos se realiza en pequeños "bocados" de 100 elementos, es posible que la base de datos se modifique antes de haber completado un ciclo de revisión. Ello puede provocar que un nick sea revisado más de una vez o que nos saltemos algún nick en la revisión. El primer caso no es problema, y se resuelve de la misma manera que los puntos anteriores. El segundo caso puede provocar que una IP virtual expire mucho después de que deba, al ser capturada en una pasada posterior.
    Ese riesgo se puede minimizar jugando con el tamaño de la caché. Cuando menor sea la relación tamaño caché dividido por el número de IPs virtuales totales (suponiendo que se dan de alta de forma uniforme en su período, no todas a la vez), menor será la probabilidad de que nos saltemos alguna expiración y, de saltárnosla, menor será el tiempo hasta que la localicemos.
    En general me parece que una caché con capacidad de 4 horas es razonable. El número de elementos que debe tener la caché para abarcar unas 4 horas se sabrá conforme se gane experiencia con el sistema.
    Se podría modificar el sistema para que, en vez de limitar la caché por número de elementos, se limite por TimeStamp del elemento primero y último. Esto tengo que pensarlo con calma, pero es problemático si el TimeStamp del primer elemento está muy lejos... Claro que tengo un problema similar en el caso de la caché por límite de elementos.
    Sí, mejor limito el contenido de la caché a aquellas IPs virtuales que van a caducar en, digamos, 4 horas a partir de ahora.
- Si cuando terminamos un ciclo de verificación de base de datos, la caché está vacía, esperamos 2 horas a volver a repasarla. De esta forma también ahorramos CPU, aunque sea a costa de permitir que alguna IP virtual personalizada dure algo más de lo debido.
- Por simetría, cambio el punto anterior a 4 horas.
- En las estadísticas, añado un campo más de "expiraciones", para llevar la contabilidad de las expiraciones de "TOKENS".
- En las estadísticas, muestra los "TOKENS" expirados, también.
- Implemento la expiración de "TOKENS". De momento pongo la expiración en 6 meses. Recorro 100 "TOKENS" por minuto. Cuando termino de revisar la base de datos, programo la siguiente revisión 22 horas, 17 minutos y 12 segundos más tarde.
- Distribuyo las diferentes ejecuciones diferidas para que no coincidan simultaneamente, distribuyendo el consumo de CPU de forma más uniforme.
15/Jul/02 Versión 1.183
- En los filtros a aplicar a las IPs virtuales personalizadas que piden los usuarios, ignoro la distinción entre minúsculas y mayúsculas.
- Añado el comando "DESACTIVACION", que dá de baja la IP virtual personalizada de un usuario, si tiene alguna. Este comando requiere confirmación.
  Se informa al usuario de que esta acción es irreversible. Si quiere volver a recuperar su IP virtual, debe solicitar un nuevo "TOKEN", y pagar por ello.
18/Jul/02 Versión 1.210
- Añadimos comandos para dar de alta, de baja y listar usuarios "generadores". Un usuario "generador" es un usuario que puede generar "TOKENS". Tipicamente se tratará de usuarios que representan miembros de la red.
  Los datos que se requiere para crear un usuario "generador" nuevo son: nick, nodo a través del que conecta ese usuario, miembro de la red al que representa y, opcionalmente, una dirección de correo electrónico a la que enviar los "TOKENS" generados.
- Cuando se da de alta un usuario generador, se guarda también el nick de quien realiza la operación, la fecha y la hora.
- Es necesario que un nick "generador" se dé de alta cuando YA esté registrado como "+r". Si no es el caso, el resultado es indefinido.
- Cuando este módulo detecta que un nick "generador" ha expirado o ha sido eliminado del sistema, actualiza sus permisos internos, de forma que ese nick, si se vuelve a registrar, ya no sea considerado "generador".
- Para que un nick "generador" se acepte, debe:
  - Estar dado de alta como "generador" en este módulo.
  - Estar como "+r".
  - Entrar por su nodo raíz.
- Cuando se listan los nicks "generadores", se hace por orden alfabético.
- Solucionado un pequeño problema con las transacciones, en los "NICKDROPS".
22/Jul/02 Versión 1.216
- Cuando se consume un "TOKEN", se deja constancia en el log, como medida de resolución de conflictos a la hora de facturar a los miembros.
- Damos por finalizado el plazo de pruebas. Elimino el comando "PROMOCION". Cuando alguien lo usa, le informo de que la promoción ha concluido, y le mando a un web de IRC-Hispano.
- Expiro los "TOKENS" promocionales. Menuda escabechina :-)
05/Ago/02 Versión 1.237
- Implemento el comando "INFO", que muestra la IP virtual personalizada de un usuario, si la tiene, y su fecha de activación.
- Solucionado un problema menor en la expiración de IPs virtuales personalizadas.
- Los días 1, 8, 15, 22 y 29 de cada mes, envía por correo electrónico los datos de uso del mes en curso y del mes anterior, a las personas de contacto de facturación. Se indica el número de "TOKENS" generados, consumidos y expirados de cada miembro.
- Solucionamos un problema con la expiración de IPs Virtuales Personalizadas, cuando el bot está en modo expiración de caché, ya que se eliminaba la entrada en la base de datos, pero no se distribuía el borrado por la red.
05/Ago/02 Versión 1.237
- Cuando se rastrean las IPs Virtuales Personalizadas a la caza de expiraciones, se guarda en los logs cuantas hemos metido en la caché de expiración inminente.
- Cuando se expiran IPs Virtuales Personalizadas obtenidas a través de la caché de expiración inminente, indicamos cuántas entradas nos quedan en la caché.