vim: set ts=4 sw=4 tw=80:
$Id$

Propuesta de servidor v0.1:

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, 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
		Pone el <caudal> de <canio1> en 3 l/s:
			GET /<archivo>/set/<canio1>?caudal=3 HTTP/1.0
		Comienza la simulación de la planta <archivo>:
			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
		Deja de transmitir a host:port la simulación de la planta <archivo>:
			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 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. 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 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 :)