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

Última Actualización: 10 de Septiembre de 2003 - Miércoles

La fase 3 del proyecto ESNET consiste en:

• Evaluar el correcto funcionamiento de los esquemas de distribución implementados.
• Evaluar el impacto y las nuevas necesidades de un desarrollo conjunto entre IRC-Hispano y ESNET.
• Desarrollar nuevos esquemas de distribución ajustados a las nuevas necesidades de la red.
• Desplegar dichas herramientas en la red.

Perspectiva histórica Distribución de la Base de Datos Esquema Propuesto Problemas con el Esquema Propuesto Base de Datos Bases de Datos Distribuídas Historia

Desde que se desarrollaron los primero bocetos de un sistema de base de datos distribuída hasta hoy han ocurrido muchas cosas, la mayoría de ellas buenas:

El funcionamiento básico del sistema es comparable al definido en la fase 2. Los cambios están ocasionados, sobre todo, por la necesidad de dar soporte a Bases de Datos Distribuídas gestionadas por diferentes nodos de control. Se recomienda leer previamente la descripción de la fase 2, por ser más sencilla y por sentar las bases del esquema actual.

Funcionamiento

• Red en Régimen Estacionario

  Se realiza igual que en la fase 2, pero con la salvedad de que el número de serie es propio para cada BDD.

  La propagación de nuevos registros sólo se produce a través de aquellos enlaces que tienen el "Grifo Abierto". Se mantiene un "Grifo" por cada BDD.

• Red en "Net Join"

  Aquí las cosas se complican, porque ahora hay que negociar versiones para varias BDD, así como versiones de implementación, siendo todo ello compatible con la implementación primitiva.

  • Se produce el "NetJoin". El nodo enviará:

    <Nodo Origen> DB <Nodo Destino> 0 J <Número de serie Local BDD nicks> 2

  • Si el nodo recibe un "J" de una versión antigua, responde tal y como se definió en fase 2.

  • Si el nodo recibe un "J" version 2, envía al otro extremo tantos "J" como bases de datos se estén gestionando, con el formato

    <Nodo Origen> DB <Nodo Destino> 0 J <Número de serie Local BDD> <BDD>

  • Si el nodo recibe un "J" correspondiente a una BDD, la gestiona tal y como se definió en fase 2, excepto que las operaciones se restrinjen a dicha BDD. El único cambio aparente es el nuevo formato de respuesta para "B":

    <Nodo Origen> DB <Nodo Destino> 0 B <Número de serie BDD Local> <BDD>

  • Si el nodo recibe un "B", responde tal y como se definió en fase 2. Si no se indica la BDD concreta que se está referenciando, suponemos que se trata de la BDD de nicks.

• Reinicio de un nodo

  Es la misma situación que en fase 2.

• Resincronización de las Bases de Datos Distribuídas

  Al contrario que en la fase 2, las Bases de Datos Distribuídas no necesitan estar sincronizadas antes de forzar una compactación de las mismas. Ello es así porque las órdenes de compactación viajan utilizando los mismos mecanismos de propagación que se emplean para propagar los propios registros.

  La orden de compactación de una BDD es como sigue:

  <Nodo Origen> DB <Nodo Destino> <Núemro de serie local> <BDD> * [Texto Opcional]

  Cuando un nodo recibe un registro como el anterior, revisa la copia local de la BDD en disco y:

  • Los registros de alta son contrastados con el contenido de la BDD en memoria. Si no coinciden significa que hay un registro posterior que le asigna su valor definitivo, así que el registro en curso se ignorará. Si coinciden, el registro se conserva.

  • Los registros de borrado se eliminan.

  • Los registros de compactación se eliminan, salvo el que acaba de llegar.

  Utilizando estos mecanismos, los nodos pueden compactar su base de datos de forma asíncrona. No se necesita que estén todos online y con la BDD actualizada para solicitar una compactación.

• Consulta de versiones e integridad de las Bases de Datos Distribuídas Locales

  El nodo de control de cada BDD puede solicitar el borrado de la copia local de la BDD de un nodo en particular, de una serie de nodos de nombre parecido e, incluso, de toda la red. Para ello el nodo de control envía un comando

  <Nodo Origen> DB <Nodo Destino> 0 Q <nonce> <BDD>

  A lo cual cada nodo que se dé por aludido debe responder con

  <Nodo Origen> DB <Nodo Destino> 0 R <Número de Serie Local>-<hash>-<nonce> <BDD>

  nonce es un valor opaco utilizado para identificar los comandos/respuestas.

  Nota de Implementación: Mientras no se implementa la verificación, el campo hash tiene el valor "HASH".

• Borrado de las Bases de Datos Distribuídas Locales

  El nodo de control de cada BDD puede solicitar el borrado de la copia local de la BDD de un nodo en particular, de una serie de nodos de nombre parecido e, incluso, de toda la red. Para ello el nodo de control envía un comando

  <Nodo Origen> DB <Nodo Destino> 0 D <nonce> <BDD>

  A lo cual cada nodo que se dé por aludido debe responder con

  <Nodo Origen> DB <Nodo Destino> 0 E <nonce> <BDD>

  nonce es un valor opaco utilizado para identificar los comandos/respuestas.

  Cuando un nodo recibe una orden de borrado, verifica que provenga de un HUB, y debe:

  • Enviar una copia de dicha orden de borrado por todos los enlaces con otros nodos, menos por el que le llegó.

  • Si al otro lado del enlace hay un nodo que cumple el patrón para Nodo Destino, el nodo debe "Cerrar su Grifo" para la BDD y el nodo remoto en cuestión.

  • Si el propio nodo cumple el patrón para Nodo Destino, debe borrar su copia local de la BDD en cuestión, enviando un "E" tal y como se ha especificado más arriba. Seguidamente debe enviar al nodo que le ha pasado la orden un "J" como si se hubiera producido un "NetJoin".

  Nota de Implementación: Actualmente, los servidores "Cierran el Grifo" en todos los enlaces por los que envían la orden de borrado. En contrapartida, todos los servidores envían un "J" cuando reciben una orden de borrado, aunque ellos no sean los destinatarios.

• Base de Datos Distribuída local corrupta

  Cuando un nodo arranca o se le solicita un rehash, verifica la integridad de sus copias locales de las Bases de Datos Distribuídas. En caso de que alguna de ellas parezca corrupta, el servidor la eliminará y solicitará a los nodos vecinos que le envíen una actualización.

El esquema propuesto hasta el momento presenta una serie de problemas, todos ellos derivados del borrado de una BDD local. Están ocasionados por el hecho de que se rompe la secuencia monótona creciente en la que se basa la distribución de las Bases de Datos Distribuídas.

En todos los casos los problemas son similares y aparecen cuando un nodo tiene más de una vía de actualización de sus Bases de Datos Distribuídas. Es decir, sólo afecta a HUBS, y sólo cuando estos estén conectados o otros *dos* HUBs como mínimo.

1. Solicitud de borrado de una BDD local

   Cuando un nodo recibe una solicitud de borrado de una de sus BDDs locales, así lo hace, y solicita una actualización al nodo a través de cuyo enlace le llegó la petición original.

   Este esquema no funciona cuando el nodo dispone de varias vías de actualización, y se está actualizando en este momento. Supongamos el siguiente caso, por ejemplo.

   C-H1-H2-H3
   

   El nodo H2 acaba de entrar en la red y tiene su base de datos desactualizada. Debido a ello, los nodos H1 y H3 empiezan a enviarle una actualización (se la mandan los dos nodos a la vez, de forma independiente).

   Si ahora el nodo de control C envía a H2 una orden de borrado, H2 la recibe, borra la BDD local que corresponda y solicita una actualización a H1, que habrá "Cerrado su Grifo" al pasar a H2 la orden de borrado.

   Mientras tanto, el nodo H3 sigue enviando actualizaciones a H2. Como H2 ha borrado su BDD, sólo tendrá los últimos registros, no los primeros.

   Cuando empiece a llegar la actualización de H1, H2 la ignorará, porque H3 ya le ha suministrado registros con número de serie mayor.

   Cuando termine la actualización, H2 tendrá una BDD parcial, en la que no aparecerán los primeros registros.

2. Detección de una BDD local corrupta

   Además de la situación anterior, existe otro caso con mayores repercusiones:

   Hasta BD24, cuando un nodo comprueba que una de sus BDD locales está corrupta, la borra y solicita actualizaciones a sus nodos vecinos.

   Lo primero que hacen dichos nodos es forzar un borrado de la BDD en el nodo con problemas, por si se diera el caso de que se le hubieran transferido registros intermedios. Seguidamente se le manda la BDD.

   Si los enlaces tienen LAG, es perfectamente posible que cuando un enlace esté enviando la BDD, llegue una orden de borrado por otro enlace, junto la consiguiente actualización. La BDD puede quedar, pues inconsistente.

Estos problemas son graves porque afectan a HUBs, pero pueden ser detectados con un chequeo periódico de las copias locales de las BDD, tarea que debe ser ejercida por los nodos de control responsables de cada una de las BDD. Mientras no se diseña, estudia y despliega una solución elegante, he optado por una alternativa sucia y chapucera: cuando un nodo borra una de sus BDD, corta inmediatamente las conexiones con otros HUBs. Si el nodo no es HUB, no hace falta tomar ninguna medida especial.

Esta corrección temporal está desplegada como DB25.

A continuación se detalla el formato de mensajes intercambiados entre servidores utilizando los parches hasta DB3:

<Nodo Origen> DB * 0 J <Número de Serie Local> (formato antiguo)

<Nodo Origen> DB * 0 J <Número de Serie Local> <versión implementación BDD> (formato DB16)

<Nodo Origen> DB * 0 J <Número de Serie Local> <BDD> (formato DB16)

Mensaje intercambiado entre nodos adyacentes en un "NetJoin" o entre ráfagas "DB Burst" como respuesta a un registro "B". En DB16 se realizó un cambio compatible hacia atrás para negociar la versión de la implementación de la Base de Datos Distribuída en el "NetJoin". La versión que se pasa es la "2". Los nodos antiguos ignoran ese valor. Los nodos modernos, con este esquema, permiten trabajar con varias BDD gestionadas por diferentes nodos de control. "BDD" es la BDD concreta que se está negociando.

<Nodo Origen> DB * 0 B <Número de Serie Local> (formato antiguo)

<Nodo Origen> DB * 0 B <Número de Serie Local> <BDD> (formato DB16)

Mensaje intercambiado entre nodos adyacentes al final de una ráfaga "DB Burst", para indicar que todavía quedan más registros por transferir. En el caso de que el otro extremo no lo consideremos HUB, se ignora debido al parche DB8. De otra forma se crearía un bucle infinito, ya que no estamos actualizando nuestra base de datos.

Con DB16 se especifica la BDD en cuestión.

Los siguientes mensajes han quedado obsoletos a partir de DB16: <Nodo Origen> DB <Nodo Destino> 0 Q <Número de Serie Global> Mensaje rutable en la red IRC. Permite que un nodo pregunte a otro qué versión tiene de la Base de Datos y/o borrarla. En el caso de que el otro extremo no lo consideremos HUB, se ignora debido al parche DB8. De otra forma un nodo arbitrario podría borrar cualquier base de datos de la red. <Nodo Origen> DB <Nodo Destino> 0 q <Número de Serie Local> <Hash> Mensaje rutable en la red IRC. Respuesta al mensaje anterior.

<Nodo Origen> DB <Nodo Destino> 0 D <nonce> <BDD> (formato DB17)

Mensaje Broadcast. Sólo se acepta si proviene de un HUB. Borra la BDD local si el nodo cumple la máscara.

<Nodo Origen> DB <Nodo Destino> 0 E <nonce> <BDD> (formato DB17)

Mensaje rutable en la red. Cada nodo que borre la copia local de la BDD responde al nodo que realizó la petición con este mensaje.

<Nodo Origen> DB <Nodo Destino> 0 Q <nonce> <BDD> (formato DB17)

Mensaje Broadcast. Sólo se acepta si proviene de un HUB. Consulta la versión y el HASH de la BDD local si el nodo cumple la máscara.

A partir de DB93, se puede preguntar por la tabla "*" (asterisco). El resultado es similar al habitual, pero refleja valores que dependen de los valores de todas las tablas. Con esto se pretende poder validar las bases de datos distribuidas presentes en todos los nodos con un único comando, en vez de sondear cada tabla por separado. Los valores devueltos en sí no tienen ningún significado que quiera documentar, y están sujetos a cambios entre versiones.

<Nodo Origen> DB <Nodo Destino> 0 R <Número de Serie Local>-<Número de registros existentes>-<HASH>-<nonce> <BDD> (formato DB55)

Mensaje rutable en la red. Cada nodo que cumpla la máscara del mensaje anterior responde con el número de serie local de la BDD en cuestión, su HASH y el nonce usado en la petición inicial.

Ver los comentarios para "Q", a partir de DB93.

Los siguientes mensajes han quedado obsoletos a partir de DB55: <Nodo Origen> DB <Nodo Destino> 0 R <Número de Serie Local>-<HASH>-<nonce> <BDD> (formato DB17) Mensaje rutable en la red. Cada nodo que cumpla la máscara del mensaje anterior responde con el número de serie local de la BDD en cuestión, su HASH y el nonce usado en la petición inicial.

<Nodo Origen> DB <Nodo Destino> <Número de Serie> N <Clave> [Valor] (formato antiguo)

<Nodo Origen> DB <Nodo Destino> <Número de Serie> <BDD> <Registro> [Valor] (formato DB16)

Mensaje rutable en la red IRC. Registro de nick. Normalmente el Nodo Destino es "*". En el caso de que el otro extremo no lo consideremos HUB, se ignora debido al parche DB8. De esta forma evitamos que un servidor arbitrario pueda modificar bases de datos remotas.

A partir de DB16 se pueden tener hasta 26 BDD's: de la "a" a la "z". El caso de "N" es especial: se trata de un alias a "n", y me mantiene por compatibilidad con implementaciones antiguas. En cuanto todos los nodos de una red sean post-DB16, deberían modificarse las Bases de Datos locales para cambiar los "N" por "n" y propagar de nuevo toda la Base de Datos de nicks.

Aunque un servidor no implemente una Base de Datos determinada, debe mantener una copia local sujeta a las mismas actualizaciones, verificaciones, operaciones en "NetJoin", etc., que una Base de Datos que sí implemente. De esta forma, un HUB antiguo puede intercomunicar nodos modernos, de forma transparente.

Si la clave que se intenta meter en la BDD es un asterisco "*", el nodo realizará una compactación de la BDD.

Nodo Origen:

Identificador Numérico.

Nodo Destino:

Identificador Alfanumérico.

Número de Serie:

Valor decimal.

Las Bases de Datos Distribuídas actuales son:

• 10/Sep/03: Añadimos los registros "p09:" en la tabla "z".

• 04/Sep/03: Migramos los registros especiales, en plan "número de clones permitidos" y similares, a la nueva tabla "z". Esa tabla será la que se use a modo de configuración global de la red. Este cambio es efectivo a partir de DB115 (u2.10.H.07.56).

• 09/Jul/02: Documento la gestión de nicks suspendidos y prohibidos en la tabla "n".

• 24/Jun/02: Añadimos la tabla "w" (VIP35), para la gestión de las IPs virtuales personalizadas.

• 09/May/02: Documentamos los cambios de DB93, para permitir preguntar y responder un HASH que valida todas las bases de datos distribuidas, con un único comando.

• 10/Sep/01: Eliminamos la tabla "t", ya que la migración ya está en curso y "nick2" no usa esa tabla para nada. Cambio a partir de la versión 2.10.H.02.63 del servidor.

• 24/Nov/00: Se documentan los cambios de seguridad en la versión 2.10.H.02.02 del servidor.

• 20/Nov/00: Se documenta el uso del registro "." en la tabla "v".

• 05/Oct/00: Se añade información sobre los registros especiales ".." y "..." de la tabla "i".

• 03/Ene/00: Modificada la respuesta a "Q" para incluir más información. Parche "DB55".

• 27/Oct/99: Proporciono nueva información sobre las nuevas BDD.

• 13/Oct/99: Nuevas BDD registradas.

• 11/Oct/99: Añadida la sección de "problema con este esquema".

• 06/Oct/99: Primera versión de este documento.

• Registro de Nicks
• IRC Server 2.10.07 (modificaciones)
• IRC Server 2.10.06 (modificaciones)
• Fase 1: Desarrollo Inicial
• Fase 2: Despliegue de la Gestión Distribuída
• Libro Blanco de IRC ESNET
• ESNET
• Internet Relay Chat (IRC)
• La Página de Jesús Cea Avión

©1999-2003 jcea@jcea.es