Control de Desconexiones Visualizando Páginas Web en Dispositivos Móviles con Windows CE

Control de Desconexiones Visualizando Páginas Web en Dispositivos Móviles Windows CE Juan Carlos Olivares Rojas1, Juan Gabriel González Serna1,2, Azucena Montes Rendón.1 y Víctor Jesús Sosa Sosa1 1

Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet) Cuernavaca, Morelos, México 2 Centro de Investigación en Computación (CIC-IPN), México, D.F. {jcolivares04c, gabriel, amr y vjsosa}@cenidet.edu.mx

RESUMEN Este artículo muestra la forma en que se debe de controlar las desconexiones en dispositivos móviles con sistema operativo Windows CE (Pocket PC, Smartphone), mientras se está trabajando en aplicaciones de red orientadas a conexión, como es el caso de la visualización de páginas en la Web. El objetivo de este proyecto es tener “La Web a un tap (punteo) de distancia” por parte de los usuarios. Todo esto conlleva al control de las desconexiones que se presentan en un ambiente altamente móvil (redes inalámbricas con WiFI y/o Bluetooth). Palabras clave: Desconexión, Bluetooth, Pocket PC, Redes Inalámbricas, Smartphone, WiFi, Windows CE. I INTRODUCCIÓN El sueño de acceder a la información en cualquier momento, en todo lugar y a través de cualquier medio, está siendo posible gracias a la aparición de los dispositivos móviles; dichos dispositivos están popularizándose debido a dos grandes factores: la miniaturización de componentes y el uso de redes inalámbricas.

Actualmente, los dispositivos móviles y más específicamente los dispositivos PDAs, han dejado de ser simples “jugetes electrónicos” para convertirse en verdaderas plataformas de cómputo. La movilidad es el atractivo principal de esta clase de dispositivos, la cual también se convierte en su principal desventaja. Dicha movilidad se ha logrado en gran medida con el empleo de redes inalámbricas como WiFi y Bluetooth. Debido a las características del medio físico de transmisión (ondas de radio), la transmisión en esta clase de redes presenta consideraciones no previstas en esquemas tradicionales de redes; dichas consideraciones se reflejan en desconexiones/reconexiones por parte de los clientes. La mayoría de los protocolos y aplicaciones disponibles a través de una red, necesitan de enlaces confiables y persistentes que en una red inalámbrica no están disponibles; tal es el caso de la Web, la cual es orientada a conexión (recordar que HTTP está basado en TCP y éste es un protocolo orientado a conexión) y si no existen las condiciones idóneas, los recursos no pueden ser visualizados por los clientes. II DESCONEXIONES Por desconexión se entiende la condición que se presenta cuando un equipo móvil es incapaz de comunicarse con algunos o todos los puntos de la red. A pesar del gran auge que han tenido las redes inalámbricas, aun siguen presentando una gran desventaja: son menos confiables que su contraparte cableada. De acuerdo con [1] se estima la tasa de error de las redes -10 cableadas es de una magnitud de 10 por -4 10 de su contraparte inalámbrica, lo que propicia que de cada megabit transmitido, un kilobit será erróneo.

Los principales eventos que producen una desconexión según [2] son los siguientes: 1. El nodo se ha movido 2. Se presenta un traspaso de célula 3. Se ha añadido o removido un dispositivo adaptador de red. 4. La calidad de la señal de radio se ha deteriorado. 5. La batería está perdiendo capacidad. 6. Se ha detectado una nueva red. 7. Se ha detectado una variación en el ancho de banda. Los eventos de desconexión entre otros factores, ocasionan que las redes inalámbricas presenten menor ancho de banda, menor desempeño, poca confiabilidad y mínima seguridad; en conclusión, presentan menos garantías de calidad de servicio (QoS) que las redes de infraestructura cableada, lo cual es crítico en muchas aplicaciones como por ejemplo sistemas basados en la Web o sistemas multimedia. Actualmente se está trabajando en la parte técnica (protocolos, componentes electrónicos, etc.) de las redes inalámbricas; por lo que, en entornos donde existe poca movilidad, el uso de redes inalámbricas es altamente confiable y está creciendo vertiginosamente (e.g. redes inalámbricas caseras). El esquema tradicional de comunicaciones distribuidas (arquitectura cliente/servidor) así como todos los esquemas orientados a conexión presentan las siguientes características: 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. Con el tiempo, se ha podido a preciar que el modelo cliente/servidor en ambientes móviles presenta las siguientes características: Los periodos de desconexión son frecuentes. 1. Están limitados en tiempo de conexión debido a la batería. 2. Los enlaces en ocasiones son caros y poco confiables. Ante estas circunstancias, se hace necesario llevar un control y administración de las transacciones realizadas en un ambiente móvil. Este trabajo se enfoca en la

visualización de páginas Web, ya que se ha comprobado que es el recurso más utilizado en la Internet después del correo electrónico. III ANTECEDENTES El desarrollo de esta propuesta forma parte de un Sistema de Gestión de Acaparamiento en esta clase de dispositivos móviles [3]. Él cual a su vez forma parte del proyecto Moviware [4], cuyo objetivo principal es brindar servicios a equipos móviles que están propensos a frecuentes desconexiones. En [5] se trabajó en una idea similar, con la salvedad de que el desarrollo fue para clientes móviles tradicionales (laptops con interfaces de red inalámbrica); mientras que en el presente trabajo de investigación se está laborando sobre arquitecturas no tradicionales como es el caso de dispositivos móviles con sistema operativo Windows CE. IV METODOLOGÍA DE SOLUCIÓN Un esquema interesante para resolver el problema de las desconexiones cuando se accede a recursos Web, es el acaparamiento de sitios Web. El acaparamiento se basa en la idea de que el espectáculo debe continuar. Si los usuarios no pueden acceder a los datos, los datos deben seguir a los usuarios. Esto es muy similar a la recarga de energía en las baterías de los dispositivos móviles; por lo que en el acaparamiento se habla de “recarga de datos”. Así como un usuario móvil carga su batería y se desconecta de la red eléctrica para trabajar, así del mismo modo un usuario acapara recursos informáticos mientras éste se encuentre conectado a una red inalámbrica, para posteriormente poder visualizar sitios Web sin necesidad de estar conectado. El Acaparamiento de acuerdo con [6], es el proceso de replicación y proceso en desconexión de datos previamente seleccionados y copiados localmente en el cliente móvil. En este trabajo nos enfocamos al desarrollo de un módulo de control de desconexiones, al que se ha denominado GDL (Gestor de Desconexiones Locales), dicho módulo al igual que el GAP (Gestor de Acaparamiento para Pocket PC) está desarrollado en .NET CompactFramework con lenguaje C#, ya que según un estudio realizado con anterioridad [7], es por muchas

razones la mejor herramienta para programar en esta clase de dispositivos. En la Figura 1, se muestra el proceso de obtención de un recurso en la Web a través del sistema que se está desarrollando.

enviarlo al cliente. También realiza transcodificación de contenidos Web en caso de ser necesario (por transcodificación se entiende el proceso de convertir un recurso Web de tal forma que su contenido se adapte a las limitantes de despliegue de cualquier clase de dispositivos [8]). Este Proxy se encuentra actualmente en desarrollo. El monitoreo se aplicó a dispositivos Pocket PC 2000, 2002 y 2003 Second Edition (Windows Mobile); enfocándonos en esta última plataforma, ya que nos permite instalar una consola de línea de comandos y hacer un seguimiento del proceso de monitoreo, tal y como se muestra en la Figura 2.

Figura 1. Diagrama de estado del proceso de obtención de un recurso Web La parte principal de este esquema consiste en los procesos de monitorear la conexión (en el caso de que no se pueda obtener un recurso en línea), así como también la reconexión (en caso de que el sistema este desconectado y se detecte que el medio de comunicación es fiable y haya conexión). Determinar el estado de la conexión no es una tarea sencilla, dado que si determinamos el estado de la conexión de primera mano, podría llevarnos a conclusiones equívocas; por ejemplo, determinar que existe una desconexión cuando el recurso no pudo obtenerse (podría ser que el servidor Web no responda pero la conexión es correcta) o determinar que el dispositivo se encuentra conectado pero la conexión es inestable y en un momento existe conexión y en otros no. Por estos motivos se desarrolló un mecanismo para predecir desconexiones que a continuación se describe. Para el proceso de monitoreo, simplemente verificamos que el Proxy en el lado servidor GAT (Gestor de Acaparamiento y Transcodificador) este funcionando adecuadamente. Dicho intermediario se encarga de obtener el recurso Web acapararlo en el servidor para después

Figura 2. Monitoreo de conexiones en dispositivos móviles PPC 2003 El proceso de monitoreo consistió en determinar de manera aleatoria durante tres segundos el número de peticiones que se podrían realizar (aproximadamente 15 peticiones, en un rango de aproximadamente 200ms por petición). Se eligió este esquema a comparación de monitorear constantemente el desempeño de la red, ya que de esta forma se consumía mucho tiempo de proceso innecesario. En la Tabla 1 se muestran los resultados obtenidos de la prueba al GDL. Tabla 1. Resultados obtenidos de las pruebas. Peticiones Acertadas Fallas Eficiencia 14.98 10.87 4.2 70.54%

El módulo de desconexiones se probó 100 veces obteniéndose un promedio de 14.98 peticiones realizadas en 3 segundos (se determinó este valor ya que si se escoge un valor más pequeño no se puede obtener suficiente información, y si se escoge un valor más grande se pierde tiempo vital para la visualización de recursos), de las cuales 10.87 fueron correctas y 4.2 incorrectas para un 70.54% de eficiencia. En algunos casos probar eventos de desconexión es difícil (e.g. transpaso de células o redes, errores de hardware, instalación en caliente de interfaces de red, etc.) Se simularon desconexiones al apagar/encender el mecanismo GAT, ya que se parte del hecho de que aunque haya conexión y garantías de buena comunicación si no nos podemos comunicar con nuestro intermediario, el sistema se encuentra aislado del mundo exterior dado que no hay salida. El esquema de posibles desconexiones se detalla en la Figura 3

Figura 3. Esquema de desconexiones. En el esquema 1 la desconexión con el GAT se da entre dos equipos móviles que están en una red ad hoc o sin infraestructura. En el esquema 2, la desconexión se da entre un cliente móvil y un cliente fijo; mientras que en el esquema 3, la desconexión se produce entre el dispositivo y su punto de acceso o estación base. De las pruebas realizadas, se obtuvo que el índice de eficiencia es de aproximadamente 70%, además se observó que cuando se presentaban transacciones por debajo del 30% de efectividad, era muy difícil completarlas; es por esto que se escogió este índice para determinar si se presenta una desconexión o no; es decir, se necesitará que el sistema tenga al menos el 30% de eficiencia para determinar que se encuentra conectado, caso contrario, estará desconectado. Una vez probado dicho módulo, éste se agregó al proyecto general. Se pudo observar que no es necesario vigilar el estado de la

conexión de manera continúa, solamente en el caso de que se pida una petición de un recurso Web, dado que los navegadores realizan peticiones de manera explicita por parte de los usuarios.

Figura 4. Eficiencia en el control de desconexiones. En la Figura 5, se muestra la incrustación del módulo de desconexiones en el GAP. En este ejemplo se presenta un error ya que no se pudo obtener un recurso en la Web y se determinar el estado de la conexión. Al estar el estado de la conexión por arriba del 30% el sistema se encuentra en modo conexión. Si el índice hubiese sido inferior al 30% el sistema hubiese pasado a un estado desconectado. En la Figura 6, se puede visualizar la forma en que ocurre una reconexión. Estando el sistema en modo desconexión, este no puede realizar peticiones hacia recursos Web pero el sistema realiza una petición única para determinar si ya existe conexión. En este caso, se escogió que el sistema intentará determinar el estado de la conexión hasta el final, dado que si se intentará realizar una petición en modo desconexión existiría un retardo y una gran probabilidad de que el recurso no se pudiese obtener. Sólo se realiza una petición de reconexión y no un conjunto de peticiones como en el caso de monitorear la conexión, debido principalmente al retardo en el proceso y a que si se detectará una conexión el sistema es capaz de detectar una desconexión y ya no se tendría que codificar un módulo extra. Si el GAP se encuentra en modo conexión se muestra el recurso de la red (transcodificándolo si es necesario). En modo desconexión el sistema debe mostrar el

recurso si este se encuentra en la caché local del dispositivo móvil; en caso contrario, muestra un mensaje de error, tal y como se ve en la Figura 7. Nótese que el acceso a los recursos en la caché local es transparente al navegador, por lo que el navegador no se da cuenta si el recurso está en la red o en el dispositivo (no se emplea el protocolo file://).

Figura 7. Visualización de recursos en modo desconexión.

Figura 5. Monitoreo de una desconexión en el GAP.

Figura 6. Ejemplo de Reconexión en el GAP

El GDL también se probó en otros dispositivos como el emulador de Windows CE .NET (4.2) y en un Smartphone con Windows Mobile 2003. En éste último el programa se ejecuta al igual que en la mayoría de las PPCs pero no se visualizan resultados dado que no se cuenta con un shell de líneas de comando (en la versión 2003 de PPCs y superior se puede instalar una consola de línea de comandos). La ejecución del programa en el teléfono celular con Windows Mobile 2003 se muestra en la Figura 8.

Figura 8. Ejecución del monitor de desconexiones en un Smartphone 2003.

V CONCLUSIONES En la actualidad es cada vez menos común que se presenten eventos de desconexión en redes inalámbricas, pero debido a la naturaleza del medio físico de transmisión, dichos eventos siempre se presentarán y será necesario tomar está y otras consideraciones cuando se realicen aplicaciones en dispositivos móviles. Las desconexiones son una norma en ambientes móviles y lejos de enfocarse en tratar de eliminarlas completamente se debe hacer frente a los eventos de desconexión. Tal es el caso de este trabajo, en donde se implementó un módulo gestor de desconexiones locales en esta clase de desconexiones, obteniendo una métrica del 30% de efectividad para determinar si un cliente móvil se encuentra desconectado o no. VI AGRADECIMIENTOS Al CoSNET por el apoyo económico brindado conn la beca número 102004189PJ para estudios de maestría. VII REFERENCIAS [1] Roldán Martínez, David, “Comunicaciones

[2]

[3]

[4]

[5]

[6]

[7]

inalámbricas. Un enfoque aplicado”, Editorial Alfaomega, México, 2005, ISBN 970-15-1078X, pp. 363. Alarcón Gálvez, Fernando, “Mecanismo para Gestión de Conexión en Sistemas Cliente/Servidor Móviles”, tesis de maestría, cenidet, agosto de 2002. Olivares Rojas, Juan Carlos, “Gestor de Acaparamiento de Sitios Web Transcodificados para Plataforma Pocket PC”, tesis de maestría en desarrollo, cenidet, enero de 2005. González Serna Juan Gabriel. “Plataforma middleware reflexiva para aplicaciones de cómputo móvil en Internet (Movirware)”, Centro Nacional de Investigación y Desarrollo Tecnológico (cenidet), de septiembre de 2001 a agosto de 2003, financiamiento COSNET: 570.01-P. Verduzco Reyes Gustavo, “Gestor de Acaparamiento de Patrones de Sitios Web en Clientes Móviles”, tesis de maestría, cenidet, agosto de 2003. Valenzuela Molina David R., “Mecanismo para Predicción de Acaparamiento de Datos en Sistemas Cliente/Servidor Móviles”, tesis de maestría, cenidet, agosto de 2002. González Serna Gabriel, Montes Rendón Azucena, Olivares Rojas Juan Carlos.

“Comparativa y evaluación de las herramientas de programación para desarrollar aplicaciones en plataforma Pocket PC”. 6to. Congreso Internacional de las Ciencias Computacionales. Colima, Colima, México, septiembre de 2005. [8] Uriarte Cabada Claudia Selene. “Transformador de Contenidos Web para Asistentes Personales Digitales”, tesis de maestría, cenidet, julio de 2004. CURRICULUM VITAE Juan Carlos Olivares Rojas es Ingeniero en Sistemas Computacionales por el Instituto Tecnológico de Morelia. Actualmente realiza postgrado de Maestría en Ciencias en Ciencias de la Computación en la especialidad de Sistemas Distribuidos en el Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). También es vicepresidente de la rama estudiantil del CENIDET-IEEE. Sus áreas de interés son el cómputo móvil, redes de telecomunicaciones y base de datos. Es Candidato a Doctor en Ciencias de la Computación por el CIC del IPN. Sus áreas de interés son: Redes inalámbricas (802.11x y Bluetooth), Minería de uso de la Web y Sistemas Distribuidos. Azucena Montes Rendón estudió Doctorado en Matemáticas en la Université de Paris-Sorbonne en Francia, en 2002. Sus áreas de interés son: Tratamiento informático del lenguaje natural, Web semántica e inteligencia artificial. Víctor Jesús Sosa Sosa es Doctor en Ciencias de la Computación por la Universidad Politécnica de Cataluña. Sus áreas de interés son: Sistemas distribuidos, Programación en el Web, Bases de datos y Sistemas operativos.