Para el intercambio de datos entre el cliente y el servidor se utilizó el protocolo HTTP, el mismo es un protocolo de red del nivel de aplicación, y es el que define la sintaxis y la semántica para la comunicación entre ambas partes (Fielding et al., 1999).
El protocolo HTTP se basa en un paradigma de peticiones y respuestas como se muestra en la figura 2.3, por lo que el cliente deberá enviar una petición en forma de método que incluya un identificador uniforme de recurso (URI, por sus siglas en inglés), la versión de protocolo usada, su información y el contenido de la petición. El servidor contestará con una línea de estado que incluye la versión del protocolo, un código de éxito o error, la información de este y un posible contenido de respuesta.
Figura 2.3 Paradigma de peticiones y respuestas del protocolo HTTP.
El servidor será localizado por el cliente siguiendo el esquema HTTP el cual se usa para localizar recursos en la red por medio de este protocolo. Por lo que la sintaxis de petición debe ser la siguiente: http://direccion:puerto/path.
En dicha sintaxis, dirección es el nombre del dominio de Internet o la dirección IP donde se encuentre ejecutándose el servidor, puerto es el número que indica el puerto al que se envía la petición y path indicará el recurso accedido. En el marco de este trabajo el gestor de peticiones se alcanzará a través del pathindex.php.
CAPÍTULO 2. LA ARQUITECTURA CLIENTE-SERVIDOR PARA EL SERVICIO DE
LOCALIZACIÓN 26
El protocolo HTTP define 8 métodos para realizar las peticiones al servidor. Entre estos se encuentran el método GET y el método POST. Cuando se utiliza el método GET los datos se envían al servidor a través del localizador uniforme de recursos (URL, por sus siglas en inglés). Mientras que en el caso del método POST, los datos a enviar al servidor se incluyen en el cuerpo de la misma petición (Fielding et al., 1999).
La petición realizada por el cliente al gestor de peticiones se lleva a cabo combinando los métodos GET y POST a través de los cuales se envían al servidor los siguientes datos:
• Tipo de modo.
• Lista de parejas MAC – RSSI de todos los APs detectados.
• Coordenadas de localización.
• Identificador de localización.
El identificador del tipo de modo se envía a través de la variable action utilizando el método GET, mientras los otros datos se envían en el cuerpo del mensaje utilizando el método POST. La lista de parejas MAC-RSSI solo se enviará si se accede en algún modo donde el cliente sea el objetivo al que se le necesite estimar la localización. Las coordenadas de localización y el identificador de localización solamente son enviadas en el modo de entrenamiento. Los identificadores de tipo de modos enviados al servidor a través de la variable GET action y la estructura en que deben ser enviados los datos desde el cliente pueden ser consultados en los Anexos I y II.
Luego de validarse los datos en el servidor, si estos fueron correctos y el resultado de la petición fue satisfactorio, se envía al cliente el resultado. El éxito o el fallo de la petición será reconocida por el cliente encuestando el código de respuesta enviado por el servidor. Este será un número entero igual a 200 si la respuesta es correcta y cualquier otro como notificación del tipo de error ocurrido. El listado completo de códigos de respuesta puede ser consultado en el Anexo III. Las figuras 2.4 y 2.5 obtenidas con ayuda del analizador de protocolos de red Wireshark (Orebaugh et al., 2006) muestran un ejemplo de petición- respuesta del sistema operando en el modo LBS, donde se observa el intercambio de datos entre el cliente y el servidor.
Figura 2.4 Ejemplo de petición del cliente para la estimación de la localización utilizando el protocolo HTTP.
Figura 2.5 Ejemplo de respuesta del servidor para una solicitud de estimación de la localización utilizando el protocolo HTTP.
Como se puede apreciar en la figura 2.5 la petición fue llevada a cabo correctamente y el servidor en la cabecera de la respuesta, además de incluir los parámetros necesarios para el funcionamiento del protocolo explicados anteriormente, ha incluido las coordenadas calculadas y el nombre del área en cuestión. Es importante destacar que las coordenadas son respecto a la imagen seleccionada como mapa del área.
Las coordenadas y el nombre del área a la que pertenecen han sido incluidas en la cabecera dado que el protocolo HTTP permite, mediante el parámetro content-type, especificar dinámicamente el tipo de contenido que es enviado en el cuerpo del mensaje, permitiendo al cliente interpretarlo y presentarlo al usuario. Es por ello, que el cuerpo del mensaje se ha reservado para enviar como contenido al cliente, una imagen o mapa de la zona donde se encuentra, con una marca que represente su localización o varias localizaciones
CAPÍTULO 2. LA ARQUITECTURA CLIENTE-SERVIDOR PARA EL SERVICIO DE
LOCALIZACIÓN 28
dependiendo del tipo de modo seleccionado en la petición realizada. Esto permite el menor procesamiento de datos del cliente móvil y una reducción en la complejidad del mismo, el cual solo debe interpretar la respuesta recibida y presentarla al usuario en forma de imagen. No obstante, la información comentada anteriormente, añadida en la cabecera, permite el desarrollo de clientes personalizados o el uso de dicha información para LBSs externos. Cuando el servidor opera en modo de entrenamiento el intercambio de información entre estos opera de manera similar, por lo que solamente es válido destacar que en caso de existir mediciones realizadas previamente, la respuesta incluirá el mapa con dichas mediciones representadas por marcas de color verde, permitiendo la actualización de manera dinámica de la aplicación entrenadora y por consiguiente un proceso de entrenamiento asistido ordenado.