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