Repositorio Institucional de Documentos

Portarretratos inteligente, acceso a servicios en red desde dispositivos de bajas prestaciones RESUMEN El acceso a los diferentes tipos de información que ofrece Internet ha pasado de ser algo habitual a una necesidad continua, gracias al auge de las redes sociales. Esto genera una demanda de nuevas formas de acceder a la información, lo que representa una oportunidad para desarrollar nuevas soluciones. El portarretratos inteligente, o Smart Photo Frame , es un dispositivo que muestra de forma continua información proveniente de diferentes servicios en red. Su formato es similar al de un marco de fotos digital, con una mayor interactividad. Nosotros planteamos una plataforma para portarretratos inteligentes, que: Permite el acceso a Internet sin restricciones desde cualquier dispositivo Es capaz de funcionar desde dispositivos con hardware muy limitado Evita la obsolescencia, no dependiendo del software del dispositivo para acceder a nuevos tipos de contenidos Su arquitectura está basada en la transformación en imágenes jas de los contenidos accedidos a través de un navegador. Estas imágenes son generadas por un agente externo al dispositivo cliente, cuyo único requisito computacional será representar la información en su pantalla e interactuar con el usuario. Con el n de demostrar el funcionamiento y viabilidad de la solución, se ha implementado el proxy completo, junto con un emulador de portarretratos para PC y una implementación de demostración plenamente funcional sobre la videoconsola Nintendo DS. En este marco de desarrollo, hemos realizado un estudio de viabilidad de diferentes formatos de representación de imágenes, con el n de encontrar el óptimo para nuestra solución. Finalmente, hemos comprobado que es una plataforma completa y versátil, que ofrece múltiples oportunidades para el desarrollo de servicios interactivos en red para dispositivos de bajas prestaciones. Índice general 1. Introducción 1 1.1. Motivación ....................................... 1 1.2. Objetivosdelproyecto................................. 4 1.3. Estructuradelamemoria ............................... 4 2. Arquitectura 5 2.1. Descripción ....................................... 5 2.1.1. Envíodecapturas ............................... 5 2.1.2. Diseñodelasolución.............................. 5 2.1.3. Valoración de la solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Elementos........................................ 7 2.2.1. Cliente...................................... 7 2.2.2. Proxy ...................................... 7 2.3. Conexiónproxy-cliente................................. 9 2.4. Protocolo de comunicaciones proxy-cliente . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1. Funcionamiento................................. 10 2.4.2. Ventajas respecto a otros protocolos . . . . . . . . . . . . . . . . . . . . . 11 3. Planteamiento y entorno de trabajo 13 3.1. Planteamiento...................................... 13 3.2. Dispositivosutilizados ................................. 13 3.3. Tecnología de comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. NintendoDS ...................................... 14 3.5. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.5.1. BorlandDelphi7................................ 16 3.5.2. devkitARM release 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.5.3. Apache ..................................... 17 4. Trabajo realizado 19 4.1. Desarrollodesoftware ................................. 19 4.1.1. Softwaredecliente............................... 19 4.1.2. Softwaredeproxy ............................... 21 4.1.3. Servidor..................................... 21 4.1.4. Protocolo de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. Capturas......................................... 22 4.2.1. Obtención.................................... 22 4.2.2. Formatos .................................... 23 4.2.3. Tiposdecaptura................................ 23 4.2.4. Medidas de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 i ÍNDICE GENERAL Lorena Domínguez Barrio 5. Conclusiones 29 A. Planicación del proyecto 31 A.1.DiagramadeGantt................................... 31 A.2. Descripción de los pasos seguidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 B. Viabilidad de formatos 33 B.1.Objetivoymetodología ................................ 33 B.1.1.Objetivo..................................... 34 B.1.2.Bancodeimágenes............................... 34 B.1.3.Sistemademedición.............................. 35 B.1.4.Procedimiento ................................. 35 B.2. Descripción y análisis de JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.2.1.Descripción................................... 35 B.2.2.Análisis ..................................... 36 B.3. Descripción y análisis de GIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 B.3.1.Descripción................................... 40 B.3.2.Análisis ..................................... 44 B.4. Descripción y análisis de PNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 B.4.1.Descripción................................... 47 B.4.2.Análisis ..................................... 48 B.5. Comparativa de los diferentes formatos . . . . . . . . . . . . . . . . . . . . . . . . 51 B.5.1. Formatos seleccionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 B.5.2. Resultados generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 B.5.3.Valoraciónnal................................. 54 C. Manual de la aplicación 55 C.1.Proxy .......................................... 55 C.1.1.Entornooperativo ............................... 55 C.1.2.Puestaenmarcha................................ 55 C.1.3.Funcionamiento................................. 55 C.2.ClienteparaNintendoDS ............................... 57 C.2.1.Puestaenmarcha................................ 57 C.2.2.Funcionamiento................................. 57 C.2.3. Otras funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 C.2.4.Teclado ..................................... 61 C.3. Cliente para emulador de portarretratos . . . . . . . . . . . . . . . . . . . . . . . 62 C.3.1.Puestaenmarcha................................ 62 C.3.2.Funcionamiento................................. 62 C.3.3.Teclado ..................................... 62 C.4.Servidor......................................... 63 D. Protocolo de comunicaciones proxy-cliente 65 D.1.Introducción....................................... 65 D.2. Protocolo de comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 D.3.Formatodetramas................................... 66 D.4. Interpretación de las tramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 D.4.1. Tramas recibidas por el proxy . . . . . . . . . . . . . . . . . . . . . . . . . 66 D.4.2. Tramas recibidas por el cliente . . . . . . . . . . . . . . . . . . . . . . . . 69 ii Índice de tablas B.1. Comparativa de tiempo de compresión en formatos grácos . . . . . . . . . . . . 50 B.2. Comparativa de tamaño de archivo en formatos grácos . . . . . . . . . . . . . . 50 D.1.Tiposdetramacliente................................. 67 D.2.Tiposdetramaproxy ................................. 69 iii iv Índice de guras 1.1. EncuestadelaAIMC ................................. 1 1.2. Smart Photo Frames actualmente en el mercado . . . . . . . . . . . . . . . . . . . 2 2.1. Arquitectura de la solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Ejemplosdecaptura .................................. 9 2.3. Protocoloproxy-cliente................................. 10 3.1. NintendoDSLite.................................... 15 4.1. Ejecución del software de cliente en NDS . . . . . . . . . . . . . . . . . . . . . . . 20 4.2. Aplicaciónproxy .................................... 21 4.3. Tiemposdecompresión ................................ 27 4.4. Tamañosdearchivo .................................. 27 A.1.DiagramadeGantt................................... 31 B.1. Categorías de imágenes estudiadas . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.2. Articios generados por JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 B.3. Evolución de la calidad en captura tipo foto ..................... 37 B.4. Evolución de la calidad en captura mixta . . . . . . . . . . . . . . . . . . . . . . . 38 B.5. Evolución de la calidad en captura tipo texto .................... 38 B.6. Tiempo de compresión para formato JPEG . . . . . . . . . . . . . . . . . . . . . 39 B.7. Tamaño de archivo para formato JPEG . . . . . . . . . . . . . . . . . . . . . . . 39 B.8. Ejemplo de dithering .................................. 41 B.9. Detalle de dithering .................................. 42 B.10.Codicación de imágenes dependiente de la paleta . . . . . . . . . . . . . . . . . 43 B.11.Cuadro comparativo de formato GIF . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.12.Tiempos de compresión para formato GIF . . . . . . . . . . . . . . . . . . . . . . 46 B.13.Tamaño de archivo para formato GIF . . . . . . . . . . . . . . . . . . . . . . . . . 46 B.14.Comparativa de formatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 B.15.Tiempos de compresión para formato PNG . . . . . . . . . . . . . . . . . . . . . 49 B.16.Tamaño de archivo para formato PNG . . . . . . . . . . . . . . . . . . . . . . . . 50 B.17.Tiemposdecompresión ................................ 52 B.18.Tamañosdearchivo .................................. 52 B.19.Comparativa de los formatos seleccionados . . . . . . . . . . . . . . . . . . . . . . 53 B.20.Tiempos de decodicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 C.1.Pantalladelproxy ................................... 56 C.2. Formatos del navegador del proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 C.3.NDS.Menúdeconexión................................ 57 v ÍNDICE DE FIGURAS Lorena Domínguez Barrio C.4.NDS.SeleccióndeAP ................................. 58 C.5. NDS. Petición de contraseña . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 C.6.NDS.SolicituddeIP.................................. 58 C.7. NDS. Menú de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 C.8. NDS. Servicios personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 C.9.NDS.Escritorioremoto ................................ 60 C.10.NDS.AccesoWeb.................................... 60 C.11.NDS.Menúdeopciones ................................ 61 C.12.NDS.Teclado...................................... 61 C.13.TeclasDS........................................ 61 C.14.Teclado del emulador de portarretratos . . . . . . . . . . . . . . . . . . . . . . . . 62 D.1.Protocoloproxy-cliente................................. 66 vi Capítulo 1 Introducción En este capítulo se presentan los objetivos del proyecto, así como el proceso de trabajo y la estructura de la memoria. 1.1. Motivación La idea de este proyecto, surge de la creciente necesidad de las personas por permanecer conectadas en todo momento. Desde hace un tiempo, consultar el e-mail o la información meteorológica desde los dispositivos móviles se ha convertido en algo muy habitual, por esto, cada vez son más los dispositivos tipo teléfono, que facilitan el acceso a los servicios disponibles en la Web. La gráca de la Figura 1.1, muestra los resultados porcentuales de uso de Internet por parte de la población general (eje de ordenadas) obtenidos año a año (eje de abscisas) en el Estudio General de Medios (EGM) realizado por la Asociación para la Investigación de Medios de Comunicación (AIMC). Se observa claramente cómo el uso de Internet en España no ha parado de crecer en los últimos años. A su vez, puede comprobarse cómo cada vez más personas utilizan Internet diariamente. 0 5 10 15 20 25 30 35 40 45 50 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 Porcentaje Año Han usado Internet recientemente Usaron internet ayer Figura 1.1: Estudio de la AIMC sobre el uso de Internet . El conjunto de dispositivos que permiten este tipo de acceso es muy heterogéneo. Actualmente están integrados desde en productos tan populares dentro de la electrónica de consumo como son los teléfonos móviles, hasta en productos únicamente destinados a ofrecer este tipo de 1 CAPÍTULO 2. ARQUITECTURA Lorena Domínguez Barrio Ejemplos de tecnologías soportadas son: Wi-Fi, 3G, Ethernet o PLC. Los tipos de información que se envían entre estos dos elementos son: Identicación de cliente. Se envía en sentido de cliente a proxy El cliente, al iniciar la sesión, proporciona sus datos para que el proxy pueda servirle los contenidos que él anteriormente ha solicitado. De esta manera, el cliente no tiene que decir qué contenidos desea ver al iniciar la sesión, gracias a que sus preferencias están guardadas. Capturas de pantalla. Se envía en sentido de proxy a cliente El proxy provee al cliente de las capturas conforme navega por los contenidos solicitados. Actividad de usuario. Se envía en sentido de cliente a proxy El usuario envía al proxy su interacción en el transcurso de la navegación para que éste interprete los comandos en su navegador local y realice las peticiones externas que sean necesarias. El tipo de envío que genera más cantidad de información en tránsito son las capturas de pantalla. Las capturas se fragmentan en segmentos, que son recogidos en el destino y unidos para completar la imagen, tal y como se detalla en el protocolo. Dicho protocolo de envío se describe exhaustivamente en la Sección 2.4. Interpretación de eventos El proxy recibe los eventos generados en la navegación por parte del cliente, tales como clics de ratón o movimientos dentro de la pantalla. Él es el encargado de identicarlos y ejecutarlos, enviándole el resultado de estos eventos al cliente a modo de capturas. Renderizado El envío de las capturas al cliente, supone un renderizado anterior. Este trabajo es llevado a cabo por el proxy. El proxy puede renderizar desde dos fuentes diferentes según sea necesario: Control remoto del ordenador: Si el usuario está utilizando la opción de control remoto del escritorio, la captura la toma del escritorio de la máquina en la que esté instalado el propio proxy. Navegación web: Si la captura es para una navegación normal como puede ser mirar el correo web, se captura la imagen de un navegador local del proxy en el cual se simula la navegación del cliente. Una vez renderizada la imagen, se ajusta según el tipo de imagen que se desee enviar. Un ejemplo de este ajuste se encuentra en la Figura 2.2. Se puede requerir enviar una página entera tal cual está en el navegador o el escritorio completo, para lo que es necesario escalarla al tamaño de la pantalla del dispositivo cliente. También puede enviarse una sección del total de la captura a tamaño real, para ser visualizada en el cliente. 8 Lorena Domínguez Barrio CAPÍTULO 2. ARQUITECTURA Figura 2.2: Ejemplos de captura . Una vez que se ajusta la imagen según sea necesario, se envía la captura al dispositivo cliente. El tamaño de la captura que es enviada depende del dispositivo, ya que se ajusta a la resolución que pueda tener el cliente, y el formato depende del usuario, que puede elegir entre JPEG y GIF según sus necesidades, como se explica en el Anexo B. 2.3. Conexión proxy-cliente La conexión entre el proxy y el cliente tiene las siguientes funcionalidades y características: Identicación de usuario: Para ofrecer funcionalidades independientes a los clientes, se utiliza un sistema sencillo de cuentas. Una base de datos en el servidor almacena los clientes y sus preferencias, que son accedidas cuando entran en el sistema. Gracias a esto, un cliente puede tener una conguración de servicios personalizada. Cifrado: El cifrado en la comunicación proxy-cliente es fundamental cuando se realiza a través de medios no seguros. Desconexión: Cuando se supera un tiempo preestablecido sin recibir tramas por parte del cliente, el servidor cierra la conexión. 2.4. Protocolo de comunicaciones proxy-cliente Uno de los principales objetivos en el diseño de este protocolo es reducir la latencia en la comunicación con el cliente, de forma que la navegación resulte lo más uida posible. Como sabemos, el usuario tiene la ilusión de estar llevando a cabo una navegación local y espera de manera inmediata los cambios en las páginas que está visitando. 9 CAPÍTULO 2. ARQUITECTURA Lorena Domínguez Barrio 2.4.1. Funcionamiento El protocolo, cuya representación gráca puede consultarse en la Figura D.1, funciona de la siguiente manera para los envíos de las capturas: Proxy Cliente 5 1 7 6 4 3 2 Figura 2.3: Protocolo proxy-cliente . 1. El cliente solicita una nueva imagen. Para esto le envía una trama. 2. El proxy le envía una trama informándole de que ha recibido la petición y le especica el número de bloques en los que se divide la imagen que le enviará. 3. El cliente guarda sitio para recibir la imagen completa y la inicializa. Además, envía una trama al proxy para informarle de que ya puede empezar a enviar los bloques de la imagen. 4. El proxy, envía las diferentes partes que componen la imagen seguidos mediante tramas. Cada una de ellas tiene el número de secuencia para poder reconstruirla en recepción. 5. Si hay algún bloque que no se ha recibido, o llega con error, se envía inmediatamente un NAK con el número de trama que le falta al proxy. 6. El proxy reenviaría una trama con el bloque perdido o dañado. 7. Cuando recibe todas las tramas, se envía un ACK para informar al proxy de que todos los bloques de la imagen han sido recibidos. En el Anexo D se detalla el formato de las tramas enviadas para todos los tipos de mensajes presentes en la comunicación proxy-cliente. 10 Lorena Domínguez Barrio CAPÍTULO 2. ARQUITECTURA 2.4.2. Ventajas respecto a otros protocolos El diseño de este protocolo está inuido por la necesidad de almacenar completamente la imagen en el cliente antes de ser mostrada. No tenemos restricciones en cuanto a tamaños de ventanas de recepción, ya que siempre podremos albergar, todos los segmentos de imagen que nos lleguen. El hecho de que una trama llegue dañada, o no llegue, no es un impedimento para seguir recibiendo tramas, lo que se traduce en una comunicación más rápida que la de otros protocolos como los de ventana deslizante con límite de tamaño o Stop & Wait . 11 12 Capítulo 3 Planteamiento y entorno de trabajo En este capítulo se describe el planteamiento inicial para la selección del dispositivo a utilizar, y las posibles alternativas. Además, se incluye una relación de las herramientas utilizadas para el desarrollo del proyecto 3.1. Planteamiento Para implementar la aplicación se barajaron varias posibilidades con el n de determinar qué dispositivos cliente utilizar. El cliente ideal sería un marco de fotos digital con acceso a Internet. Éstos tienen una pantalla bastante grande en comparación con móviles u otros dispositivos de tamaño reducido. Debemos tener en cuenta, que puede haber dispositivos de múltiples tamaños, desde un despertador con una pantalla muy pequeña, hasta una televisión. 3.2. Dispositivos utilizados Hemos trabajado sobre varios dispositivos para dar forma a nuestra solución. Por un lado, se ha hecho uso de un ordenador de sobremesa para albergar en él el proxy que da servicio a los diferentes dispositivos cliente. Los requisitos mínimos para que un ordenador de sobremesa pueda ejecutar el proxy no son elevados, ya que cualquier ordenador moderno con Microsoft Windows, acceso a Internet y un navegador puede hacerlo. Por supuesto, un ordenador con una potencia elevada será capaz de reducir los tiempos de compresión y dar como resultado una navegación más uida. Como dispositivos cliente, de entre todos los que pueden formar parte de la solución, se han elegido dos de ellos para demostrar el funcionamiento de la aplicación y llevar a cabo las medidas de rendimiento: la consola Nintendo DS y un ordenador portátil a modo de emulador de un portarretratos inteligente. La Nintendo DS, como se explica en la Sección 3.4, se utiliza por ser un dispositivo económico y por el atractivo de sus dos pantallas para mostrar el tipo de información al que va dirigida nuestra solución. El uso del ordenador portátil, que actúa como emulador de portarretratos, se ha implementado y además ha servido de referencia para medidas de capturas para resoluciones mayores de 13 CAPÍTULO 3. PLANTEAMIENTO Y ENTORNO DE TRABAJO Lorena Domínguez Barrio pantalla. Cualquier ordenador portátil convencional puede disponer de un navegador completo y, por lo tanto, nuestra solución no tiene sentido para este tipo de dispositivo. El programa creado tan sólo hace uso de su pantalla, ratón, teclado y conexión a Internet, obviando el resto, con el n de comprobar cómo responde el envío de capturas de pantalla cuando los tamaños son mayores. 3.3. Tecnología de comunicaciones La conexión a una LAN o a Internet es fundamental en nuestra solución, ya que todo el contenido que visualiza el cliente va a llegarle a través de esta vía. Por conveniencia y disponibilidad, se ha utilizado Wi-Fi de forma exclusiva durante la realización de este proyecto. Por supuesto, no deben descartarse otras opciones, como 3G, PLC o Ethernet. La tecnología Wi-Fi proporciona una gran libertad, ya que gracias a ella y sin necesidad de cables, los dispositivos pueden acceder a Internet desde cualquier lugar habilitado. 3.4. Nintendo DS La Nintendo DS es una videoconsola portátil desarrollada por Nintendo, que se comenzó a comercializar en el año 2004. Su característica principal es la presencia de dos pantallas independientes, una de ellas táctil. A lo largo de los años, su diseño se ha ido renando y adaptando a diferentes necesidades y mercados, dando lugar a los siguientes modelos: Nintendo DS (2004): primera versión comercializada. Nintendo DS Lite (2006): versión reducida con misma funcionalidad que la original. Nintendo DSi (2008): iteración de la DS Lite que incluye cámara de vídeo y permite el uso de diferentes servicios en Internet. Nintendo DSi XL (2009): una versión de mayor tamaño de la Nintendo DSi. En este proyecto se ha desarrollado sobre la Nintendo DS Lite, que comparte el hardware básico de toda la familia DS. La diferenciación principal respecto a la Nintendo DS original es su menor volumen, a pesar de que aumenta el tamaño de las pantallas. La videoconsola cuenta con dos procesadores: un ARM9, a una frecuencia de 66MHz, y un ARM7, a 33MHz. En general, los programas de usuario deben correr siempre sobre el ARM9, utilizando el ARM7 únicamente desde llamadas de biblioteca. La gestión de memoria es compleja. Incorpora una caché de 4KB para datos y 8KB para instrucciones, junto a 32 KB de TCM (memoria rápida controlada por software) para instrucciones y 16 KB de TCM para datos. Dispone de dos pantallas LCD con una resolución de 256x192 píxeles, una de ellas táctil. El motor de aceleración de grácos en dos dimensiones está disponible para las dos pantallas 14 Lorena Domínguez Barrio CAPÍTULO 3. PLANTEAMIENTO Y ENTORNO DE TRABAJO Figura 3.1: Nintendo DS Lite simultáneamente, mientras que el motor de tres dimensiones sólo puede utilizarse de forma efectiva sobre una. Además de las pantallas LCD, la DS soporta dieciséis canales de sonido, incorporando micrófono, dos altavoces con control de volumen analógico y toma de auriculares. Así mismo, dispone de varios botones y cursores, que junto a la pantalla táctil hacen de la DS una videoconsola con un gran potencial para todo tipo de aplicaciones interactivas. La Nintendo DS utiliza Wi-Fi como medio de comunicación para juegos en red. La versatilidad que ofrece la tecnología Wi-Fi ya ha sido aprovechada por la propia Nintendo a partir de la DSi, ampliando los servicios disponibles para la consola. Utiliza el estándar IEEE802.11b en la banda de 2.4GHz, dando soporte a encriptación WEP. Existe un navegador para la Nintendo DS y DS Lite creado por Opera, basado en su motor Presto. Este navegador presenta serias limitaciones, como no ser capaz de reproducir contenido ash o ser demasiado lento, a pesar de incluir una ampliación de memoria para la consola. La Nintendo DSi incorpora una versión más moderna de este navegador. La Nintendo DS es una videoconsola extremadamente popular, con más de ciento veinte millones de unidades vendidas en todo el mundo. El kit de desarrollo ocial no es de libre distribución, por lo que existen varias comunidades de homebrew (desarrollo de aplicaciones no ociales para videoconsolas) que ofrecen bibliotecas y utilidades para crear software para la DS. Este software debe ser ejecutado utilizando un dispositivo especial, que debe adquirirse de forma separada. Su gran interactividad y baja potencia la hacen la candidata ideal como sistema de desarrollo y demostración para este proyecto. Sus dos pantallas ofrecen nuevas oportunidades de mostrar el contenido. 15 CAPÍTULO 3. PLANTEAMIENTO Y ENTORNO DE TRABAJO Lorena Domínguez Barrio 3.5. Herramientas utilizadas Se han utilizado varias herramientas para implementar la solución. A continuación, se detallan las principales. 3.5.1. Borland Delphi 7 Borland Delphi es un entorno de desarrollo de aplicaciones para Microsoft Windows, comercializado por Borland en el año 2002. El lenguaje utilizado es un derivado de Pascal, con varios añadidos que incluyen orientación a objetos. En este proyecto se ha utilizado Delphi para la programación del proxy, de forma que se ha podido reutilizar código ya existente de capturas de pantalla con la Nintendo DS. También se ha utilizado para implementar el emulador de portarretratos en PC. La amplia biblioteca de componentes y su integración con la API de Windows, junto a las potentes características de creación de menús, han sido características muy ventajosas a la hora de realizar este desarrollo. El principal inconveniente es la dicultad a la hora de portar el software generado a otras plataformas. 3.5.2. devkitARM release 21 Para el desarrollo de software sobre la Nintendo DS se ha utilizado la plataforma devkitARM. El entorno es gratuito y está bajo licencia GPL 1 , por lo que todo el código fuente está disponible. devkitARM forma parte del proyecto devkitPro, que ofrece diferentes entornos de compilación cruzada para desarrollar software para diversas videoconsolas. Concretamente, devkitARM permite desarrollar programas para procesadores ARM, e incluye soporte especíco para GameBoy Advance y Nintendo DS. El entorno para usuario nal de devkitARM incluye un toolchain completo de compilación cruzada para ARM. Este toolchain incorpora los compiladores de C y C++ de GCC 4.1.2, además de utilidades de generación de binarios e imágenes para la Nintendo DS. Dentro del mismo entorno se encuentra también libnds, una biblioteca de bajo nivel que permite controlar el hardware de la Nintendo DS. Por desgracia, al ser una implementación no soportada por Nintendo, no cubre todas las características de la máquina. La programación para Nintendo DS resulta compleja por las limitaciones de su arquitectura y la falta de soporte para las bibliotecas con las que contamos. Como problema adicional, no hemos podido utilizar ninguna herramienta de depuración: aunque existen varios emuladores de la arquitectura, ninguno simula correctamente la comunicación Wi-Fi, necesaria en este proyecto. 1 General Public License 16 Lorena Domínguez Barrio CAPÍTULO 3. PLANTEAMIENTO Y ENTORNO DE TRABAJO 3.5.3. Apache La navegación desde algunos de los dispositivos que tratamos está muy limitada en comparación con la navegación desde ordenadores convencionales. Las bajas resoluciones de algunos de estos dispositivos hacen que sea conveniente adaptar las páginas web antes de presentárselas al usuario. En algunos casos (Facebook o Wikipedia, por ejemplo), la propia página tiene versiones adaptadas a dispositivos móviles que podemos usar en nuestra aplicación. Para otro tipo de páginas, como el propio Facebook o Flickr entre otras, existen APIs públicas que permiten crear páginas web con la misma información que ofrece la página ocial. Por eso, dentro de la arquitectura de la aplicación se incluye un servidor web, desde el que el usuario pueda comenzar su navegación con un menú personalizado, y visitar páginas adaptadas si así lo desea. Esta labor la realiza el servidor web Apache. El servidor HTTP de Apache es uno de los servidores web más utilizados en Internet. Además de ser un software maduro y estable, es libre. Uno de sus puntos fuertes para su elección en este proyecto, es su integración inmediata con gran número de lenguajes de programación de páginas web dinámicas. 17 CAPÍTULO 4. TRABAJO REALIZADO Lorena Domínguez Barrio Gracias a esta optimización, se puede reducir considerablemente la cantidad de información a transmitir por la red a un cliente que realice este tipo de desplazamientos. Esta optimización se implementó sobre nuestra solución, por lo que pudimos comprobar que los tamaños de las imágenes a enviar eran menores, ya que tan sólo suponen una porción del tamaño total de la pantalla. El tiempo empleado en renderizar la imagen era el mismo, ya que se necesita capturar toda la pantalla para comprobar si ha habido variación en la pantalla antes de enviar tan solo una sección. Esto es así ya que es posible que además del desplazamiento, se haya producido un cambio en la parte ja y deba ser enviada de nuevo toda la imagen. Por otro lado, este proceso conlleva más trabajo por parte del proxy, ya que debe mantener índices de las posiciones y tamaños enviados anteriormente para calcular el punto a partir del cual enviar la imagen, así como calcular el tamaño de la nueva sección para enviarle todos estos datos al cliente. Esto es necesario para que el cliente sepa dónde colocar la sección de imagen que le llega. Cambios localizados Además de los desplazamientos en la pantalla, podemos encontrarnos con variaciones localizadas dentro de la misma. Imaginemos por ejemplo un anuncio en una página web que se trata de contenido en ash que está en continuo movimiento. Enviar toda la imagen puede ser excesivo, ya que sólo ha cambiado una sección. Una posible optimización para beneciarnos de esta circunstancia es la de enviar solamente los píxeles que hayan sido modicados de la imagen. Esta optimización, es similar a la anterior, ya que sólo enviamos parte de la imagen. La diferencia se encuentra en que en el caso anterior, el movimiento venía dado por un evento del cliente, mientras que en este caso, es el proxy el que debe identicar que sólo ha variado una parte antes de enviarla. Esto puede localizarse mediante diferentes técnicas como pueden ser: • Resta de capturas. Éstas deberán estar guardadas en formato BMP para poder comparar píxel a píxel, ya que por ejemplo el formato JPEG no codica las imágenes en mapa de bits. Si los cambios se localizan dentro de un área determinada de la imagen, tan sólo se enviará ese área. • Análisis de metadatos. Se puede analizar el código en HTML en busca de contenido ash o susceptible de movimiento. Esta optimización también ha sido implementada y estudiada con el n de analizar la posible mejora. Es una optimización más compleja, ya que supone trabajo por parte del proxy, que ha de realizar una comparativa de los BMPs y cada uno de sus píxeles. El tiempo invertido en esta comparación es elevado y aumenta considerablemente el tiempo de preparación de la captura. Una vez seleccionados los píxeles se envía de forma absoluta la menor área de la imagen que contenga todos los píxeles modicados. Para pantallas pequeñas no se obtienen benecios. Por este motivo, a pesar de haber sido implementado, se dejó sin aplicar en la versión de demostración. 24 Lorena Domínguez Barrio CAPÍTULO 4. TRABAJO REALIZADO Incremental Por último, puede darse el caso de que se produzcan pequeños cambios en píxeles dentro de la página que no se encuentren localizados en un área. El proceso a llevar a cabo en estos casos es similar al anterior. Se ha de recurrir a la resta de BMPs (píxel a píxel) con el n de localizar los píxeles que han sido modicados. Sin embargo, esta opción no puede emplearse en todos los tipos de formatos. Debido a que el formato JPEG, por ejemplo, codica las imágenes en conjunto y no con mapa de bits, resulta imposible cambiar un píxel suelto. Esta optimización es válida para formatos como por ejemplo GIF, con la restricción de emplear una paleta ja para todas las imágenes, con el n de que los índices accedan al color correcto. Esta optimización se implementó y su estudio no produjo una mejora signicativa en los tiempos. Por un lado, la comprobación de cada píxel supone un gasto de tiempo elevado. Por otro lado, el uso de una paleta ja, hace que los colores obtenidos dieran de la realidad y ocasionen una calidad visual de la imagen muy pobre. En el único caso que puede ser viable es para las imágenes con sólo texto y aún así, el tamaño en formato GIF es mínimo, con lo que carece de sentido práctico. Otros factores como la restricción de formato impuesta, la sobrecarga para el proxy (mayor cuantos más clientes concurrentes) y la inuencia del tamaño de la pantalla, han sido decisivos para prescindir de esta optimización en nuestra aplicación. Las optimizaciones presentadas ganan importancia a medida que aumenta la resolución del dispositivo cliente. En el caso de la Nintendo DS, con su escasa resolución, las optimizaciones no inuyen en gran medida. 4.2.4. Medidas de rendimiento Se han llevado a cabo medidas de rendimiento para conseguir minimizar el tiempo empleado en mostrar las imágenes por pantalla. Con nuestra arquitectura se pretende que el usuario tenga la ilusión de navegación local, así que las capturas han de ser recibidas de manera uida. Por tanto, será necesario conseguir reducir la latencia al mínimo posible y garantizar un ancho de banda suciente. Las dos medidas que hemos tenido en cuenta han sido el tiempo de compresión de la captura en un formato de imagen y su tamaño, que afecta al tiempo de envío. A continuación se detalla cómo se llevan a cabo estas medidas y los resultados que arroja su estudio. Se ha de tener en cuenta el compromiso que existe entre calidad y tamaño: a mayor calidad, mayor tamaño de imagen. Se pretende encontrar el punto que equilibre este compromiso y genere resultados óptimos. Método La solución se verica y estudia utilizando los dos dispositivos clientes nombrados en la primera sección de este capítulo, con el n de generar envíos de capturas, la operación más costosa en tiempo y la que tiene un mayor potencial para minimizar la latencia. El procedimiento llevado a cabo para este estudio es la creación de una traza de imágenes a un tamaño acorde para cada dispositivo, que nos permita medir de forma consistente diferentes factores utilizando 25 CAPÍTULO 4. TRABAJO REALIZADO Lorena Domínguez Barrio ejecución directa. En esta traza se encuentran tres tipos de imágenes: Imágenes con sólo texto Imágenes con sólo foto Imágenes mixtas (texto y foto) Esta separación de tipos de imagen se debe a sus diferentes gamas de color, que tras varios análisis previos pudimos comprobar que es el factor determinante para obtener tamaños de chero reducidos con diferentes formatos. Es importante disponer de estos tres tipos para poder calcular datos ables, en media, de cómo reaccionan los dispositivos a un tamaño determinado de imagen independientemente del tipo de imagen que se esté enviando. Ya que nuestro objetivo es obtener datos consistentes de todos estos bloques, hemos denido un amplio conjunto de imágenes para cada uno, que nos permitirán obtener promedios ables de las características estudiadas. El conjunto de todas estas imágenes lo denominaremos banco de imágenes. Se han realizado las siguientes actividades para cada formato estudiado: 1. Codicación del banco de imágenes en el formato correspondiente Se codica cada imagen del banco de imágenes, explicado anteriormente, con el n de medir el tiempo de conversión. Como ya hemos dicho, cada formato tiene características congurables que pueden hacer variar los tamaños y tiempos que se pretenden estudiar, luego han de ser tenidos en consideración. Por ello, se realizan experimentos con todas las conguraciones que permite cada formato, atendiendo al compromiso entre calidad, tamaño y tiempo. Según el tipo de formato, son: JPEG : Variación de la calidad, de 0 a 100% en intervalos de 10%. GIF : El formato GIF, al ser un formato que hace uso de paletas dentro de la imagen, ofrece la posibilidad de utilizar diferentes paletas ya predenidas o incluso generar una propia. Además, permite elegir entre diferentes algoritmos de dithering . Las paletas estudiadas son tres y los algoritmos son siete. PNG : Variación del ratio de compresión, de 0 a 9. 2. Envío al dispositivo cliente El siguiente objeto de estudio, una vez obtenidos unos parámetros de codicación razonables, es la transferencia de imágenes al dispositivo cliente. Como ya se ha dicho, se utilizan dos dispositivos cliente para realizar estas pruebas con el n de probar diferentes resoluciones de imagen. Este paso busca calcular el tiempo de envío de cada imagen. Se comprueba que el tiempo de envío es proporcional al tamaño de la imagen enviada, por lo que va a ser un factor determinante en la elección del formato a utilizar. 26 Lorena Domínguez Barrio CAPÍTULO 4. TRABAJO REALIZADO Resultados y conclusiones Analizando los resultados se llega a una idea clara del tiempo necesario para codicar las imágenes dependiendo del formato elegido y del tipo de imagen. Se analiza no sólo los tiempos obtenidos y los tamaños, sino la calidad visual de la imagen generada, ya que, en denitiva, es lo que es lo que marcará la experiencia de usuario. El Anexo B incluye más conclusiones sobre el estudio que se ha realizado de los formatos grá- cos disponibles. A continuación se presentan los resultados y conclusiones nales de dicho estudio. De entre las distintas conguraciones posibles para cada uno de los formatos, se selecciona la que genera mejores resultados. Eligiendo las características óptimas para cada formato, la Figura 4.3 presenta los resultados obtenidos para el tiempo de compresión. 0 10 20 30 40 50 60 70 80 JPG PNG GIF(P.Quantize) GIF(P.Web) Tiempo de compresión (ms) Formato de archivo Foto Mixta Texto (a) Nintendo DS 0 100 200 300 400 500 600 700 800 JPG PNG GIF(P.Quantize) GIF(P.Web) Tiempo de compresión (ms) Formato de archivo Foto Mixta Texto (b) Ordenador portátil Figura 4.3: Tiempos de compresión Los tamaños de imagen generados, que afectan directamente al tiempo de envío de las capturas, son los recogidos en la Figura 4.4 a modo de resumen. 0 10 20 30 40 50 60 70 80 90 JPG PNG GIF(P.Quantize) GIF(P.Web) Tamaño de archivo (kB) Formato de archivo Foto Mixta Texto (a) Nintendo DS 0 100 200 300 400 500 600 700 800 900 JPG PNG GIF(P.Quantize) GIF(P.Web) Tamaño de archivo (kB) Formato de archivo Foto Mixta Texto (b) Ordenador portátil Figura 4.4: Tamaños de archivo 27 CAPÍTULO 4. TRABAJO REALIZADO Lorena Domínguez Barrio Como se desprende de la Figura 4.3, el tiempo que se dedica a la compresión de las imágenes es, en media, menor en el formato JPEG que en cualquiera de los demás formatos. Si nos centramos únicamente en las imágenes con sólo texto, PNG es una opción algo mejor. Además vemos como, en las pruebas a mayor tamaño, la relación sigue siendo proporcional a los resultados de las pruebas en la Nintendo DS. En la Figura 4.4 que recoge el tamaño de los archivos generados según el formato utilizado, se observa cómo, en media, los resultados son mejores nuevamente para el formato JPEG. También en esta ocasión, los tamaños resultantes de la conversión son peores para JPEG cuando la imagen es únicamente texto. En este caso concreto, los formatos GIF y PNG tienen una clara ventaja. Teniendo en cuenta el conjunto de los resultados obtenidos se decide implementar el envío de capturas utilizando como formato JPEG con una calidad del 70%. Sin embargo, se deja implementada la posibilidad de usar el formato GIF si lo que se va a visualizar es texto, en cuyo caso, como hemos visto, los resultados relativos al tamaño y al tiempo de compresión son mejores para este formato. 28 Capítulo 5 Conclusiones Tal y como se planteaba en los objetivos del proyecto, se ha diseñado una arquitectura viable para el acceso a Internet desde dispositivos de baja capacidad computacional. La arquitectura permite el acceso desde el cliente a cualquier servicio que sea capaz de mostrar el proxy, no siendo necesaria la actualización de su software a medida que aparecen nuevas tecnologías y estándares. Para lograr estos objetivos, se ha denido un protocolo de comunicaciones y se ha implementado el servidor proxy. Además, se ha realizado una implementación de demostración como dispositivo cliente sobre la videoconsola Nintendo DS con funcionalidad completa y un dispositivo cliente en PC emulando un portarretratos. En el marco de este desarrollo, se ha realizado un estudio de la inuencia del uso de diferentes formatos grácos en el rendimiento de la solución. Para dicho estudio se han utilizado las dos implementaciones de cliente desarrolladas. Los resultados nales del estudio se han incluido satisfactoriamente en la solución. Trabajo futuro A continuación, se presentan diferentes propuestas que pueden ser interesantes en futuros desarrollos de este proyecto: Detectar en proxy el formato adecuado para el envío. En la solución actual, es el usuario quien decide en qué formato enviar las imágenes mediante un selector en el proxy. En general, se prevé utilizar JPEG como formato habitual, pero se mantiene GIF como una opción para capturas de sólo texto. La mejora consistiría en que el proxy fuera capaz de, según el contenido que se esté visualizando, emplear el formato que produzca mejores resultados, realizando análisis sobre la imagen, comprobando el tamaño tras realizar una conversión directa, o aplicando conocimientos sobre el contenido HTML. Streaming Podría incorporarse a la solución un sistema de streaming de vídeo, de forma que el dispositivo cliente pudiese reproducir música o vídeo desde el servidor. Esto permitiría una navegación más completa, ya que no se perdería funcionalidad en páginas de vídeo. Nuestra aplicación consigue una velocidad adecuada para la navegación pero no para la reproducción de vídeo. 29 30