From: Leandro Lucarella Date: Sun, 23 Nov 2003 18:47:00 +0000 (+0000) Subject: Se corrige documentacion y se agrega la pagina relacionada sobre el server X-Git-Tag: svn_import~199 X-Git-Url: https://git.llucax.com/z.facultad/75.42/plaqui.git/commitdiff_plain/d46988670a776e174147fc0cce35652383177785?ds=inline Se corrige documentacion y se agrega la pagina relacionada sobre el server (protocolo y otras cosas) que ahora la toma bien el doxygen. --- diff --git a/Server/include/plaqui/server/documentacion.h b/Server/include/plaqui/server/documentacion.h new file mode 100644 index 0000000..ddf5a02 --- /dev/null +++ b/Server/include/plaqui/server/documentacion.h @@ -0,0 +1,180 @@ +/** \page page_server PlaQui Server + +\section page_server_general Descripción General + El servidor está dividido en 2 módulos que provean 2 servicios diferentes. + + \subsection page_server_general_control 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 utilizado es una implementación limitada e incompleta de + HTTP 1.1. Solo se implementan los métodos POST y GET, tomando sólo en + cuenta la ruta del archivo a obtener (se ignora el query string de + GET y los datos recibidos por POST). Cada comando se representa a través de + una ruta a un archivo. Si el comando recibe parámetros, estos parámetros + son también representados como componentes de dicha ruta. + A cada comando se responde con una respuesta HTTP 1.1 (también a través de + una implementación incompleta y limitada). El cuerpo de la respuesta es un + archivo XML de texto plano en formato XML que contendrá la información + requerida por el comando (ya sea una lista de archivos o una respuesta + informando el éxito o error al cambiar las propiedades de una planta). + Este módulo está implementado por las clases PlaQui::Server::ControlServer + y PlaQui::Server::ControlClient. + + \subsection page_server_general_transmision 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 y continúa transmitiendo (en un principio) + hasta que recibe una petición de desconexión. + Lo que se envía es un archivo XML con el estado de la planta. + 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). + Este módulo está implementado por las clases PlaQui::Server::Transmitter y + PlaQui::Server::Receiver. + + +\section page_server_protocolo Comandos del Módulo de Control. + Todos los comandos son rutas de archivos. En un principio no se van a utilizar + los query string de los datos pasados por GET ni datos adicionales + recibidos por POST. Es decir, de un request HTTP solo se usara la ruta + para codificar los comandos. Por ejemplo, de: + \verbatim GET /ruta/que/representa/comando?query=string HTTP/1.1 \endverbatim + Sólo se utilizará \verbatim /ruta/que/representa/comando \endverbatim para + codificar el comando. El query string y los datos que se reciban por + POST serán ignorados silenciosamente (sin producir un error). + + Todos los comandos son respondidos con una respuesta XML que siempre + incluye un código de éxito/error. Adicionalmente puede devolver más datos en + la respuesta en cuyo caso se especifica expresamente. + + Los comandos se tiene una estructura general compuesta por 3 elementos: + - Destino: A quién se le envía el comando. + - Comando: El comando en sí (la acción a realizar). + - Argumentos: Opciones y datos necesarios para ejecutar el comando. + Esto se estructura como una ruta, por lo que todos los comandos se componen la + menos de 2 directorios, con cero o más argumentos representados a su + ves por archivos o más subdirectorios: + /verbatim /[destino]/[comando]/[argumento 1]/[...]/[argumento N] /endverbatim + + Los destinos disponibles son: + - server: Comandos para el servidor en sí. + - connection: Comandos para las conexiones. + - transmission: Comandos para las transmisiones. + - plant: Comandos para las plantas. + + \subsection page_server_protocolo_general Comandos para el Servidor. + Los comandos para el servidor, como se vio previamente, comienzan con + /server/ seguido de alguna de las siguientes opciones: + + + + + + + + + + + + +
ComandoDescripciónRespuesta
statusObtiene estado general del servidor.Cantidad de plantas, conexiones, transmisiones, versión, + uptime, etc.
stopDetiene el servidor.Nada.
+ + \subsection page_server_protocolo_control Comandos para una Conexión de Control. + Todos los comandos de transmisiones comienzan con /connection/ + y continúan con alguna de las siguientes opciones: + + + + + + + + + + + + +
ComandoDescripciónRespuesta
listObtiene una lista de las conexiones de control activas.Lista de conexiones activas (host, puerto, uptime, etc).
stop/[host]/[port]Finaliza la conexión de control del host [host] en el puerto + [port].Nada.
+ \note Los nombres entre [ y ] denotan un argumento. + + \subsection page_server_protocolo_transmision Comandos para una Transmisión. + Todos los comandos de transmisiones comienzan con /transmission/ + y continúan con alguna de las siguientes opciones: + + + + + + + + + + + + + + + + + +
ComandoDescripciónRespuesta
listObtiene una lista de las transmisiones activas.Lista de transmisiones activas (host, puerto, uptime, + etc).
start/[plant]/[host]/[port]Comienza la transmisión de la planta [plant] al [host] + en el puerto [port].Nada.
stop/[host]/[port]Finaliza la transmisión al [host] en el puerto + [port].Nada.
+ \note Los nombres entre [ y ] denotan un argumento. + + \subsection page_server_protocolo_planta Comandos para una Planta. + Todos los comandos de plantas comienzan con /plant/ y continúan con + alguna de las siguientes opciones: + + + + + + + + + + + + + + + + + + + + + + +
ComandoDescripciónRespuesta
listObtiene lista de plantas.Lista de plantas con info mínima de cada una (está + corriendo o no, uptime, cantidad de elementos,etc).
get/[planta]Obtiene la planta de nombre [planta].El mismo archivo que se crea en el Constructor.
stop/[planta]Finaliza la simulación de la planta de nombre .Nada.
set/[planta]/[elem]/[prop]/[val]Cambia la propiedad [prop] del elemento [elem], asignándole + el valor [val] a planta de nombre [planta].Nada.
+ \note Los nombres entre [ y ] denotan un argumento. + +\section page_server_uso Modo de uso. + Para utilizar el servidor es necesario disponer de un archivo XML de planta + (por ejemplo, generado por el Constructor). + + Invocación del servidor: + \verbatim ./plaqui-server [planta.xml] [puerto] \endverbatim + + Ambos argumentos son opcionales. El primero, [planta.xml], es la + ubicación del archivo con la descripción de la planta a simular (por omisión + prueba.xml). El segundo, [puerto], es el puerto en el cual + se van a atender las peticiones al servidor (por omisión 7522). + +*/ diff --git a/docs/mainpage.h b/docs/mainpage.h index ec016ab..6939d24 100644 --- a/docs/mainpage.h +++ b/docs/mainpage.h @@ -3,60 +3,61 @@ \section introduccion Introducción \subsection herramientas Herramientas Utilizadas - Aquí tenemos un listado de las herramientas y bibliotecas que estamos - utilizando a fin de poder luego documentar de manera correcta los - requerimientos para instalar y ejecutar el programa, las versiones y los - programas utilizados durante el desarrollo. - - Glade2: Editor RAD para crear interfaces de usuario - - GCC (3.3.x): Compilador C++ - - VIM: Editor de texto utilizado para programar - - Doxygen: Generador de documentación y referencias cruzadas - - GNU Make - - Automake - - Autoconf + Aquí tenemos un listado de las herramientas y bibliotecas que estamos + utilizando a fin de poder luego documentar de manera correcta los + requerimientos para instalar y ejecutar el programa, las versiones y los + programas utilizados durante el desarrollo. + - Glade2: Editor RAD para crear interfaces de usuario. + [http://glade.gnome.org/] + - GCC (3.2.x): Compilador C/C++. + [http://gcc.gnu.org/] + - VIM: Editor de texto utilizado para programar. + [http://www.vim.org/] + - Doxygen: Generador de documentación y referencias cruzadas. + [http://www.stack.nl/~dimitri/doxygen/] + - GNU Make. + [http://www.gnu.org/software/make/] + - Automake. + [http://www.gnu.org/software/automake/] + - Autoconf. + [http://www.gnu.org/software/autoconf/] \subsection bibliotecas Bibliotecas Utilizadas - - Gtkmm ( >= 2.0.0): Warper a C++ de la biblioteca Gtk+ - http://www.gtkmm.org/ - - Glademm ( >= 2.0.0): Para cargar archivos XML con la UI - http://www.gtkmm.org/ - - Glibmm ( >= 2.0.0): Funciones de threads y otras básicas. - http://www.gtkmm.org/ - - sigc++ ( >= 1.2.5): Sistema de señales para C++ - http://libsigc.sourceforge.net/ - - socket++ ( >= 1.12.10): Wrapper de socket portables en C++ streams - http://members.aon.at/hstraub/linux/socket++/ + - Gtkmm ( >= 2.0.0): Warper a C++ de la biblioteca Gtk+ + [http://www.gtkmm.org/] + - Glademm ( >= 2.0.0): Para cargar archivos XML con la UI + [http://www.gtkmm.org/] + - Glibmm ( >= 2.0.0): Funciones de threads y otras básicas. + [http://www.gtkmm.org/] + - sigc++ ( >= 1.2.5): Sistema de señales para C++ + [http://libsigc.sourceforge.net/] + - socket++ ( >= 1.12.10): Wrapper de socket portables en C++ streams + [http://members.aon.at/hstraub/linux/socket++/] \subsection requerimientos Requerimientos de Hardware y SO. - El trabajo práctico fue desarrollado bajo Debian GNU/Linux sid - (http://www.debian.org/), pero debería andar en cualquier GNU/Linux e - incluso probablemente en otros Unixes (e incluso podría llegar a andar - en WIN32). - \b Cliente: - - Procesador: PII 400 Mhz - - Memoria RAM: 64 Mb - - Espacio en disco: aun no confirmado - - SO: GNU/Linux + PlaQui fue desarrollado bajo Debian GNU/Linux sid (http://www.debian.org/), + pero debería andar en cualquier GNU/Linux e incluso probablemente en otros + Unixes (e incluso podría llegar a andar en WIN32). La versión para el + usuario (binaria y sin símbolos para depurar) requiere menos de 2MB de + espacio en disco. Para compilarlo (con símbolos para depurar) puede + necesitar más de 80MB. - \b Servidor: - - Procesador: Pentium 75MHz - - Memoria RAM: 16MB - - Espacio en disco: 5MB - - SO: GNU/Linux - - \b Constructor: - - Procesador: PII 400 Mhz - - Memoria RAM: 64 Mb - - Espacio en disco: aun no confirmado - - SO: GNU/Linux + \subsubsection requerimientos_minimos Requerimientos mínimos + Esta es la mínima configuración en la que fue probado. + - Procesador: Pentium 75MHz + - Memoria RAM (física y virtual): 32MB + + \subsubsection requerimientos_recomendados Requerimientos recomendados + - Procesador: PII 400 Mhz + - Memoria RAM: 64 MB \subsection instalacion Instalación. El programa se divide en 4 módulos: - Modelo: es el módulo que se encarga de la simulación y el modelo \c físico de la planta (es una biblioteca). - - Servidor: es la infrastructura de red. Comprende tanto el servidor - como el cliente en cuando al manejo de la red (es una biblioteca y un - programa). + - \ref page_server "Servidor": es la infrastructura de red. Comprende tanto + el servidor como el cliente en cuando al manejo de la red (es una + biblioteca y un programa). - Cliente: es el cliente gráfico que permite ver la simulación (es un programa). - Constructor: es el programa para diseñar la planta química que será