CENTRO NACIONAL DE INVESTIGACI~N Y DESARROLLO TECNOL~GICO
CENID E T SERVIDOR PROXY CACHE CON SOPORTE A OPERACIONES EN MODO
DESCONEXI~N EN REDES INALÁMBRICAS
T E S I S PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS
EN CIENCIAS COMPUTACIONALES
P R E S E N T A FREDY JUÁREZ PÉREZ
Director de Tesis M.C. JUAN GABRIEL GONZÁLEZ SERNA
Co-Director de Tesis DR. VíCTOR JESÚS SOSA SOSA
CUERNAVACA, MORELOS FEBRERO 2005
IFlNVKY DE INFORMACION
M10 ACEPTACI~N DEL DOCUMENTO DE TESIS
Cuernavaca. 1!4or.> a 18 de Enero del 2005
Dr. Cerardo Reyes Salgado Jefe del Departamento de Ciencias de la Computación Presente.
At’n Dr. Reiié Santaolaya Salgado Presidente de la Academia de Ciencias de la Computación
Nos es grato comunicarle. que confomie a los linealnientos para la obtención del grado de Maestro en Ciencias de este Centro. y después de haber sometido a revisión académica la tesis titulada: Servidor Proxy Cache con Soporte a Operaciones en Modo Desconexión en Redes Inalámbricas, realizada por el C. Fredy Juárez Perez, y dirigida por el M.C. Juan Gabriel González Serna y el Dr. Victor Jesús Sosa Sosa. y habiendo realizado las correcciones que le fueron indicadas, acordamos ACEPTAR el documento final de tesis, as¡ mismo le solicitamos tenga a bien extender el correspondiente oficio de autorización de inipresióii.
Atentamente La Comisión de Revisión de Tesis
Salgado Hernández
Centro Nacional de Investigación cenidet y Desarrollo Tecnológico Sistema Nacional de Institutos Tecnológicos
MI1 AUTORIZACI~N DE IMPRESI~N DE TESIS
Cueiiiavaca, Mor.: a 18 de Enero del 2005
C. Fredy Juárez Pérez Candidato al grado de Maestro en Ciencias en Ciencias de la Computación Presente.
Después de haber atendido las indicaciones sugeridas por la Coniisión Revisora de la Academia de Ciencias de la Computación en relación a su trabajo de tesis cuyo titulo es: Servidor Proxy Cache con Soporte a Operaciones en Modo Desconexión en Redes Inalámbricas, me es grato coniuiiicarle que conforiiie a los liiieaniientos establecidos para la obtención del grado de Maestro en Ciencias en este centro se le concede la autorización para que proceda con la impresión de su tesis.
Atentamente
Jefe del Departamento de Ciencias de la Coinputación
c.c.p. Subdirección Académica Presidente de la Academia de Ciencias de la Computación Departamento de Servicios Escolares Expediente
Dedicatorias A Dios:
Por ser bueno y generoso conmigo, Por cuidar a los míos, Por darme la vida y permitime alcanzar las metas propuestas.
A mi esposa Paula:
Por el inmenso cariño, por sus cuidados, por sus atenciones, por los buenos momentos juntos.
A mis padres Silvano y Gaudencia:
Por creer en mí y en cada aventura que he emprendido, sus nombres son motivo de orgullo para ser mejor cada día.
A mis hermanos:
Rodolfo, Griselda, Aurelia, Evelia y Silvano
Por su apoyo y preocupación, por su trabajo constante en cada una de sus famillas, ahora les toca creer en sus hijos, que en cada generación se puede ser mejor.
A mis sobrinos Enrique, Víctor, Erick, Juana, Pablo, Maria del Carmen, Maria de Jesús, Maria Guadalupe, José, Patricia y Gabriela:
Por su cariño y ternura para su tío, Aprendan y nunca dejen de soñar con ser los mejores doctores, maestros, ingenieros, astronautas, políticos, arquitectos, matemáticos, fisicos, licenciados, deportistas, artesanos, músicos, técnicos y cada profesión que decidan en su vida.
A mis cuñados Oralia, Enrique, Felix, Fernando y Graciela:
Por ayudar a construir esta familia que será recordada por muchos siglos
“Hacia el futuro, un miembro de la dinastía Juárez, alcanzará las estrellas hacia la conquista del espacio, en la preservación de la raza humana ... ’I.
Fredy Juárez Pérez Febrero del2005.
Agradecimientos A memoria a mis abuelos Atanasio Juarez Garcia t , Celestina Sarmiento de
Juárez t, Adalberto Pérez t, Catalina Castillo de Pérez.
AI Centro Nacional de Investigación y Desarrollo Tecnológico (Cenidet) por
dame la oportunidad de seguir adelante con mis estudios.
Al Consejo del Sistema Nacional de Educación Tecnológica (C.O.S.N.E.T.) por
el apoyo económico otorgado para realizar mis estudios de maestría en el cenidet.
A la Secretaría de Educación Pública (S.E.P.) por el apoyo económico otorgado
para realizar mis estudios de maestría en el cenidet.
A mi director de tesis M.C. Juan Gabriel González Sema, por ser mi amigo y
saber alentarme a teminar mis estudios.
AI Dr. Victor Jesús Sosa Sosa por su amistad, jviva el Tec. de Madero!
A mis revisores de tesis Dr. Rene Sataolaya salgado, M.C. José Antonio Zárate
Marceleño, M.C. Carlos Felipe Garcia Hernández. Gracias por su dedicación y
observaciones al trabajo desarrollado, por las correcciones y consejos del proyecto, por
las pláticas informales que nos recuerdan nuestro lado humano de la amistad.
A cada uno de los maestros del cenidet por sus conocimientos transmitidos
A mis compañeros de maestría Toledo, Vega, Manuel, May, Pepe, Luisillo, Pancho, Isaac, Isidro, Jorge, Alex, Roy, Shei, Ary, Ali, Xóchilt y pichilita.
A mis amigos de batallas del Tec de Madero: Isaac Hernandez, Ramón Chávez, Jorge Vázquez, Javier Gutiérez, Oscar Rocha, Genaro blanco, Jorge Mercado, Alfred0 escobar, David Zepeda, ¡juntos arreglamos el mundo!.
Tabla de Contcnido
TABLA DE CONTENIDO
Tabla de contenido Lista de figuras. Lista de tablas. Glosario. Resumen.
I
iv vi vii X
CAP~TULO 1. INTRODUCCI~N. 1.1 Descripción del problema. 3 1.2 Estado del arte. 3
1.2.1 Gestor de desconexión y reconexión para sistemas clientekervidor 3 móviles. 1.2.2 Maneio de movilidad de clientes y conexiones intermitentes en 4 .. dispositivos móviles para el acceso a la Web. 1.2.3 Middleware para acceso a la información móvil 1.2.4. Tabla comparativa.
1.3 Objetivo general. 1.4 Propuesta de solución y metodología. 1.5 Alcances y limitaciones. 1.6 Beneficios. 1.7 Organización del documento.
CAPÍTULO 2. MARCO TEÓRICO. 2.1 TCPíIP en Unix.
2.1.1 Procesos y descriptores en Unix. 2.1.2 Lectura y escritura a través de descriptores
2.2.1 Conexiones simultáneas. 2.2.2 Servidores multiproceso y multithread. 2.2.3 Servidores monoproceso.
2.2 Servidores concurrentes.
2.3 El modelo de interacción asíncrono no interactivo. 2.4 El protocolo HTTP.
2.4.1 Etapas de una transacción HTTP. 2.4.2 Conexiones Keep-Alive.
CAP~TULO 3. ESPECIFICACIÓN DE REQUEFUMIE.!TOS Y CA uso. 3.1 Ámbito.
3.1.1 Perspectiva del Producto. 3.1.2 Funciones del Prototipo.
3.2 Descripción de las Funciones. 3.2.1 El D ~ O X Y lado cliente.
5 6 7 7 9 10 10
13 13 14 15 15 15 15 17 18 19 20
OS DE
22 22 22 23 23
3:2.1.i Recepción y envió de petición al lado servidor. 23 3.2.1.2 Recepción, almacenamiento de páginas HTML y objetos del 23
I I Tabla de Contenido I
proxy lado servidor. 1 23 24
3.2.1.3 Devolución de pagina y objetos al cliente (Navegador). 3.2.1.4 Construcción y devolución de páginas de estado en caso de desconexión. 3.2.1.4 Soporte a desconexiones (Monitoreo de conexiones).
3.2.2 El Proxv lado servidor. 24 1 A L;-f ~.
24 3.2.2.1 Recepción y gestión de peticiones al proxy caché Squid. 3.2.2.2 Parseo del código fuente en busca de los objetos contenidos. 24
24 3.2.2.3 Petición y almacenamiento de los objetos. 25
3.2.2.5 Soporte a desconexiones (Monitoreo de conexiones). 25 3.2.2.6 Construcción y devolución de páginas Web en caso de 25 desconexión.
3.2.2.4 Transferencia de objetos al proxy lado cliente.
~ ~~
3.2.2.7 Control y registro de eventos de desconexión para recuperación posterior. 3.2.2.8 Redireccionamiento de páginas al recuperarse de una desconexión.
3.3 Casos de uso. 3.3.1 Visualiza páginas Web sin desconexión 3.3.2 Visualiza error de conexión con el proxy lado servidor. 3.3.3 Visualiza error de conexión con el proxy caché Squid. 3.3.4 Visualiza, determina y controla eventos de desconexión. 3.3.5 Visualiza y se recupera de eventos de desconexión.
3.4 Usuarios del sistema. 3.5 Limitaciones de software.
CAPÍTULO 4. ANÁLISIS Y SOLUCIÓN CONCEPTUAL DEL PROBLEMA. 4.1 Descripción del problema.
4.2 Diseño de la solución. 4.1.1 Eventos de desconexión.
4.2.1 Modelo de interacción asíncrono no interactivo rediseñado. 4.2.2 Configuración de los componentes proxy.
4.3 Funcionamiento general del sistema. 4.4 Funcionamiento detallado de las operaciones soportadas.
4.4.1 El navegador Web solicita una página sin desconexión. 4.4.2 El navegador Web solicita una página Web y se determina un error de conexión con el proxy lado servidor. 4.4.3 El navegador Web solicita una página Web y se determina un error de conexión con el proxy caché Squid. 4.4.4. El navegador Web solicita una página Web y se determina una desconexión. 4.4.5 El navegador Web se recupera de una desconexión.
CAPITULO 5. ARQUITECTURA. 5.1 Proceso de atención a clientes. 5.2. Estructura de datos. 5.3. Descripción de funciones
25
25
32 34 36 36 31 38 42 43 44
45
46
48
.. . .
CAPITULO 6. PRUEBAS. 6.1 Objetivo de las pruebas. 6.2 Infraestructura utilizada, 57
57
6.4 Evaluación y pruebas. 61 62
6.4.1.1 Caso 1: el cliente solicita una página Web sin desconexión. 62 6.4.1.2 Caso 2: el cliente solicita una página y se desconecta. 63
65 6.4.2.1 Caso 1: el cliente solicita una página Web sin desconexión. 65 6.4.2.2 El cliente solicita una página Web y se determina un error de 69 conexión. 6.4.2.3 Diagramas de secuencias para error de conexión con el proxy 70 caché Squid. 6.2.4.4 Diagramas de secuencias para una desconexión. 72 6.2.4.5 Diagramas de secuencias para la recuperación una 75
6.3 Configuración de recursos para los escenarios de pruebas, 6.3.1 Configuración del escenario de pruebas A. 6.3.2 Configuración del escenario de pruebas para B.
6.4.1 Seguimiento y resultados del plan de pruebas A.
6.4.2 Seguimiento y resultados del plan de pruebas B.
desconexión. 6.5 Resumen de resultados obtenidos.
CAPITULO 7. CONCLUSIONES Y TRABAJOS FUTUROS. 7.1 Conclusiones. 7.2 Aportaciones. 7.3 Trabajos futuros.
ANEXO A. IMPLEMENTACI~N DE CONEXIONES PROGRAMACIÓN EIS MULTIPLEXADA. A. 1 Sincronización de conexiones (sockets). A.2 Seguimiento y sincronización de conexiones para una petición.
ANEXO B. DESCRIPCI~N DE FUNCIONES DEL PROTOTIPO. B.l Funciones de conexión. B.2 Funciones para el parseo de encabezados de peticiones HTTP. B.3 Funciones para el manejo de lista de peticiones. B.4 Funciones para el análisis de conexiones y E/S de datos. B.5 Funciones para el soporte orientado a conexión B.6 Lisia para el soporte y recuperación de desconexiones.
Referencias.
77
93
Lista de figuras
LISTA DE FIGURAS
Fig, 1.1 Modelo de interacción asíncrono. ~ i ~ , 1.2 Modelo de[ sistema y mecanismo de desconexión para Clientes móviles. Fig, 1.3 Obtención de información de diferentes proveedores de Isp. Fig. 1.4 Arquitectura general de proyecto Movi Ware. Fig. 1.5 Alineación de componentes y servicios. Fig. 2.1 Tabla de descriptores. Fig. 2.2 Modelo de interacción asincrona. Fig. 3. I Diagrama general sistema con soporte a desconexiones. Fig. 3.2 Casos de uso requeridos para la implementación del prototipo. Fig. 3.3 Caso de uso para visualizar Páginas Web sin desconexión. Fig. 3.4 Caso de usopara visualizar error de conexión con el proxy lado servidor. Fig. 3.5 Caso de uso para visualiza error de conexión con el proxy cache Squid. Fig. 3.6 Caso de uso para visualizar, determinar y controlar eventos de desconexión. Fig. 3.7 Caso de usopara visualizary recuperarse de una desconexión. Fig. 4.1 Modelo de Interacción síncrono. Fig. 4.2. Modelo cliente/servidor móvil. Fig. 4.3. Causas que originan una desconexión. Fig. 4.4 Desconexión entre un cliente móvil y su punto de acceso, y desconexión entre un cliente cableado. Fig. 4.5 Mensaje de error del navegador Web. Fig. 4.6. Configuración del escenario de pruebas B. Fig. 4.7. Modelo de interacción para el SPCD. Fig. 4.8 Alineación de componentes y servicios. Fig. 4.9 Alineación detallada de componentes y servicios. .Fig. 4.10 Diagrama de secuencias general. Fig. 4.I1. Interacción de componentes con el uso del protocolo H U P . Fig. 4.12. Diagrama de secuencias para una petición sin desconexión. Fig. 4.13. Proxy lado servidor construye página de estado de aceptación de petición. Fig. 4.14 Diagrama de secuencias para un error de conexión. Fig. 4.15. Proxy lado cliente construye página de eitado de error de conexión. Fig. 4.16. Diagrama de secuencias para un error de conexión con el proxy caché Squid. Fig. 4.17. Proxy lado servidor construye página de estado de error con el proxy caché Squid. Fig. 4.18. Diagrama de secuencias para una desconexión. Fig. 4.19. Proxy lado servidor genera y guarda el evento de desconexión. Fig. 4.20. P r o q lado cliente construye página de estado para una desconexión, Fig. 4.21. Proxy lado cliente construye página de estado para un error de conexión. Fig. 4.22. Diagrama de secuencias para una recuperación de una desconexión. Fig. 4.23. Proxy lado servidor construye página de estado para una conexión
4 5 6 8 9 14 18 22 26 27 27 28 29
30 33 33 34 34
35 36 36 37 38 39 40 43 43
44 45 45
-iv-
pendiente. Fig. 5.1 Servidor monoproceso. Fig. 5.2. Manejo de peticiones múltiples. Fig. 5.3. Arquitectura para el servidor proxy caché con soporte a operaciones en modo desconexión en redes inalámbricas. Fig. 5.4 Estructuras del proxy lado cliente. Fig. 5.5 Estructuras del proxy lado servidor. Fig. 6. I . Configuración del escenario de pruebas A. Fig. 6.2. Configuración del escenario de pruebas B. Fig. 6.3. Alineación de componentes y servicios. Fig. 6.4. Configuración del navegador Web para usar un Proxy. Fig. 6.5 Diagrama de secuencias para una petición sin desconexión. Fig. 6.6 Visualización de página HTML sin carga de objetos. Fig. 6.7 Visualización de página HTML completa. Fig. 6.8 Diagrama de secuencias para una petición con desconexión. Fig. 6.9 Mensaje de error del navegador Web. Fig. 6.10 Diagrama de secuencias para una petición sin desconexión. Fig. 6. I I Navegador sisualiza página de estado de aceptación de petición. Fig. 6.12 Visualización de página HTML sin carga de objetos. Fig. 6.13 Visualización de página HTML completa. Fig. 6.14 Diagrama de secuenciaspara un error de conexión. Fin. 6.15 Navepador sisualiza pápina de estado de error de conexión I - - -
Fig. 6.16 Diagrama de secuenciaspara un error de conexión con el proxy cache Squid. Fig. 6.1 7 Navegador Web visualiza página de estado de error con el proxy cache Squid. Fig. 6.18 Diagrama de secuencias para una desconexión. Fig. 6.19Navegar Web visualiza página de estado para una desconexión. Fig, 6.20 Navegador Web visualiza página de estado para un error de conexión. Fig. 6.21 Diagrama de secuencias para una recuperación de una desconexión. Fig. 6.22 Navegador Web visualiza página de estado para una conexión pendiente. Fig. 6.23 Mensaje mostrado por le navegador Web para una petición que no puede ser enviada debido a una desconexión. Fig. 6.24a. Petición esta siendo procesada. Fig. 6.24b. Proxy detecta una desconexión. Fig. 6 .24~ . Proxy no puede reconectarse. Fig. 6.24 Proxy se reconecta y muestra solicitud pendiente. Fig. 6.24e. Petición está siendo recuperada. Fig. 6.24f: Proxy completa la transferencia de la página. Fig. 7. I Direccionamiento dinámico de proxy caches cooperativas en la Web. Fig. A.I. Estados de una conexión. Fig. A.2 Serie de estados de las conexiones en una petición. Fig. A.3. Habilitación del puerto de escucha. Fig. A.5. Lectura de una petición y conexión con elproxy caché Squid. Fig. A.6. Escritura de petición al proxy caché Squid. Fig. A. 7. Lectura de una petición procedente del proxy caché Squid. Fip, A.8. Escritura de datos al cliente.
Lista de figuras
51 52 53
55 55 58 59 60 60 62 63 63 64 65 66 67 68 68 69 70 71
72
73 74 75 76 77 77
78 78 78 78 78 78 82 84 85 87 88 88 88 88 89
-Y-
Lista de tablas
LISTA DE TABLAS
Tabla 1.1 comparativa entre el servidor con soporie a desconexiones y otras 7 aplicaciones.
Tabla 4.1 Diagramas de secuencias para el soporte a desconexiones
Tabla 4.2 Operaciones soportadas por el sistema.
Tabla 6.1 Actividades para el plan de pruebas A.
Tabla 6.2 Actividades para el plan de pruebas B.
38
42
61
61
GLOSARIO
SPCD:
DNS
Servidor proxy caché con soporte a operaciones en modo desconexión en redes inalámbricas.
(Domain Name System). Sistema de nombres de dominio. El DNS un servicio de búsqueda de datos de uso general, distribuido y multiplicado. Su utilidad principal es la búsqueda de direcciones IP de sistemas centrales (hosts) basándose en los nombres de estos.
Cliente o usuario móvil: inalámbrico como enlace.
Equipo que solicita servicios en una red utilizando un medio
Ethernet: Estándar IEEE 802.3. Se refiere al tipo de cableado entre los que se pueden mencionar: coaxial grueso, coaxial delgado, par tranzado y fibra óptica.
Internet: Sistema de redes de computadoras enlazadas, con enlace mundial y de crecimiento continuo, que facilita servicios de transmisión de datos como el inicio de sesión remoto, transferencia de archivos, correo electrónico, World Wide Web y grupos de noticias. Internet, la cual descansa sobre TCPIIP, asigna a cada computadora conectada una dirección IP, con el fin de que dos computadoras conectadas puedan localizarse entre sí en la red para intercambiar datos.
Javascript:
Middleware:
Lenguaje de programación para WWW desarrollado por Netscape, es un lenguaje interpretado orientado a las páginas Web, con una sintaxis semejante al lenguaje Java.
Se le llama al software que se ubica entre los programas de aplicación que se utilizan y el sistema operativo,
(agenda, contactos, calendario,. . .)
Proxy: Servidor especializado en centralizar el tráfico entre lnternet y los usuarios, de forma que evita que cada una de las máquinas de la red interior tenga una conexión directa a Internet. Algunos pueden almacenar páginas Web a las que los miembros del servicio tienen acceso frecuente, de esta manera, cuando los miembros solicitan estas páginas, el servidor proporciona la copia almacenada en lugar de solicitar la página a Internet.
Punto de acceso: Concentrador inalámbrico (HUB inalámbrico).
Red inalámbrica: Red de computadoras interconectadas mediante dispositivos inalámbricos.
Servidor: Equipo que ofrece diversos servicios a los clientes tales como páginas Web, bases de datos, sistemas de archivos, entre otros.
Servidor Proxy cache: Servidor que ha sido configurado para almacenar páginas Web a las que los miembros del servicio tienen acceso frecuente. Cuando los miembros solicitan estas páginas, el servidor proporciona la copia almacenada en lugar de solicitar la página a Internet.
URL:
WLAN:
WWW:
Bluetooth:
Roaming:
(Universal Resource Locator). Localizador Universal de Recursos. Sistema unificado de identificación de recursos en la red. Permite identificar objetos WWW, Gopher, FTP, etc. Es una cadena que suministra la dirección Internet de un sitio Web o un recurso WWW, junto con el protocolo.
(Wíreless Local Area Nehvork). referirse a las redes de área local en un ambiente inalámbrico.
Termino utilizado para
Red mundial de información (World Wide Web), Sistema mundial de hipertexto que utiliza Internet como mecanismo de transporte. En un sistema de hipertexto, el usuario navega con sólo hacer clics en hipervínculos, lo que presenta en pantalla otro documento (que también puede contener hipervínculos).
Sistema de comunicación inalámbrica que permite la interconexión de diferentes dispositivos electrónicos (PCs, teléfonos fijos y móviles, agendas electrónicas, auriculares, etc.) a corto alcance.
Tecnología que permite que el usuario de un equipo móvil pueda utilizarlo en una red celular fuera de la coberiura de la red
-vi¡¡-
TCPIIP:
FTP:
"IUJaII"
a la que pertenece, permitiendo así hacer y recibir llamadas, siendo esto posible, sólo si hay un acuerdo entre operadores de redes de telefonía móvil. Es un conjunto de protocolos de comunicaciones que definen cómo se pueden comunicar entre sí ordenadores y otros dispositivos de distinto tipo.
Es uno de los diversos protocolos de la red Internet, concretamente significa File Transfer Protocol (Protocolo de Transferencia de Archivos) y es el ideal para transferir datos por la red.
I
-ix-
Resumen
Resumen
El esquema de trabajo de las arquitecturas tradicionales de software clienteiservidor no contempla en su modelo de interacción, la gestión de eventos de desconexión como situaciones comunes, por el contrario los atribuye a fallas de hardware o del medio fisico de transporte. Por tal razón, lo consideramos inadecuado para ambientes de cómputo móvil y cabieado.
Tradicionalmente, el modelo de interacción clienteiservidor es síncrono, lo cual significa que el cliente y el servidor deben estar en línea para realizar cualquier petición, el cliente generalmente controla la transacción y no mantiene su estado, si se presenta un evento de desconexión, el cliente debe repetir la consulta nuevamente, sin poder recuperar los resultados de la primera transacción. Para solucionar esta problemática, a lo largo de este trabajo de investigación hemos desarrollado un prototipo basado en un cliente y un servidor para dar soporte al modelo de interacción asíncrono no interactivo, además de la utilización del proxy cache Squid para dar soporte a caching de paginas Web, proporcionando servicios en modo desconexión y recuperación de desconexiones en redes basadas en el estándar 802.1 1 y 802.3.
De esta forma se dan soluciones a los problemas que presentan los navegadores Web al presentarse eventos de desconexión, entre los que destacan: a) el navegador no puede enviar peticiones HTTP o recibir las respuestas del servidor Web, b) el navegador es forzado a mostrar páginas de error para las peticiones HTTP incompletas, c) la petición original del cliente se ha perdido o ha sido mostrada en forma incompleta, d) el navegador ha quedado imposibilitado para realizar nuevas peticiones, d) el cliente debe corregir la falla de comunicación y volver a realizar la petición nuevamente.
En base a estas problemáticas establecidas, explicamos las operaciones soportadas por el sistema y detallamos las acciones implementadas, las cuales están identificadas como casos de uso que son las siguientes: a) el navegador Web solicita una página sin desconexión, b) el navegador solicita una página Web y se determina un error de conexión con el proxy lado servidor, c) el navegador solicita una página Web y se determina un error de conexión con el proxy cache Squid, d) el navegador solicita una página Web y se determina una desconexión, e) el navegador se recupera de una desconexión.
El desarrollo e implementación de esta tesis aporta una solución para el P d l e M a @e wpnen las eventos de desconexion ' I en redes :nalLmbr:cas y cableadas. La metodología desarrollada está enfocada al diseño de servicios intermediarios que procesan peticiones basadas en el protocolo HTTP, y dan soporte a eventos de desconexión. Asimismo, brindan la posibilidad de poder continuar, procesar, almacenar y recuperar las peticiones no completadas, ya que su diseño está basado en el modelo de interacción asíncrono no interactivo.
".
Abstract
Abstract
The work scheme of software traditional architecture clienthewer does not contemplate in its interaction 'model the management of disconnection events as common situations, on the contrary, it ascribes them to hardware failures or the physical transportation route. For this reason, we consider it inadequate for mobile computing and wired environments.
Traditionally, the clientíserver interaction model is synchronous, which means that the client and the server must be in line to perform any request. The client generally controls the transaction and does not maintain its status, if a disconnection event occurs, the client must repeat the request again, without the possibility of recovering the result of the first transaction. To solve this problem, along this investigation research we have developed a prototype based on a client and a server to give support to the non- interactive asynchronous interaction model, moreover, we use the Squid proxy cache to give support to Web pages caching, providing services in disconnection mode and recovering from disconnections in networks based on the 802.11 and 802.3 standards.
In this way, we give solutions to the problems presented in Web browsers when disconnection events occur, the most important problems are: a) the browser cannot send HTTP request or receive responses from the web server, b) the browser is forced to show error pages for incomplete HTTP requests, c) the original client request has been lost or has been shown in an incomplete manner, d) the client must correct the communication failure and perform the request again.
Based on these established problems, we explain the supported operations by the system and detail their implemented actions, which are identified as use cases and are the following: a) the Web browser requests a Web page without disconnection, b) the browser requests a Web page and a disconnection error with the proxy on the server side is determined, c) the browser requests a Web page and a disconnection error with the Squid proxy cache is determined, d) the browser requests a Web page and a disconnection is determined, e) the browser recovers from a disconnection.
The development and implementation of this thesis provides a solution to the problems generated by disconnection events on wired and wireless networks. The developed methodology is focused on the design of intermediate services that process requests based on the HTTP protocol, and give support to disconnection events. Likewice, they offer thb p b ~ ~ i l i i l h y of being able to continue, to process, to store and to recover uncompleted requests, because its design is based on the non-interactive asynchronous interaction model.
The obtained results are the base for the development of new intermediate services which will provide greater improvements to the asynchronous processes that are not based on the HTTP and FTP protocols, or can be focused on traditional processes of databases, and even be focused on other communication protocols that do not have disconnection support.
CAPíTULO 1
I
La presencia de una infraestructura que soporte redes inalámbricas es cada vez nayor; a medida que esta tecnología está siendo asimilada por las empresas como una ;olución a las necesidades de conexiones para equipos portátiles hacia la Web, los querimientos de los usuarios móviles son cada vez mayores y han pasado, de recuperar nformación de la Web, a la ejecución de aplicaciones críticas de comercio electrónico y nanejo de transacciones. Así, el perfil de los usuarios ha cambiado, han pasado de ser isuanos fijos que tienen acceso a la Web con equipos conectados a la red cableada, a isuanos móviles conectados a una infraestructura de red inalámbrica (WLAN).
desconexiones.
I 1.1 DESCRIPCI~N DEL PROBLEMA I
- .
operaciones que se realizan como consu¡tas en buscadores de páginas Web, transferencias de datos, consultas a bases de datos, operaciones de comercio, entre otras, requieren de una conexión persistente para llevarse de principio a fin.
Estos equipos pueden experimentar eventos de desconexión con la red, derivados de los siguientes problemas: a) retiro de la tarjeta inalámbrica, b) desconexión de los equipos del suministro de energía o falla general, c) desconexión del cable de red, e) desplazamiento fuera del área de cobertura del punto de acceso, e) falla de kernel para
arender los procesos EIS de las conexiones, por mencionar alpnos. Por 10 tantp if [f@ifrf h i I l Y I imulementar mecanismos con cauacidades de reaccionar a las frecuentes desconexiones de
su entorno de ejecución.
Como resultado de la problemática desbrita anteriormente y de la experiencia obtenida de los trabajos previos [21] en esta área, consideramos que el esquema de trabajo tradicional de las aplicaciones cliente/servidor está cambiando drásticamente. Esto io podemos afirmar ya que identificamos varios problemas derivados de las WLAN, entre los que destacan: a) el modelo de interacción ciiente/servidor es inadecuado para entorno de cómputo móvil, b) el manejo de eventos de desconexión no se contempla en las arquitecturas tradicionales de software. Mientras estos problemas no se solucionen, los equipos portátiles conectados mediante enlaced inalámbricos o cableados enfrentarán situaciones que las arquitecturas como la clienteíservidor tradicional no manejan de manera adecuada.
Por lo tanto, el problema a resolver en este trabajo de tesis es la comunicación interrumpida al presentarse eventos de desconexión para poder garantizar la continuidad de las peticiones en internet a pesar de las desconexiones en la red inalámbrica o cableada.
1.2.1 Gestor de desconexión y reconexión para sistemas cliente/servidor móviles [ O i l
Para resolver el problema de las desconexiones se propone un proxy que represente al cliente en la red fija después de una desconexión, de esta manera, se establece un modelo de interacción asíncrono no interactivo 1021 con la red fija.
Los datos que recupera el proxy los almacena en un disco duro, para cuando el cliente reestablezca su conexión con la red de área local, pueda recuperar la información de las operaciones inconclusas que quedaron en el momento de la desconexión.
Capitulo I
Para que el cliente esté informado del estado de la conexión con el representante, requiere un intermediario que se comunique con el. El intermediario ubicado en el cliente se denomina proxy cliente intermediario (mcp: Middleware Client Proxy), el intermediario ubicado en la misma LAN del cliente se denomina proxy servidor intermediario (msp: Middleware Server Proxy). La arquitectura para manejar las desconexiones es una arquitectura con dos intermediarios, el mcp y el msp, y se denomina intermediario con soporte a desconexión (dsm: Disconnection Support Middleware).
En la Fig. 1.1 se muestra de forma general la arquitectura del intermediario con soporte a desconexión. El punto de desconexión dispuesto en la arquitectura propuesta es entre el proxy cliente intermediario y el proxy servidor intermediario.
1.2.2 Manejo de movilidad de clientes y co exiones intermitentes en dis- sitivc móviles para el acceso a la Web 1031
Este proyecto se enfoca a la movilidad de lientes y la conectividad para el acceso a la Web. Se examina el impacto de los dispositi s móviles para el acceso a la Web y se introduce una noción denominada consisten ia delta, junto con dos propuestas denominadas empujón (push) y jalón (puli) para i 1 manejo de técnicas de almacenamiento (buffering) sobre un proxy y la aplicación de algoritmos para el manejo de clientes móviles fuera de línea. I
! Las pruebas experimentales demuestran que las técnicas del empuj6n (push)
satisfacen bien el manejo de las desconexiones del cliente mientras que la técnica del jalón (pull) satisface el manejo de la movilidad del cliente (Fig. 1.2).
Se toma en cuenta que el cliente puede desconectarse en cualquier momento y en ese punto, el proxy y el servidor no pueden ser accedidos, por lo que no puede actualizarse la información. Para solucionar esto, se deben tomar medidas oportunas para las desconexiones del cliente.
i
Aquí se observa que el proxy y el servidor sobre la red cableada pueden continuar recibiendo actualizaciones durante las desconexiones de los clientes, por io que se requiere de: 1) Técnicas para el descubrimiento oportuno de desconexiones y 2) Técnicas de sincronización para el cliente.
Como puede observarse, se hace uso de proxys intermedios. donde el cliente envía demandas al proxy; el proxy y el servidor se comunican a través de una red cableada, mientras que el proxy y el cliente se comunican sobre una red inalámbrica que puede ser una 802.1 1 I o GSM'.
!
En esta investigación se obtuvieron tres importantes aportaciones:
1. Se proporcionó una semántica congruente apropiada para que los datos dinámicos sean accedidos desde ambientes visuales.
2. La técnica del empujón (push) para reducir la problemática de desconexiones del cliente.
3. La técnica del jalón (pull) Para proporcionar las garantías necesarias que igualen a una conexión persistente.
PYll aandri p w
al Modelo del sistema
3. estado del cliente
5. peticiones subslguientes cliente
b) Mecanismo de deiconexlón
4. redirecclonaraproxy:
Fig. 1.2 Modelo del sistema y mecanismo de desconexiónpara clientes tnóviles
1.2.3 Middleware para acceso a la información móvil 1041
El acceso de información móvil involucra la recuperación de información de los proveedores de servicio de la red. Hay a menudo situaciones donde la información no está disponible en un solo proveedor de servicio, pero puede ser resuelto combinando
' 802.11. Estándares para redes inalámbricas ' GSM Sistema Globalpara comunicaciones Móviles '
-5-
NOMBRE DEL TEMA SOPORTE EN MANEJO SOPORTE MODO DE PROTOCOLOS
DESCONEXIÓN' CACHING HTTP Gestor de desconexión y SI NO SI reconexión para sistemas cliente/servidor móviles.
información de múltiples proveedores de servicio. En este articulo se describe un middleware para apoyar este modo de acceso a recursos con dispositivos móviles de capacidad limitada, que toman en cuenta la movilidad, restricciones de recursos y heterogeneidad de servicio (Fig. 1.3).
SOPORTE A CACHÉS
JE RÁ R Q U I c A s NO
Fig. 1.3 Obiención de información de dferentes proveedores de ISP
Manejo de movilidad de clientes y conexiones intermitentes en dispositivos móviles para el acceso a la Web. Middleware para acceso a la información móvil.
Tabla 1. I comparativa entre el servidor con soporte a desconexiones y otras aplicaciones.
SI NO SI NO
1.3 OBJETIVO GENERAL
El objetivo general de este trabajo de tesis es implementar el modelo de interacción asíncrono no interactivo para proporcionar soporte a operaciones en modo desconexión en redes inalámbricas y cableadas. El proxy detectará cuando un cliente pierde la conexión de manera voluntaria o involuntaria, garantizando la continuidad de las peticiones en Internet a pesar de las desconexiones, habilitando los mecanismos necesarios que permitan continuar con la transferencia de información.
1.4 PROPUESTA DE SOLUCIÓN Y METODOLOGíA
Primero describiremos el proyecto global MoviWare (OS] para el diseño de servicios de soporte a cómputo móvil, el cual está conformado de varios elementos que se describen a continuación (Fig. 1.4):
Gestor de desconexión y reconexión. Este componente se encarga de gestionar y procesar los eventos de desconexión que se pueden presentar de manera voluntaria, esto es, si el cliente solicita desconectarse explícitamente. Desconexión involuntaria, cuando el cliente se desconecta sin previo aviso como resultado de las constantes desconexiones propias de ambientes inalámbncos.
Generador de pairones de acceso a recursos informáticos. Estos componentes utilizan mecanismos de minería de reglas de asociación para extraer patrones de acceso. Se han implementado tres algoritmos, los patrones generados con estos mineros son clasificados y colocados en un contenedor que permite su recuperación de acuerdo a criterios de selección que el gestor de acaparamiento determina.
Gestor de acaparamiento de recursos informáticos. Los componentes del gestor tienen la función de interpretar el perfil de conducta de los usuarios móviles para poder identificar el patrón de acceso que permita precargar los recursos informáticos que el patrón indica. También proporciona servicios para el procesamiento de los recursos acaparados en modo desconexión.
Gestor de contenidos Web. Este componente se encarga de devolver recursos Web a dispositivos móviles atendiendo a las características particulares de esos dispositivos. Por ejemplo, una página Web la cual es llamada por una computadora
I
-8-
I
Fig. 1.5 Alineación de componenies y servicios
ALCANCES. I Análisis de la arquitectura del proxy caché Squid. I
Primero se realizará un análisis detallado de la arquitectura del proxy caché Squid. El análisis se centrará en la obtención e integración de módulos de código fuente, su relación entre cada uno de ellos, así como el uso de protocolos de comunicación, técnicas de almacenamiento (caching) y técnicas de programación. Posteriormente se trazará un mapeo de peticiones y funcionamiento interno del Squid, esto con el propósito de obtener una metodología probada para el proceso de atención a los clientes y una arquitectura ad hoc con el proxy caché Squid.
Se diseñará el soporte para el modelo asíncrono no interactivo. Este diseño deberá aplicar técnicas de programación que permita la continuidad de las peticiones. Esta arquitectura hará uso de los servicios del proxy caché Squid sin afectar el funcionamiento normal, por lo que es importante que la selección de esta arquitectura que será integrada se acople sin afectar procesos internos. La programación del prototipo se realizará en lenguaje C para Linux.
El desarrollo de una metodologia es considerada como punto principal para poder garantizar las transacciones de los protocolos HTTP [O71 y FTP [OS] sobre HTTP para clientes móviles.
Con estos trabajos se estará dando soporte al modelo asíncrono no interactivo y a desconexiones no previstas, para lo cual el diseño deberá incluir un control de avance de las operaciones de tal forma que al detectar una reconexión se restablezca automáticamente la transmisión de datos.
1.5 ALCANCES Y LIMITACIONES.
Los alcances y limitaciones de esta tesis se enlistan a continuación:
inexión. ITACr0NW.S.
icolos HTTP. ILosrotocolos como Telnet no serán soportados por operaciones en modo desconexión.
Capítulo I
1.6 BENEFICIOS
Con el desarrollo de un servidor proxy caché con soporte para operaciones en modo desconexión en redes inalámbricas se obtendrán los siguientes beneficios:
Los usuarios de equipos móviles tendrán la opción de realizar sus consultas en modo asíncrono no intetactiv? delegando las peticiones al proxy lado servidor mientras realizan otras tareas, ahorrándose tiempo de conexión.
Los usuarios de equipos móviles, así como también los usuarios de equipos fijos, tendrán la ventaja de que en caso de desconexión por interferencia, desconexión voluntaria o desconexión física accidental, sus peticiones seguirán en proceso.
Se dará soporte de desconexión a operaciones HTTP
El sistema desarrollado hará uso del proxy caché Squid para dar soporte a caching de páginas Web centralizadas y distribuidas.
, .
1.7 ORGANIZACI~N DEL DOCUMENTO
El documento de tesis está organizado en siete capítulos, en cada uno de ellos se describe la parte correspondiente a cado uno de los trabajos realizados durante el desarrollo de esta tesis.
Capítulo 1. Se presenta una introducción del desarrollo de la investigación, abordando la problemática, los modelos de interacción síncrono y asíncrono, estado del arte, el objetivo general, la propuesta de solución y los alcances y limitaciones.
Capítulo 2. Aquí se definen los conocimientos y tecnologías que se utilizaron a lo largo del desarrollo de la tesis, también se incluyen parte de la terminología utilizada.
Capitulo 3. En este capítulo se describe el análisis de requerimientos de software y los casos de uso necesarios para la implementación del prototipo.
Capítulo 4. En este capítulo se describe el análisis correspondiente a la solución conceptual del problema, es decir, el diseño de la solución para el soporte al modelo de interacción asíncrono no interactivo. i
Capítulo 5. Aquí mostramos la arquitectura diseñada, donde mostramos los diferentes componentes y su relación entre sí, explicando además la definición de las
-10-
I
estructuras de datos a nivel programación.
Capítulo 6 . En este capítulo hacemos m a evaluación del sistema basado en un plan de pruebas para comprobar la estabilidad del sistema desarrollado.
Capítulo 7. Finalmente se presentan las conclusiones y trabajos futuros que se pueden desarrollar posteriormente sobre esta línea de investigación.
- 1 I .
Capitulo I1
CAPÍTULO 2
MARCO TEÓRICO Los conceptos básicos de esta tesis/ son presentados en este capítulo, el uso
eficiente de conexiones son la base fundpmental para el desarrollo de esta tesis. Presentamos las definiciones y conceptos ,a nivel de programación y técnicas más utilizadas para la construcción de servidores concurrentes y monoprocesos para la atención de clientes. Así también mostramos la tecnología de redes inalárnbricas, cableadas y el protocolo HTTP. I
Capitulo I1
2.1 TCPllP EN UNIX
L ~ S beneficios derivados del uso del sistema operativo UNIX provienen de Su potencia y flexibilidad. Una caracteristica fundamental es el manejo de procesos y su capacidad para comunicarse, los procesos pueden comunicarse entre ellos en la misma máquina o en diferentes máquinas, mediante una infraestmctura que permita la comunicación entre los procesos 1091.
2.1.1 Procesos y descriptores en UNIX
Un proceso en UNIX es un programa en ejecución, el sistema operativo gestiona el programa que está ejecutando, el espacio de memoria que ocupan sus variables e información diversa. Entre esta información se encuentra el id o identificador de proceso, que lo identifica de manera única de los demás procesos, por ejemplo, dos procesos que corren en una misma computadora, no comparten el espacio de memoria ni su información de estado, aunque si podrían compartir el mismo código.
Un proceso puede generar otros procesos, llamados procesos hijo, mediante la llamada aforkf). Cuando un proceso es creado, éste es virtualmente idéntico al padre, como a continuación se indica:
Padre e hijo ejecutan el mismo código, también puede ser que compartan una única copia en memoria o que sean totalmente independientes. . El proceso hijo tiene exactamente las mismas variables y valores del padre, sin embargo, lo que hereda es una copia, de ahí en adelante cada uno cambiará los valores por separado. Se crea para el hijo un bloque de información de estado, casi idéntico al del padre ya que cada uno tiene identificadores diferentes.
Los procesos pueden comunicarse con procesos locales o remotos, al ejecutar operaciones de E/S (entradalsalida) para acceder a archivos, dispositivos u operaciones de comunicación entre procesos (PC, inter Process Communications). Los P C tienen mecanismos que les permiten comunicarse con procesos dentro de una misma computadora o con procesos que residen en computadoras diferentes, esto es, que utilizan los protocolos de comunicación de capa de red.
Los archivos, dispositivos, tubenas, conexiones, entre otros, comparten un elemento clave que hace posible la comunicación entre ellos. Este identificador es llamado descriptor de objeto de comunicación o comúnmente llamado FD (file descriptor). Cuando un proceso quiere comunicarse genera un FD, que es el resultado de una llamada al sistema para crearlo o si ya existe abrirlo, cada proceso mantiene dentro de su información una tabla de descnptores a todos los objetos que puede manipular. Los procesos no utilizan los objetos de comunicación directa, en lugar de ello utilizan un índice a la tabla de descriptores que sirve al sistema para localizar el objeto correspondiente (Fig. 2.1).
Mediante llamadas al sistema de apertura o creación se actualiza la tabla de descriptores y se obtiene un FD nuevo. Usando el FD se hacen llamadas de EIS para leer o escribir información del objeto correspondiente. Usando el FD se realiza una llamada al sistema para cerrar el dispositivo o destruirlo, liberando su referencia en la tabla de descriptores.
-13- , .
. Usando el FD es posible realizar llamadas para obtener información referente al dispositivo señalado o descrito y obtener sus características.
2.1.2 Lectura y escritura a través de descriptores
Las operaciones de lectura y escritura están basadas en dos funciones read0 y write0 [ I O ] , el FD (file descriptor), indica a través de cuál se realizan las operaciones.
#include <unistdh>
read( int FD, void* buA size-i nbyie); write( in1 FD, const void* buJ size-! nbyie);
bufindica destino y fuente de los datos para read y write respectivamente, nbyre indica el número de octetos a leer o escribir, que normalmente es el tamaño de buf; las operaciones deben tener cierto grado de sincronización y un análisis de los valores devueltos a las llamadas read# y write#. Típicamente read0 se comporta en forma bloqueante, ya que el proceso que realiza la llamada se mantiene en espera hasta recibir datos, los valores a ser analizados son los siguientes:
Si el resultado es negativo, indica que se ha producido un error, la variable global errno indica el error. Si es resultado es igual a cero, no se ha producido ningún error, al leer O octetos indica que se ha leído el final del flujo de datos, normalmente indicado por un fin de archivo o cierre de la conexión. Si el resultado es mayor que cero, entonces se han leídos octetos con éxito, el número viene dado con nbyie.
Para el caso de wrifeo, es poco probable que quede bloqueado, al menos que la cola de encaminamiento esté llena y tenga que esperar espacio. El resultado generalmente es el número de bytes escritos. En algunos casos, cuando el número de flujo es demasiado grande, el número devuelto es menor que lo especificado en nbyte y es necesario más de una llamada a wriieo para completar la transferencia.
Los errores de las operaciones pueden ser referenciados en la variable errno y puede asociarse a la función perror0 para notificar un diagnóstico que el sistema complementa.
#include <sidio.h>
2.2 SERVIDORES CONCURRENTES
La función de un servidor es realizar las operaciones necesarias para atender a sus clientes; dependiendo del tipo de servidor y nietodologia implementada. A continuación detallamos tres tipos de ellos, todos orientados a conexión.
2.2.1 Conexiones simultáneas
Un servidor TCP de flujo interactivo 1111 se usa para transferir información a lo largo de una conexión TCP. Sin embargo, en un momento dado podrían existir, entre las computadoras de origen y destino, múltiples conexiones ocurriendo simultáneamente, esto es especialmente Útil para servidores concurrentes.
2.2.2 Servidores multiproceso y multihilado
La altemativa en los servidores concurrentes consiste en diseñar un servidor multiproceso, de tal forma que el servidor mantiene constantemente un proceso asignado al puerto de escucha. En cuanto se establece una conexión, el servidor realiza un fork0 y crea un proceso hijo que se dedica en forma exclusiva a atender las peticiones del cliente mediante la conexión de diálogo. Mientras esto sucede, el proceso padre sigue atendiendo al puerto de escucha, ignorando los diálogos de los hijos y creando tantos procesos hijos como sea necesario.
El diseño es funcional, siempre y cuando los procesos hijos no necesiten compartir información, puesto que cada uno de ellos se ejecuta en espacios de memoria separados. En el caso de que el sistema operativo soporte multihilos, el servidor puede ser multihilado y la limitación desaparece, debido a que diferentes hilos pueden compartir variables.
El diseño de un servidor multiproceso tiene una variante muy importante con respecto a la implementación de un servidor interactivo, el uso de un ciclo asegura permanentemente la atención al puerto de escucha, en cada interacción, luego del accept() el servidor queda en estado de espera. Cuando el cliente intenta conectarse, accept() retorna con un nuevo descriptor de conexión, pero antes de comenzar la transferencia de datos, el servidor realiza unforkl), apareciendo en memoria un proceso hijo igual que el servidor, que sólo se dedica a realizar la transferencia de datos con el cliente, mientras que el proceso padre retorna al estado en espera; de esta forma el servidor puede atender a vanos clientes en forma simultánea, por cada cliente que está atendiendo en forma simultánea, aparecerá un proceso hijo ejecutándose,
2.2.3 Servidores monoproceso
No siempre es aplicable una solución multiproceso ai diseño de servidores concurrentes, el principal problema a resolver es cómo gestionar un conjunto de conexiones sobre los cuales realizar operaciones de escritura y lectura en forma simultanea. Si las operaciones de E/S son bloqueantes, puede ocurrir que un proceso se bloquee intentando leer de una conexión sin datos, el resultado es tal que, mientras está bloqueado, no atiende a las otras conexiones aunque están activas. Por el contrario, si las operaciones de E/S son no bloqueantes, el proceso puede atender múltiples conexiones al realizar iteraciones constantemente, mirando que conexiones tienen datos y leyendo de ellas, esta técnica se denomina método por encuesta (poll).
Capitulo I I
Cuando creamos una conexión, se establece como bloqueante, al llamar a ciertas funciones como accept(), recvo, recvfrom0, etc., se bloquea el programa. Para establecer la conexión como no bloqueante utilizamos la funciónfcntlo de la siguiente manera.
intfcntl (in1 socket fd, in! cmd, long arg);
Donde socketfd es el descriptor de conexión sobre el cual se va a realizar alguna operación; cmd determina el comando que se va a aplicar, para nuestro caso usaremos el comando F-SETFL, el cual establece las banderas del descriptor al valor especificado en arg; y arg son argumentos que necesita el comando, para establecer la conexión como no bloqueante sera O-NONBLOCK. Si se produce un error, retorna -1 y se establece errno especificando el error.
socket fd=socket(AF-INET, SOCKET STREAM, O); fcnll (socket fd, F-SETFL, O-NONBL8CK);
Una vez establecido la conexión como no bloqueante, se puede llamar a las funciones bloqueantes como recvo para recibir datos. Si no hay datos disponibles recv() devuelve -1 y establece errno=EWOULDBLOCK.
Función selecto. Nos permite monitorear un conjunto de descnptores de conexiones y nos avisa cuáles tienen datos para leer, cuáles están listos para escribir, y cuáles generaron excepciones.
int select ( in! n, fd-set *readfds, fd-set *writefds, f d set *except$dss, struct limeval *timeout);
Donde n es el número de descriptor más alto de cualquiera de los 3 conjuntos
-
más uno.
fimeoul permite al selecto retornar por dos causas, se produce algún cambio en un descriptor o se excedió más del tiempo especificado en fimeout sin producirse cambios. Si se establece timeout a cero se retorna inmediatamente, si establecemos fimeout a NULL se monitorea hasta que se produce algún cambio en los conjuntos, es decir, que puede bloquearse. Cuando retorna, fimeout indica el tiempo remanente, también modifica los conjuntos de descriptores reflejando cuál de los descnptores está listo para leer, cuáles para escribir y cuáles causaron excepciones, aquellos conjuntos que no tienen descriptores, se especifican con NULL.
Se proveen 4 macros para manejar los conjuntos de descriptores:
FD-Z&RO (fd-set *set ). Limpia un conjunto de descriptores
Capiiulo 11
FD-SET (intfd, fd-set *set). Agrega un FD a un conjunto. FD CLR (intfdJd-set *set ). Borra FD de un conjunto. FD-ISSET - (intfd,fd-set *ser). Verifica si un FD está dentro de un conjunto
alternativa al uso de seleclo es pol/(), la cual ofrece una funcionalidad similar, el prototipo es el siguiente:
#include <poll.h> int poll(struct pollfd fds[], nfds-t nfds, int timeout);
poll() es una variaci6n de selecto. Especifica un vector de nfds estructuras del tipo:
stmct pollfd { int fd; I* Descriptor de archivo */
short events; /* Eventos solicitados *i short revents; /* Eventos ocurridos */
1; y un tiempo límite timeout en milisegundos. Un valor negativo indica un tiempo infinito. El campofd contiene el descriptor de archivo de un archivo abierto. El campo events es un parámetro de entrada, una máscara de bits que especifica los eventos en los que la aplicación está interesada. El campo revents es un parámetro de salida, completado por el núcleo con los eventos que han ocurrido realmente, bien del tipo solicitado o bien de uno de los tipos POLLERR, POLLHUP o POLLNVAL. (Estos tres bits carecen de significado en el campo events y se pondrán a 1 en el campo revents en el momento en que la condición correspondiente sea cierta). Si no se ha producido ninguno de los eventos solicitados (y ningún error) para ninguno de los descnptores de archivo, el núcleo espera durante timeout milisegundos a que se produzca uno de estos eventos. Los bits posibles en estas máscaras están definidos en <sys/poll.h>:
#define POLLIN Ox0001 I* Hay datos que leer */ #define POLLPRI 0x0002 /* Hay datos urgentes que leer */ #define POLLOUT Ox0004 /* La escritura ahora será no bloqueante */ #define POLLERR 0x0008 /* Condición de error */ #define POLLHUP OxOOlO /* Colgado */ #define POLLNVAL 0x0020 /* Petición invá1ida:fdno está abierto */
Valor devuelto. En caso de éxito, se devuelve un número positivo que indica el número de estmcturas cuyo campo revents tiene un valor distinto de cero (en otras palabras, aquellos descriptores para los que se ha producido un evento o un error). Un valor O indica que se ha cumplido el tiempo límite (timeout) de la llamada y que no se ha seleccionado ningún descriptor de archivo. En caso de error, se devuelve - I y se asigna a errno un valor apropiado.
2.3 EL MODELO DE INTERACCIÓN ASiNCRONO NO INTERACTIVO
El modelo de interacción asincrono es la base del desarrollo de esta tesis (Fig. 2.2). Este modelo está formado por tres capas (cliente, proxy intermediario y servidor) las cuales permiten al cliente desconectarse durante la transmisión de los datos. La secuencia del funcionamiento del modelo de interacción asincrono es la siguiente:
Capitulo 11
El cliente envla una solicitud dk datos al proxy. El proxy devuelve un acuse delrecibido y reenvía la solicitud al servidor. El cliente se desconecta de la red. El proxy recupera la información del servidor. Cuando el cliente se reconecta, solicita la información del estado de la solicitud. Si la solicitud se ha completado, el proxy devuelve los datos al cliente, en caso contrario informa al cliente que aún no se ha completado la solicitud.
[ solicitud
Fig. 2.2 Modelo de inieracción mincrona
El proxy representante debe estar ubicado de manera tal que nos permita obtener de forma confiable y rápida la información después de una desconexión, por lo que el lugar ideal para ubicar al proxy es en el dominio del cliente, dentro de la misma red de área local (LAN).
2.4 EL PROTOCOLO HTTP
El protocolo de transferencia de hipertexto (Hypertext Transfer Protocol) es un protocolo cliente/servidor sencillo que coordina los intercambios de información entre los clientes provistos de un navegador Web y los servidores HTTP. La especificación completa de los protocolos HTTP 1.0 y HTTP 1.1, están en el RFC (Request For Comments) 1945 [I21 y F J C 2616 I131 respectivamente. Desde el punto de vista de las comunicaciones, está soportado sobre los servicios de conexión TCPLP, y funciona de la misma forma que el resto de los servicios comunes de los entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el SO), y espera las solicitudes de conexión de los clientes Web. Una vez que se establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores. HTTF' se basa en sencillas operaciones solicitudrespuesta. Un cliente establece una conexión con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto Web (documento HTML, archivo multimedia o aplicación CGI) es conocido por su URL (Universal Resource Locator).
l b .
Los recursos u objetos que actúan como entrada o salida de un comando HTTP están clasificados por su descripción MIME'.
I
I
De esta forma, el protocolo puede intercambiar cualquier tipo de dato, sin Dreocuoarse de su contenido y la identificación MIME penhitirá que el receptor trate adecuadamente los datos.
2.4.1 Etapas de una transacción HTTP
Cada vez que un cliente realiza una petición a un servidor, se ejecutan 10s
1. Un usuario accede a una página Web seleccionando el enlace de un documento HTML o introduciéndola directamente en el campo dirección del navegador Web.
2. El navegador Web decodifica la URL, separando sus diferentes partes. Así identifica el protocolo de acceso, la dirección DNS (Domain Name System) o IP del servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor.
3. Se abre una conexión TCPRP con el servidor, llamando al puerto TCP correspondiente.
4. Se realiza la petición. Para ello, se envia el comando necesario (GET, POST, HEAD,. . .), la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada (HTTP 1.0 o 1.1) y un conjunto variable de información, que incluye datos sobre las capacidades del navegador (browser) y datos opcionales para el servidor.
5. El servidor devuelve la respuesta al cliente. Esta consiste en un código de estado y el tipo de dato MIME' de la información de retorno, seguido de la propia información.
6 . Se cierra la conexión TCP.
siguientes pasos:
Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se pide una página Web que contiene 4 imágenes, el proceso anterior se repite hasta completar 5 veces, una para el documento HTML y cuatro para las imágenes.
En la actualidad el uso del protocolo HTTP 1.1 permite que una misma conexión se mantenga activa durante un cierto periodo de tiempo, de forma que sea utilizada en sucesivas transacciones. Este mecanismo, denominado Keep Alive, es empleado por la mayoría de los clientes y servidores modernos. Esta mejora es imprescindible en un Internet saturado, en la que el establecimiento de cada nueva conexión es un proceso lento y costoso.
I
' MIME. (Multipuipose Internet Mail Extensions). Es el método estándar para adjuntar archivos que no son tipo texto a mensajes de correo electrónico de Internet.
-19-
I
2.4.2. Conexiones Keep-Alive
La extensión de HTTP KeepLAlive, hace posible las conexiones persistentes. Estas sesiones HTTP de larga vida permiten enviar múltiples peticiones sobre la misma conexión TCP. En algunos casos se han obtenido resultados de casi el 50% de mejora en velocidad en tiempos de latencia para documentos en HTML con muchas imágenes.
Para usar el Keep-Alive, antes que nada, el navegador debe soportarlo, las versiones actuales de Netscape, Mozilla e Internet explorer los soportan. Su funcionamiento básico entre el navegador y el servidor Web se describe a continuación.
Una conexión con el cliente es persistente si el servidor no cierra la conexión esperando otra petición del cliente. El comportamiento del servidor respecto a la persistencia de las conexiones seguirá estas reglas:
Siempre que se detecte un error de sintaxis en la petición se cenará la conexión con el cliente (después de enviar el correspondiente mensaje de error).
Peticiones HTTPí1.0. Si la petición no incluye una cabecera Connection: Keep- Alive, el servidor cerrará la conexión con el cliente tras mandar la respuesta. Si la petición incluye dicha cabecera, no se cerrara la conexión. Si no la incluye, la conexión se mantendrá abierta.
Peticiones HTTPI1.1. Si la petición no incluye una cabecera Connection: Close, el servidor no cerrará la conexión con el cliente:
.
La instalación de un servidor Web, trae por defecto desactivada esta opción, ya que las conexiones persistentes Keep-Alive suponen un nesga muy común ai intentar provocar una negación de servicio (deny of service DOS), realizando peticiones hasta que el servidor no pueda atenderlas. Esto se logra realizando peticiones con una cabecera de paquetes falsa y poniendo una dirección IP inexistente, con lo cual el servidor mandará paquetes a una dirección que no existe y se quedará esperando una respuesta que nunca recibirá.
Si se hacen suficientes peticiones llegará un momento en que todas las peticiones que esté atendiendo el servidor serán falsas, las peticiones legitimas no serán atendidas, y si no se pone una condición para terminar las conexiones, el servidor Web quedara bloqueado.
-20-
ESPECIFICACI~N DE REQUERIMIENTOS Y CASOS DE USO
En este capítulo especificamos los requerimientos de ingeniería de software [14] que debe cumplir el prototipo denominado “servidor proxy caché con soporte a operaciones en redes inalárnbricas”, así como los casos de uso [ 151.
CENTRO DE INFORMACION SEP CENIDET I
-2 1
i I
Capitulo 111
3.1 ÁMBITO
El producto de software que se describe en esta sección, se puede clasificar como una aplicación destinada a realizar peticiones HTTP. Estas peticiones son realizadas por un navegador Web que soporte configuración hacia un proxy.
3.1.1 Perspectiva del Producto
Tomando como referencia la descripción del problema y el objetivo de la tesis planteada en el capítulo 1; se requiere la implementación de dos proxys que den soporte a desconexiones y den continuidad a las peticiones para su posterior recuperación.
3.1.2 Funciones del Prototipo
El prototipo con soporte a desconexiones deberá realizar las funciones básicas para el manejo de peticiones tanto para el proxy lado cliente como para el proxy lado servidor (Fig. 3.1):
Para el proxy lado cliente se tienen los siguientes requerimientos:
1. 2. 3. 4. 5.
Recepción del cliente (navegador) y envió de petición al proxy lado servidor. Recepción y almacenamiento de la página HTML y objetos del proxy lado servidor. Devolución de página y objetos al cliente (Navegador). Construcción y devolución de páginas de estado en caso de desconexión. Monitoreo de conexiones.
PUNTO DE
Acceso eableado
Fig. 3. I Diagrama general sislema con soporte a desconexiones
Para el proxy lado servidor:
1 . Recepción y gestión de peticiones al proxy cache Squid. 2. Análisis @aseo) del código fuente en busca de los objetos contenidos. 3. Petición y almacenamiento de los objetos.
-22.
I
I
4. Transferencia de objetos al proxy lado cliente. 5. Redireccionamiento de páginas al recuperarse de una desconexión. 6 . Monitoreo de conexiones. 7. Construcción y devolución de páginas Web en caso de desconexión 8. Registro de eventos de desconexión.
3.2 DESCRIPCIÓN DE LAS FUNCIONES
Los usuarios interactuarán con el sistema mediante un navegador, en este caso una computadora portátil o una computadora ' de escritorio. Esta solicita un URL correspondiente a una página Web. Los componentes lado cliente y lado servidor se coordinan para poder procesar las peticiones que tiene por finalidad mostrar a los usuarios solicitantes las páginas y a su vez brindan soporte a eventos de desconexión y errores enconbados a lo largo del todo el proceso.
3.2.1 El proxy lado cliente
El proxy lado cliente coordina peticiones entre al navegador Web y el proxy lado servidor. A continuación describiremos los requerimientos.
3.2.1.1 Recepción y envió de petición al lado servidor
Al gestionarse una petición HTTP, el navegador la envía hacia el proxy lado cliente. Para esto, es necesario implementar un servicio de atención a clientes que maneje las conexiones entre el navegador Web y el proxy lado servidor.
3.2.1.2 Recepción, almacenamiento de páginas HTML y objetos del proxy lado servidor
Una vez enviada la petición, ésta es procesada por el proxy lado servidor mientras mantiene a la espera al navegador Web y queda en espera de recibir la información. Una vez que se recibe la notificación para empezar a recibir datos, se implementan listas dinámicas para asegurar la recepción de las páginas y los objetos referenciados, así, una vez terminado, se prepara para empezar a enviar al navegador Web la página solicitada.
3.2.1.3 Devolución de página y objetos al cliente (Navegador).
Para el navegador Web es transparente el proceso de peticiones de paginas, el único conocimiento que el tiene al respecto es que se está usando un proxy para realizar las peticiones y debe ajustarse a ello, por tal razón, una vez recibida la página HTML, éste procede al análisis de la página en busca de objetos referenciados, y gestiona las conexiones para pedir los objetos referenciados. Así el proxy lado cliente recibe las peticiones e implementa una búsqueda en la lista de objetos recibidos del proxy lado servidor para esa petición en curso, una vez localizado, es remitido hacia el navegador, en caso de no encontrarse, devuelve una página de no localizado.
-23-
I
Capitulo 111
3.2.1.4 Construcción y devolución de páginas de estado en caso de desconexión
. . Durante el proceso de gestión de peticiones, pueden ocurrir errores de conexión o
puede presentarse un evento de desconexión, en ambos casos, el proxy lado cliente cuenta con funciones que le permiten determinar e1,tipo de error, y en base a ello, construye una página HTML conteniendo una descripción de la situación. Dicha página es remitida hacia el navegador Web y puede contener un enlace o un código de javascript que le permitirá al usuario tratar de solucionar la situación.
3.2.1.5. Soporte a desconexiones (Monitoreo de conexiones)
El monitoreo de conexiones tiene que ver con las desconexiones, es decir, durante el tiempo que se mantiene en espera ai navegador Web, antes de recibir la notificación de datos listos, se espera un tiempo aproximado de tres segundos. Si en ese tiempo no se recibe notificación alguna, se procede a enviar un mensaje al proxy lado cliente, para saber el estado que guarda la petición, si no se puede enviar significa que se ha producido un evento de desconexión, en cuyo caso se procede a notificar al usuario del error.
3.2.2 El proxy lado servidor
El proxy lado servidor coordina peticiones entre el navegador, proxy lado cliente y el proxy caché Squid, a continuación describiremos los requerimientos.
3.2.2.1 Recepción y gestión de peticiones al proxy caché Squid
Una vez recibida la petición por el proxy lado cliente, éste solicita una conexión con el proxy lado servidor. Para esto, es necesario implementar un servicio de atención a clientes que maneje las conexiones entre el navegador, el proxy lado cliente y el proxy cache Squid.
3.2.2.2 Parseo del cbdigo fuente en busca de los objetos contenidos
Una vez gestionada y recibida la solicitud con el proxy caché Squid, éste procede a un análisis del código fuente en busca de los objetos referenciados, para ello hace USO de una lista dinámica, en la cual va agregando los URL de los objetos encontrados y añade las características del navegador, es decir, construye las peticiones como la haría el navegador Web en forma directa, esto debido a que las peticiones las realizará posteriormente de igual
\ forma.
3.2.2.3 Petición y almacenamiento de los objetos
Una vez construido la lista de objetos al proxy caché Squid, se procede a recorrer la lista, al mismo tiempo almacena los objetos recibidos como resultado de enviar y recibir las peticiones ai proxy caché Squid. Una vez terminado se prepara para enviarlas hacia el proxy lado cliente.
-24-
Capitulo 111 I
protocolo HTTP, donde se especifican el nombre del objeto, longitud y tipo, así mismo se monitorea constantemente la conexión para determinar eventos de desconexión. AI final se procede a liberar la lista de memoria.
Error al intentar conectarse al proxy caché Squid. Se determina un error de conexión. Se ha localizado una petición no completada con anterioridad debido a un evento de desconexión.
I
i Estos eventos generan una página Web con información de error.
3.2.2.7 Control y registro de eventos de desconexión para recuperación posterior
Adicional al evento de desconexión, se requiere gestionar una entrada en la lista de desconexiones, donde se almacenará la IP desde donde se hizo la solicitud, el URL, el puerto, la fecha y la hora. Esta información es esencial para habilitar la recuperación posterior.
3.2.2.8 Redireccionamiento de páginas ai recuperarse de una desconexión I
Cuando se recibe una petición, ésta es inmediatamente buscada en la lista de desconexiones, si se encuentra una entrada, se procede a construir una página Web con un código para redireccionar hacia la petición no completada.
I 3.3 CASOS DE USO 1
Para el Óptimo funcionamiento del sistema, se han identificado los siguientes casos de uso, que son simplemente descripciones textuales de la interacción que tiene lugar entre un agente externo o actor (que puede ser el usuario o un sistema determinado) y la
-25-
Capitulo 111
Sprvidnr prosy r x h r i'en soporle a oprrarionrs en Modo Uesroneiión rn rrdhs iiirlaiiibriras.
aplicación (o componentes) que se está diseñando. Los actores también pueden ser servicios, componentes y usuarios, entre otros. A continuación mostramos los casos de uso requeridos para la implementación del sistema (Fig. 3.2).
Prosy Vdl'hF
o
Xarrgadar U'eli I \ /I
Fip 3 2 Casos de uso requeridos paro la implemenfacidn del profofipo
3.3.1 Visualiza páginas Web sin desconexión
Cuando el cliente, en este caso una computadora portátil o una computadora de escritorio, solicita el URL correspondiente a una página, ésta es enviada hacia el proxy lado cliente, el proxy lado cliente la gestiona con el proxy lado servidor. Para ello requiere de la recepción y envió, así como la implementación del soporte a desconexiones.
El proxy lado servidor gestiona la solicitud con el proxy caché Squid y devuelve una página Web de confirmación al navegador Web, para ello requiere de la recepción y envió, así como el soporte a desconexiones. La petición es tomada por el proxy caché Squid y gestionada al servidor Web correspondiente.
El proxy lado servidor recibe la respuesta del proxy caché Squid y utiliza un control para la lista de almacenamiento, para ello requiere realizar un parseo en busca de los objetos contenidos, que posteriormente son solicitados al proxy caché Squid. Los objetos recibidos, requieren de la recepción y almacenamiento. Una vez terminado son enviados al proxy lado cliente (Fig. 3.3).
-26-
I
Fig. 3.3 Caso de uso para visualizar Páginas Web sin desconexión
I-? Swviilnr \'di
3.3.2 Visualiza error de conexión con el proxy lado servidor
Para este caso, observemos cómo el proxy lado cliente la gestiona con el proxy lado servidor (Fig. 3.4).
Fig. 3.4 Caso de usopara visualizar error de conexión con elproxy lado servidor
-21.
Capítulo Ill
El proxy lado servidor no puede completar la conexión, debido a que el proxy lado servidor no está en ejecución. Para ello requiere de la recepción y envío, así como la implementación del soporte a desconexiones, por lo que se gestiona un error de conexión; para ello requiere de la construcción de una página indicando el error. Esta página es enviada al navegador Web para su visualización.
3.3.3 Visualiza error de conexión con el proxy caché Squid
Para este caso, observemos cómo el proxy lado servidor gestiona la solicitud con el proxy caché Squid, pero no puede completar la conexión, debido a que el proxy caché Squid no está en ejecución; para ello requiere de la recepción y envío, así como la implementación del soporte a desconexiones, por lo que se gestiona un error de conexión; para ello requiere de la construcción de una página indicando el error, esta página es enviada al proxy lado cliente, que a SU vez la envía ai navegador Web para su visualización (Fig. 3.5).
Prosy lado Clicnir
c!.$&? ->Y
Consiriiir Rccepcionar y páginas de almacenar de eslado páginas IIThI1
P r o x y lado Servidor
Ileccycionar y geslionar con
Consiruir páginas (Ir eslado
I' L Prow cathc Soiiid
d
Fig. 3.5 Caso de usopara visualiza error de conexión con elproxy cache Squid
3.3.4 Visualiza, determina y controla eventos de desconexión
Los requerimientos previos son idénticos a los establecidos en 3.3.1, hasta el punto donde intenta enviar la página Web con sus respectivos objetos al proxy lado cliente.
-28-
Capitulo 111
Cuando ocurre un evento de desconexión, el proxy lado cliente y el proxy lado servidor realizan funciones distintas para su tratamiento, como a continuación se indica.
Proxy lado servidor. AI intentar enviar la información al proxy lado cliente, no puede completar la transferencia debido a que se ha presentado un evento de desconexión, se procede a crear una entrada con los datos de la petición fallida para su posterior recuperación, para ello impiementa funciones asociadas a la gestión y registro de eventos de desconexión.
Proxy lado cliente. El proxy lado cliente ha esperado un tiempo razonable de tres segundos y no ha recibido respuesta, se procede a enviar un mensaje ai proxy lado servidor, para saber el estado que guarda la petición, en la mayoría de los casos, el proxy responde indicando que aún no se ha completado, pero cuando ocurre un evento de desconexión, no recibe respuesta, de esta manera se gestiona un evento de desconexión y se construye una página indicando el error de conexión que es enviado al navegador Web para su visualización (Fig. 3.6).
puede cslalileccr camiinicacián con LI
Fig. 3.6 Caso de uso para visualizar, determinary controlar eventos de desconexión
3.3.5 Visualiza y se recupera de eventos de desconexión
Cuando un cliente ha experimentado una desconexión, inmediatamente después de recibir la notificación como se indicó anteriormente, el navegador Web intenta realizar en
-29-
Proxy Lado Siwidor
Canirol y regislro de Rcdireccionamicnio evenlos Be de páginas. desconexi6n
Fig. 3.7 Caso de usa para visualizar y recuperarse de una desconexión
3.4 USUARIOS DEL SISTEMA
Administrador. Es el encargado de poner en operación el proxy lado cliente, el proxy lado servidor, configurar e inicializar el servidor proxy caché Squid y de configurar los navegadores Web.
Cliente. Se refiere a la persona que hace uso del navegador Web para realizar peticiones HTTP.
-30-
3.5 LIMITACIONES DE SOFTWARE
La implementación del prototipo con soporte ai modelo de interacción ashcrono no interactivo, no está sujeta a ningún entorno de desarrollo de aplicaciones (IDE) en particular. Sin embargo, una buena elección de las herramientas facilitará el desarrollo del producto final. Las herramientas sugeridas son las siguientes:
1
WindowsXP. Redhat Linux 9 basado en el kernel 2.4.
Compilador GNU C para Linux. Compilador GNU C basado en Cygwin para XP. Una IDE (Entorno de Desarrollo Integrado) para Linux. Anjuta o Kdevelop. Una IDE (Entorno de Desarrollo Integrado) para Windows. Kdevelop basado en Cygwin para XP
-31-
ANÁLISIS Y SOLUCI~N CONCEPTUAL DEL PROBLEMA
El problema a resolver en este trabajo de tesis es la comunicación intemmpida entre el cliente y el servidor ai presentarse eventos de desconexión y poder garantizar la continuidad de las peticiones en Internet a pesar de las desconexiones en la red inalámbrica o cableada.
4.1 DESCRIPCI~N DEL PROBLEMA
El esquema de trabajo de las arquitecturas tradicionales de software clienteiservidor no contempla en su modelo de interacción la gestión de eventos de
-32-
I. . .
desconexión como situaciones comunes, por \el contrario los atribuye a fallas de hardware o del medio fisico. Por tal razón, consideramos este modelo inadecuado para ambientes de cómputo móvil. Tradicionalmente, el modelo de interacción clienteiservidor es síncrono (ver Fig. 4.1),'10 cual significa que el cliente y el servidor deben estar en línea para realizar cualquier petición: El cliente generalmente controla la transacción y no mantiene su estado, si. se pres.enta un evento de desconexión, el cliente debe repetir la consulta nuevamente, sin poder recuperar los resultados de la primera transacción.
Fig. 4.1 Modelo de Inleraccíón sincrono
A partir de los trabajos de investigación que se han desarrollado en el laboratorio de sistemas distribuidos del cenidet. se han identificado cinco características de este modelo: 1) requiere de una conexión persistente, 2) si la conexión se pierde, la transacción también, 3) cualquier falla de comunicación es atribuida a la red, 4) su esquema de interacción es consumidor de tiempo por su naturaleza síncrona, y 5) utiliza un protocolo solicitud-respuesta. Estas características son aplicables a equipos de cómputo móvil y fijo, es decir, para equipos que están conectados en forma inalámbrica o cableada.
Los entornos de cómputo móvil (inalámbricos) son los más susceptibles a presentar eventos de desconexión (Fig. 4.2). Para los entornos de cómputo fijo (cableados), aunque son más estables, también están propensos a sufrir eventos de desconexión. Las causas que lo conllevan son diferentes como se indica en el punto 4.1.1.
c'-cw* Solicitud
Frecuentes descnnexiones
-33.
4.1.1 Eventos de desconexión
Los eventos de desconexión pueden presentarse en cualquier momento, los más
0 Para equipos de cómputo móvil aplican los incisos A,B,D,E 0 Para equipos cableados aplican los incisos B,C,E
comunes los identificamos a continuación (Fig. 4.3):
A) Retiro de la tarjeta B) Desconexión de los inalámbrica. equipos del suministro de
energía o falla general.
C) Desconexión del D) Desplazamiento fuera cable de red. del área de cobertura del
punto de acceso.
E) Falla de kernel para atender 'los procesos E/S de las conexiones.
Fig. 4.3. Causas 9ue originan una desconexión
Por lo regular se pueden numerar una gran cantidad de factores que ocasionan eventos de desconexión, con la consecuente pérdida del enlace virtual (enlace entre el programa cliente y el programa servidor). Se probaron todos los casos, a excepción del inciso E), para el cual asumimos que la falla del kernel equivale a una desconexión.
Para este trabajo de tesis, el evento de desconexión que nos interesa es el que se da entre el cliente (cableado o inalámbrico) y el servidor (Fig. 4.4).
Fig. 4.4 Desconexión enire un cliente móvily supunio de acceso, y desconexión entre un cliente cableado
-34-
Capitulo IV
Por ejemplo, un cliente, en este caso un navegador Web, solicita una página a un servidor Web mediante una dirección URL. Una vez que el cliente recibe el archivo HTML que describe el contenido de una página en particular, analiza su código y solicita los objetos referenciados en el archivo. Si durante el proceso de solicitud de los objetos se presenta una desconexión, el cliente no lleva un estado de los objetos que ha recibido, por otro lado el servidor no continúa con la solicitud de los objetos que el cliente no ha solicitado para conformar la página Web, debido a que el servidor no mantiene estado de la transacción que el cliente estaba realizando, ya que los objetos son solicitados por el cliente, lo cual requiere de una conexión persistente que permita obtener todos los objetos contenidos en la página Web. Tal situación presenta el siguiente panorama (Fig. 4.5):
El navegador no puede enviar peticiones HTTP o recibir las respuestas del servidor Web, s