Diseño: arquitectura para Cuartos de Baja

Notas de diseño: arquitectura para Cuartos de Baja

Thursday, 17 July 2003, 1:15:33 pm --Dario
Transporte alternativo: Jabber También se puede usar Jabber como transporte. La ventaja sería su mayor eficiencia para una implementación de RPCs... (ver http://www.jabber.org/)

Thursday, 17 July 2003, 1:09:47 pm --Dario
Primeras ideas: usar HTTP para la comunicación, XML para los mensajes (e incluso XML-RPC/SOAP si fuera necesario).

Rationale:

HTTP está ampliamente soportado, se conocen sus puntos fuertes y débiles, hay implementaciones usables tanto en servidores C (p.ej. mathopd, que es BSD) como para perl, python como clientes (libcurl).
XML permite definir los mensajes "sujetos a amppliación"; las nuevas versiones de las estructuras simplemente suponen valores por defecto para todos aquellos campos que no se conocen. Los campos que no se conocen se pueden incorporar a los mensajes de respuesta tal cual, etc.
En caso de ncesitar RPC (en general, no sunrpc), siempre es factible usar XML-RPC/SOAP, que son "triviales".

Puntos a depurar y posibles soluciones:

XML requiere bastante ancho de banda. El ancho de banda se puede corregir mandando los streams de datos comprimidos con la zlib.
XML requiere tiempo de proceso para parsear los mensajes. Se podría mejorar haciendo que mandase los mensajes en un formato binario (o textual O:-) más fácil de parsear. Ver http://www.xml.com/pub/a/2001/04/18/binaryXML.html para los pros y contras de hacer esto (AKA salirse del estándar).

Ejemplo concreto: servidor de estado Los siguientes pasos describen el funcionamiento teórico de un servidor de info en tiempo real a n clientes:

El servidor (BBDD) tiene un búffer circular de sucesos de un subsistema, cada uno con un timestamp, y el estado "global" a un timestamp determinado.
Los clientes se conectan, y piden información "contínua" a partir de un cierto timestamp. El servidor les va mandando elementos xml con dicha información según va llegando (y cada uno con su timestamp, de manera que si pierde la conexión se puede reconectar y pedir la info a partir de un cierto timestamp).
Si el cliente pide información al servidor a partir de un tiemestamp que ya no tiene o el servidor estima que es menor cantidad de datos el mandar el estado completo que los eventos desde ese timestamp, el servidor puede mandar el estado y después las actualizaciones a partir del timestamp del estado.

Descripción del proyecto

Se va a necesitar hacer un sistema de monitorización de los cuartos de baja. Aprovechando que es un subsistema relativamente independiente, se va a realizar con él un intento de hacer nuevas infraestructuras para captura.

(por completar)

Notas generales de diseño

Uso de tecnologías aceptadas No se trata de reinventar la rueda. En prinicio la idea es primar el uso de tecnologías estándar, adaptadas para el proyecto
Que sea capaz de acomodar todas las necesidades de captura de datos. No sólo para cuartos de baja, si no que sirva como experimento para mejorar la arquitectura de captura, basada actualmente en paso de mensajes mediante rpcs y la existencia de dos procesos "especiales", control y router.
Capacidad de prototipar Las tecnologías usadas deben ser lo suficientemente simples como para permitir hacer prototipos funcionales en lenguajes "rápidos", como perl, python, tcl/tk...
Especificación inicial pequeña y simple pero extensible. Hacer que la especificación inicial sea sencilla, fácilmente comprensible y prácticamente trivial de implementar. Sin embargo, es necesario que las extensiones para conseguir toda la funcionalidad necesaria no rompan la limpieza de diseño inicial.
Independencia y modularidad. Se pretende que la arquitectura proporcione una serie de módulos (librerías) com pocas dependencias de unas en las otras (p.ej. que cada extension sólo dependa de core) y con las librerías del sistema. Así pues, que no dependan ni de motif, ni de openview, ni de glib, ni de gtk, ni de... bueno, creo con esos ya se entiende la idea ;-)