X-Git-Url: https://git.llucax.com/z.facultad/75.42/plaqui.git/blobdiff_plain/b81da7a08ef57c3d0b9baa229eb5bd6b701fd84a..fb2d20d28eedbd1b0a98c05a03da5643924d04f9:/Server/include/plaqui/server/documentacion.h diff --git a/Server/include/plaqui/server/documentacion.h b/Server/include/plaqui/server/documentacion.h index 2b268ec..ea3c53e 100644 --- a/Server/include/plaqui/server/documentacion.h +++ b/Server/include/plaqui/server/documentacion.h @@ -57,7 +57,6 @@ 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 @@ -205,53 +204,41 @@ Las respuestas del servidor, como se dijo anteriormente, son respuestas HTTP, cuyo cuerpo es un archivo XML. Este archivo se compone de un tag XML plaqui-response y tiene como atributos obligatorios code (indica - el código de respuesta, para saber si se realizó bien el comando) y version - (indica la versión del formato del archivo XML, para preveer la posibilidad de que - cambie en futuras versiones). También tiene un atributo opcional description - que permite agregar una descripción sobre la respuesta, útil para observar respuestas - con un navegador u otro cliente no específico. El tagplaqui-response - puede tener un contenido, en caso de que la respuesta necesite enviar información al - cliente (como al obtener una planta o una lista). El contenido es a su vez XML y en - el caso de la obtención de una planta tiene el mismo formato que el utilizado por el + el \ref PlaQui::Server::Response::Code "código de respuesta", para saber si se + realizó bien el comando) y version (indica la versión del formato del + archivo XML, para preveer la posibilidad de que cambie en futuras versiones). + También tiene un atributo opcional description que permite agregar una + descripción sobre la respuesta, útil para observar respuestas con un navegador u + otro cliente no específico. El tagplaqui-response puede tener un + contenido, en caso de que la respuesta necesite enviar información al cliente + (como al obtener una planta o una lista). El contenido es a su vez XML y en el + caso de la obtención de una planta tiene el mismo formato que el utilizado por el Constructor. -\section page_server_uso Modo de uso. - \subsection page_server_uso_inicio Inicio del servidor - Para iniciar el servidor es necesario disponer de un archivo XML de - planta (por ejemplo, generado por el Constructor). - - Invocación del servidor: - \verbatim ./plaqui-server [archivo] [puerto] \endverbatim - - Ambos argumentos son opcionales. El primero, [archivo], es la - ubicación del archivo con la descripción de la planta a simular (por omisión - planta.xml). El segundo, [puerto], es el puerto en el cual - se van a atender las peticiones al servidor (por omisión 7522). - - \subsection page_server_uso_estado Estado del servidor. - Mientras el servidor se ejecuta, va imprimiendo en la salida estándar su - estado. Se imprime cada vez que llega una conexión entrante y cada vez que - se detecta un error. - - Otro tipo de información del estado del servidor puede ser obtenida desde - el cliente a través del comando /server/info (ver - \ref page_server_protocolo_general). - - \note Los errores se imprimen en la salida de error, no en la salida - estándar. - - \subsection page_server_uso_fin Finalización del servidor. - Hay varias formas de finalizar el servidor: - - Enviando una señal de interrupción (SIGINT), por ejemplo, - presionando la combinación de teclas CTRL-C. - - Enviando una señal de salida (SIGQUIT) o de terminación - (SIGTERM), por ejemplo, a través del comando - kill(1). - - Enviando un comando /server/stop desde un cliente (ver - \ref page_server_protocolo_general). - - Cualquiera de estos métodos es válido y finaliza el servidor de forma - correcta. +\section page_server_implementacion Destalles de la implementación. + El servidor se basa en un la clase PlaQui::Server::Runnable que se utiliza para + encapsular un hilo de ejecución. De ella derivan todas las demás clases + importantes del servidor: PlaQui::Server::TCPServer y PlaQui::Server::Connection. + De esta última derivan todas las posibles conexiónes que hay para la comunicación + entre el servidor y el cliente: PlaQui::Server::ControlClient, + PlaQui::Server::ControlServer, PlaQui::Server::Receiver y + PlaQui::Server::Transmitter. Las dos primeras son utilizadas para la conexión + de control y las dos segundas para la transmisión del estado de la planta por + UDP. + + El protocolo HTTP se encapsula en la clases PlaQui::Sever::HTTPMessage y de ella + derivan PlaQui::Sever::HTTPRequest (petición HTTP) y PlaQui::Sever::HTTPResponse + (respuesta HTTP). Hay otras clases auxiliares como PlaQui::Sever::HTTPError que + encapsula un error HTTP. + + Finalmente, para abstraerse del protocolo HTTP que se usa de transporte, se + implementan dos clases: PlaQui::Sever::Command y PlaQui::Sever::Response que + representan un comando y una respuestas específicos del servidor PlaQui. + + A continuación se incluye un diagrama de clases para tener una visión más general + de las clases más importantes utiilzadas en el servidor: + \image html cliente_servidor.png + \image latex cliente_servidor.eps "Diagrama de clases." width=14cm */