Propuesta de servidor v0.1:
-El servidor estará dividido en 2 modulos que provean 2 servicios diferentes:
+El servidor estará dividido en 2 módulos que provean 2 servicios diferentes:
1) Módulo de control.
El módulo de control se basa en el protocolo TCP y se encarga de listar
los archivos de planta disponibles en el servidor, permitiendo cambiar
las propiedades de cada uno y conocer su estado en términos generales
(si se está simulando o no). Todo lo que sean comandos (abrir una
- exclusa, llenar un tanque, etc) se realizan a través de este módulo.
- El protocolo que maneja este modulo es un HTTP simplificado. Se aceptan
- comandos simples (en un principio solo GET) a través de URLs.
+ exclusa, parar una bomba, etc) se realizan a través de este módulo.
+ El protocolo que maneja es un HTTP simplificado. Se aceptan comandos
+ simples (en un principio solo GET) a través de URLs.
Ejemplos:
Obtiene lista de archivos:
GET / HTTP/1.0
Cierra la <exclusa1> de la planta <archivo>:
- GET /archivo/set/exclusa1?cerrar HTTP/1.0
+ GET /<archivo>/set/<exclusa1>?cerrar HTTP/1.0
Pone el <caudal> de <canio1> en 3 l/s:
- GET /archivo/set/canio1?caudal=3 HTTP/1.0
+ GET /<archivo>/set/<canio1>?caudal=3 HTTP/1.0
Comienza la simulación de la planta <archivo>:
- GET /archivo/start HTTP/1.0
+ GET /<archivo>/start HTTP/1.0
Empieza a transmitir a host:port la simulación de la planta <archivo>:
- GET /archivo/connect?host=localhost&port=1234 HTTP/1.0
+ GET /<archivo>/connect?host=localhost&port=1234 HTTP/1.0
Deja de transmitir a host:port la simulación de la planta <archivo>:
- GET /archivo/disconnect?host=localhost&port=1234 HTTP/1.0
+ GET /<archivo>/disconnect?host=localhost&port=1234 HTTP/1.0
Los datos que envía este módulo están en formato XML, preferentemente con
un archivo de transformación XSLT (o como se llame :) para que pueda ser
visto en un browser cualquiera (que soporte esto, como Mozilla).
-2) Módulo de simulación:
+2) Módulo de transmisión:
Este módulo se encarga de transmitir la simulación en tiempo real por UDP
(como si fuera un video). Comienza luego de que el módulo de control recibe
una petición de transmisión (con connect) y continúa transmitiendo (en un
- thread propio) hasta que recibe un disconnect. Envia un archivo XML con el
- estado de la planta.
- En este caso no tiene sentido la XSLT porque no hay browsers HTTP que usen
- UDP :).
+ thread propio) hasta que recibe un disconnect. Envía un archivo XML con el
+ estado de la planta. En este caso no tiene sentido la XSLT porque no hay
+ browsers HTTP que usen UDP :).
+ El cliente debe validar lo recibido y mostrar todos los 'frames' válidos.
+ Mientras que no se reciban 'frames' válidos se debe mostrar el último
+ válido. Si no se recibiece durante una cantidad de tiempo determinada ningún
+ 'frame' válido, se asume un error en la red.
+ Si por casualidad los datos recibidos son incorrectos pero válidos (por
+ ejemplo, se recibe el comienzo de un 'frame' y el final del siguente), el
+ cliente lo mostrará igual porque no tiene forma de darse cuenta. Esto no es
+ problema si consideramos que en pocos milisegundos se recibirá un nuevo
+ 'frame' válido y correcto (similar a lo que pasa en transmisiones de audio o
+ video en tiempo real).
-Opcionalmente se puede hacer un módulo de simulación sobre TCP, que sólo envíe
-el estado actual de la planta en ese instante, o directamente implementarlo como
-un comando del módulo de control para poder verlo en un browser. Aunque esto ya
-sería más un cliente que un servidor :)
+Opcionalmente se puede hacer un Módulo de transmición sobre TCP, que sólo envíe
+el estado actual de la planta en ese instante y se desconecte, o directamente
+implementarlo como un comando del módulo de control para poder verlo en un
+browser. Aunque esto ya sería más un cliente que un servidor :)