Symbian

Análisis de Symbian OS para desarrollar aplicaciones distribuidas sobre terminales GPRS

Almudena Díaz, Pedro Merino, Fº Javier Rivas Dept. de Lenguajes y Ciencias de la Computación ETSI de Telecomunicación Univ. de Málaga 29071 Málaga {almudiaz,pedro}@lcc.uma.es, {almudiaz,pedro}@lcc.um a.es, [email protected]

Resumen El papel que desempeñan los teléfonos móviles en en el ámbito de los sistemas distribuidos ha evolucionado en los últimos años hasta llegar a convertirse en entornos en los que se pueden desarrollar complejas aplicaciones. Por esta razón han surgido numerosas plataformas, tales como Symbian, cuyo objetivo es adaptarse a las limitaciones de los terminales móviles y proveer  al desarrollador de las herramientas necesarias  para la programación programación de aplicaciones aplicaciones en terminales móviles. Symbian OS es un sistema operativo especialmente diseñado para adaptarse a los requerimientos de un teléfono móvil. En este artículo se revisan loas aspectos que pueden tener  más impacto en las aplicaciones desarrolladas sobre este sistema operativo en los terminales GPRS actuales. También se lleva a cabo una evaluación cuantitativa de las comunicaciones de datos sobre dicha plataforma que permite extraer  conclusiones acerca de la experiencia de los usuarios de aplicaciones en terminales móviles.

1. Introducción Los teléfonos móviles con tecnología GPRS (General Packet Radio Service) o UMTS (Universal Mobile Telecommunications System) comienzan a sustituir a los ordenadores personales como terminales de Internet tanto en uso  profesional  profesional como de ocio. Sin embargo, al tratarse de dispositivos con características propias como

las limitaciones de memoria, CPU o batería resulta necesario desarrollar nuevos sistemas operativos y entornos de desarrollo específicos que se ajusten a las exigencias de dichos terminales. En este artículo se revisan nuestras experiencias con el sistema operativo Symbian OS, tanto desde el punto de vista del desarrollador  como de las prestaciones que ofrecen al usuario final. En este trabajo nos centramos en los aspectos que se han revelado críticos para mejorar  la percepción del usuario cuando emplea TCP/IP sobre estos terminales. Muchas de las experiencias  provienen de desarrollos recientes como clientes de correo [1] y clientes para domótica [2][3] para terminales móviles. Las velocidades proporcionadas por GPRS han propiciado el desarrollo de aplicaciones que hacen un uso intensivo de las comunicaciones. Con la reciente puesta en marcha de UMTS las velocidades medias alcanzadas pueden llegar  hasta los 384 kbits. Esto junto con las elevadas  prestaciones  prestaciones de los teléfonos de última generación, usualmente llamados smartphones,  permite el desarrollo aplicaciones multimedia que explotan el concepto de movilidad en su sentido más amplio. En este escenario han ido surgiendo una gran variedad de sistemas operativos y plataformas orientadas al desarrollo de aplicaciones para dispositivos móviles: Symbian OS [12], Linux Embedded[16], Microsoft CE[19], Blackberry OS[20], Brew[18], J2ME[14], Mophun[17]. De todas ellas, el sistema operativo Symbian OS

Actas Actas de las XIII XIII Jornad Jornadas as de Concur Concurre renci ncia a y Sistem Sistemas as Distri Distribui buidos dos,, pp.259 pp.259-26 -269 9 ISBN: 84-9732-432-3 © 2005 Los autores, Thomson

260

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

tiene dos características que posiblemente lo harán destacarse a medio plazo. Por una parte, su diseño se realizó directamente para terminales móviles, en lugar de ser una adaptación de otro sistema existente. Por otra parte, no está ligado a un único fabricante, sino que es fruto de un consorcio en el que participan la mayoría de ellos. En este artículo se lleva a cabo un análisis del sistema operativo Symbian centrándose en el soporte que ofrece para las comunicaciones y en las decisiones adoptadas en su diseño para adaptarse a las peculiaridades de los terminales móviles. El objetivo es dar una visión de los aspectos más relevantes que deben conocer los desarrolladores de nuevos servicios telemáticos. La organización del artículo es la siguiente. En la sección 2 se describe la arquitectura del sistema operativo. En la sección 3 se describe el modelo de programación de objetos activos y las  particularidades de la programación sobre Symbian. La sección 4 trata la problemática asociada a los contextos PDP y el uso de NAT por   parte de los operadores. En la sección 5 se discuten aspectos de rendimiento de las comunicaciones a partir de experiencias de  proyectos concretos. Finalmente se presentan las conclusiones.

Java, OPL y C++. Siendo este último el lenguaje nativo de Symbian y el que proporciona acceso a un mayor número de funcionalidades. Existen diferentes SDKs (Software Development Kit) para el desarrollo. El SDK   proporciona las herramientas y la documentación necesarias para el desarrollo de aplicaciones en Symbian y un emulador del terminal móvil para PC. Los distintos SDKs están ligados a diferentes  plataformas. Cada una de estas plataformas  proporciona una interfaz de usuario y un conjunto de aplicaciones del sistema para mensajería, telefonía, multimedia, agenda y otras tareas, que  permite a los diferentes fabricantes personalizar  sus entornos de desarrollo. Estas aplicaciones hacen uso de los motores de aplicación genéricos  proporcionados por Symbian OS. Las principales  plataformas existentes son UIQ, Nokia Serie 60 y  Nokia Communicator.

2. Visión general de Symbian OS El consorcio Symbian fue constituido en 1998 y esta integrado por los principales fabricantes del sector de la telefonía móvil Fig 1. Su objetivo de  partida fue el desarrollo de un sistema operativo específico para teléfonos móviles con capacidad  para la comunicación de datos. Symbian OS se asienta en la experiencia de Psion en el desarrollo de EPOC, el primer sistema operativo verdaderamente enfocado hacia terminales móviles con capacidades para comunicaciones. Symbian OS es actualmente un sistema operativo multitarea de 32 bits basado en ROM con una arquitectura de micro-kernel altamente modular que ofrece numerosas APIs (Application Programming Interfaces) para el desarrollo de aplicaciones de comunicaciones y soporta los  principales estándares de la industria inalámbrica WAP, XHTML, J2ME, MIDP, MMS, Bluetooth, GPRS, CDMA, SyncML, IPv6, IPsec, etc. Para la programación de aplicaciones se  pueden utilizar distintos lenguajes: Visual Basic,

Figura 1. Fabricantes de teléfonos móviles con licencia Symbian en 2005

2.1. Arquitectura en capas

El sistema operativo Symbian presenta una estructura en capas (Fig 2). La capa base constituye el núcleo de Symbian y está formada por las librerías de usuario, el servidor de ficheros, el microkernel, y los controladores de dispositivos. El microkernel separa el núcleo funcional del sistema operativo de extensiones y partes específicas del sistema. El tamaño del núcleo del kernel en Symbian OS constituye aproximadamente un 5% del tamaño total del sistema operativo. Esta separación proporciona al sistema una alta modularidad y mejora la  portabilidad, el refinamiento y la personalización

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

de la plataforma. Las funciones que no se pueden incluir en el microkernel debido a su complejidad son separadas en servidores internos. Los servidores internos extienden la funcionalidad del núcleo. El kernel se ejecuta en modo privilegiado,  posee los controladores de dispositivos, implementa la política de planificación, gestiona el consumo de potencia y la asignación de memoria tanto para él como para los procesos que se ejecutan en modo usuario. Se ejecuta nativamente sobre núcleos ARM (menor consumo que los procesadores x86 de Intel y mejor relación rendimiento-precio). El kernel implementa un marco de trabajo de paso de mensajes usado para la comunicación cliente-servidor.

Figura 2.

261

Los subsistemas más destacados, en cuanto a la funcionalidad que ofrecen, son el de telefonía, el de comunicaciones y el de mensajería. El subsistema de telefonía proporciona un API multimodo para sus clientes. Entres las redes móviles abstraídas se encuentras GSM, GPRS, EDGE, CDMA (IS-95) , 3GPP cdma2000 y 3GPP W-CDMA. El subsistema de comunicaciones proporciona el marco de trabajo y los servicios del sistema  para las comunicaciones y el establecimiento de conexiones de red. Este subsistema será analizado con más detalle en el siguiente apartado. El marco de trabajo de mensajería proporciona soporte para los protocolos de envió y recepción de SMS (Short Message Service), EMS (Enhanced Message System), MMS (Multimedia Message System), correo electrónico y fax.

Arquitectura en capas de Symbian

262

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

3. Desarrollo de servicios para Internet Una de las características más representativas de Symbian OS es que se trata de un sistema operativo orientado al manejo de eventos en lugar  de al manejo de hebras. Aunque la programación multihebra está soportada y es usada internamente en el sistema operativo, para las aplicaciones se recomienda evitar su uso debido a la sobrecarga que introducen, ya que, en principio, en una aplicación basada en eventos no se necesitaría realizar ningún cambio de contexto, con lo cual la sobrecarga, en este caso, sería menor que si se emplearan hebras. A continuación se analizarán algunas de los aspectos más relevantes de Symbian, como son el concepto de objeto activo y las técnicas de gestión de memoria usadas. 3.1. Modelo de programación: Objetos Activos

Un objeto activo es una entidad manejadora de eventos. Un planificador coordina los diferentes objetos activos existentes para gestionar los eventos procedentes del terminal y de las aplicaciones. Cada objeto activo tiene una función virtual llamada RunL(). Esta función es atómica y es llamada cuando tiene lugar un evento del cual el objeto activo es responsable. Dentro de esta función se lleva a cabo un preprocesamiento del evento para identificarlo y actuar en consecuencia. Los objetos activos son planificados en función de su prioridad al igual que las hebras. La  planificación de los objetos activos se lleva a cabo de forma no expropiativa, es decir, la  planificación sólo se lleva a cabo cuando la función RunL() en ejecución se ha completado, en este momento el objeto activo con mayor   prioridad que esté esperando pasa a ejecutarse, si no existe ningún objeto activo el sistema operativo se mantiene a la espera de nuevos eventos. De esta forma al no planificarse expropiativamente no es necesaria la utilización de semáforos, secciones críticas u otras técnicas de sincronización, que implican una sobrecarga significativa del sistema. La elección de un sistema basado en eventos también influye en el ahorro de batería ya que el sistema sólo actúa cuando se produce un evento, mientras tanto el sistema se mantiene a la espera sin consumir ningún ciclo del procesador y por 

tanto batería. Esta forma de operar es diferente a la de los de los sistemas orientados al manejo de hebras en los cuales se llevan a cabos sondeos  para detectar si en algunas de las hebras se ha  producido algún cambio, y por tanto existe consumo de batería en periodos en los que en teoría el sistema no debería estar operando. 3.2. Arquitectura cliente-servidor

La arquitectura cliente-servidor es otra de las claves del diseño de Symbian OS. Las aplicaciones de los usuarios y los procesos del sistema son clientes que comparten los recursos de una amplia variedad de servidores del sistema. Prácticamente todos los servidores se ejecutan con una prioridad alta, pero sin privilegios para asegurar una respuesta puntual a sus clientes mientras controlan el acceso a los recursos del sistema. La arquitectura cliente servidor permite mejorar la extensibilidad (a través del uso de  plugins), la eficiencia (varios clientes pueden ser  atendidos por el mismo servidor), la seguridad (los servidores y sus clientes se ejecutan en  procesos separados y se comunican a través de un mecanismo de paso de mensajes proporcionado  por el kernel,) y la asincronía (los servidores son implementados a través de objetos activos de forma que los clientes se suspenden mientras esperan a que sus peticiones sean atendidas en lugar de llevar a cabo sondeos para comprobar el estado de esta, con la consecuente reducción en el número de ciclos de procesador necesarios para atenderla). 3.3. Mecanismos de gestión de memoria

A la hora de programar en Symbian es necesario tener en cuenta ciertas peculiaridades que ayudan a evitar errores y a entender mejor su estilo de  programación.  Pila Existen ciertas divergencias entre el espacio de pila disponible en el emulador para PC y el disponible en el terminal. El tamaño de la pila en el emulador para PC no está limitado como ocurre en el terminal ya que se usa la propia pila de Windows. Para prevenir desbordamientos de la

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

 pila es recomendable localizar los descriptores en el heap, usar únicamente objetos automáticos para datos y cadenas de pequeño tamaño y evitar   programar recursivamente (si esto último fuera inevitable deberían ser minimizados los tamaños de los parámetros pasados y de las variables automáticas usadas en la parte recursiva). CleanUp Stack  En un sistema limitado en memoria como es un teléfono móvil se debe prestar especial atención a la gestión de la memoria, para este fin Symbian implementa un mecanismo propio denominado Cleanup Stack. El Cleanup Stack es una pila especial que almacena los punteros a los objetos que necesitan ser liberados cuando ocurre una excepción. Todas las aplicaciones tienen su propio Cleanup Stack  que es creado por defecto. Cualquier puntero definido localmente que apunte a un objeto localizado en el heap debe ser  añadido al Cleanup Stack si existe riesgo de que una excepción tenga lugar y no hay ninguna otra referencia al objeto. Si no tiene lugar ninguna excepción los punteros deberán ser borrados de la  pila por el programador. Los datos pertenecientes a las instancias de una clase no pueden ser añadidos al Cleanup Stack ya que son eliminados por el destructor de la clase.

263

excepciones de Symbian está adaptado a las normas de programación usadas en Symbian (clases C, clases T, códigos de error de 32 bits…) con esto se evita la sobrecarga introducida por el mecanismo de manejo de excepciones de C++ (try, catch y throw). El manejo de excepciones empleado en Symbian se basa fundamentalmente en la macro TRAP y sus variantes (p.e. TRAPD permite que el código se ejecute en un ambiente protegido (trap harness)) y en la llamada User::Leave() la cual, en caso de malfuncionamiento, termina la ejecución de la función actual y devuelve el código del error.  Procesador  Los procesadores de los dispositivos más recientes son procesadores RISC con frecuencias de reloj que rondan los 200MHz, frecuencia que resulta adecuada para la mayoría de las aplicaciones. Sin embargo el desarrollador debería tener en mente que los procesadores no disponen de unidad de punto flotante (UPF). Por este motivo se recomienda evitar en la medida de lo  posible el uso de notación en punto flotante, ya que la velocidad de ejecución de la aplicación  podría experimentar una disminución considerable.

3.4. Subsistema de comunicaciones

Construcción en dos fases Por el mismo motivo que antes los constructores y los destructores de los objetos no  pueden generar excepciones ya que si esto ocurre se podrían producir fugas de memoria. Para solucionar esto la construcción de objetos se lleva a cabo en dos fases. En una primera fase se  procede a la inicialización del objeto y en una segunda fase, y usando el CleanUp Stack, se lleva a cabo la asignación de memoria, de forma que si en esta fase se produjera alguna excepción la memoria asignada hasta ese momento sería correctamente liberada.  Manejo de excepciones Symbian proporciona sus propios mecanismos  para el manejo de excepciones. El sistema de

El subsistema de comunicaciones de Symbian OS  proporciona los siguientes servicios: •

•

•

Gestor de base de datos que se encarga de controlar la configuración de todo el sistema de comunicaciones. Servidor de sockets y un API de cliente que  permite la implementación de distintos  protocolos de comunicación a través del interfaz de sockets. Los protocolos pueden ser cargados dinámicamente a través de  plugins. Administrador de red que proporciona el marco de trabajo para la conexión con otros ordenadores o redes. El administrador   proporciona los mecanismos necesarios para que el cliente pueda monitorizar el progreso a través de, por ejemplo, una conexión PPP.

264

•

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

Servidor de comunicaciones serie que  proporciona la abstracción de un puerto serie (RS232C) lo que permite a los teléfonos Symbian actuar como un DCE y un DTE. Los módulos de comunicación se pueden cargar  dinámicamente para comunicarse con los controladores y las diferentes pilas de  protocolos.

Symbian proporciona una pila dual que soporta tanto IPv4 como IPv6. La pila IP  proporciona una arquitectura basada en plugins que permite la implementación de extensiones. Los plugins pueden interactuar con los niveles OSI 2, 3 y 4, y pueden ser instalados, cargados y descargados y en tiempo de ejecución. Uno de los plugin más destacados es el IPSec, para la seguridad en las comunicaciones. 3.5. Contextos PDP (Packet Data Protocol)

Para el establecimiento de una comunicación de datos a través de GPRS el usuario debe  proporcionar los datos de la sesión y enviar la  petición a la red. Para establecer una sesión con una red de paquetes (PDN) como Internet se debe aportar una descripción de las características del flujo de datos que se desea establecer y la red GSM/GPRS en función los datos recibidos analizará la viabilidad del establecimiento de dicho flujo de datos. Se denomina contexto PDP a la conexión entre el terminal de usuario y la GGSN (Gateway GPRS Support Node) del operador. Para el establecimiento de esta conexión es necesario el envío de un paquete de activación del contexto PDP en el que se incluye información acerca del tipo de red de paquetes de datos (p. e IPv4), la dirección de red asignada (p.e. una dirección IPv4 192.168.2.1), los requerimientos de calidad de servicio (QoS) y el nombre del punto de acceso (APN), a través del cual el tráfico será enrutado hacia la red de paquetes de datos. Actualmente el campo de la dirección IP se envía en blanco y es el operador el encargado de asignar una dirección IP dinámica que puede ser pública o privada, implicando esta última opción la imposibilidad de establecer comunicaciones directas entre terminales.

Un terminal móvil puede tener más de un contexto PDP activo a la vez, y tener por tanto más de una dirección IP, lo que a todo los efectos supone tener más de un interfaz de red. Es decir, si un terminal móvil soporta varios contextos PDP un navegador WAP puede usar un punto de acceso para wap mientras un cliente de correo usa un punto de acceso GPRS, y estar ambas aplicaciones conectadas y transmitiendo datos. Cuando el terminal está negociando con la red el establecimiento de una sesión de datos se debe especificar el nombre del punto de acceso (APN). El punto de acceso puede identificar un servicio o una red externa (p.e. Internet) y suele expresarse a través de un identificador de red que no es más que la URL usada por el SGSN (Serving GPRS Support Node) para consultar en el DNS del operador la GGSN que proporciona el APN solicitado por el cliente. Este mecanismo permite enrutar el tráfico desde y hacia la intranet del operador.

4. Eficiencia de las comunicaciones A la hora de evaluar las características de la comunicación sobre Symbian, se ha aprovechado la experiencia obtenida en la evaluación de aplicaciones sobre otras plataformas como Mophun [1][2][3]. Los resultados obtenidos para dichas plataformas han ayudado a identificar  aspectos de interés y puntos fuertes de Symbian OS.

Figura 3.

Escenario de captura de tráfico

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 4.1. Escenarios de captura de tráfico

Durante las primeras fases del desarrollo de una aplicación las pruebas se realizan normalmente utilizando un emulador sobre un PC. Este tipo de herramienta resulta apropiado en primera instancia al no requerirse de terminales reales, pero por otro lado puede enmascarar posibles limitaciones de las implementaciones en terminales reales. Sin embargo, para analizar el comportamiento de una aplicación sobre un terminal real, es necesario utilizar una configuración como la de la Fig. 3. Para reproducir un escenario habitual, se ha utilizado un equipo conectado a Internet a través de un router ADSL, la transmisión de datos con el terminal móvil se realiza mediante una conexión GPRS, la red GPRS empleadas es una red en explotación. El tráfico generado por la aplicación se ha capturado utilizando un analizador de protocolos en la red local del equipo servidor. 4.2. Pruebas con terminales Symbian

Para la realización de pruebas con terminales reales se han utilizado los teléfonos Nokia 6600 y  Nokia 7610 que incorporan la versión 7.0 de Symbian OS. Con el objetivo de caracterizar el comportamiento de las comunicaciones se ha utilizado una aplicación de FTP para generar dos tipos de tráfico diferenciados: interactivo e intensivo. El tráfico interactivo se caracteriza por el envío de mensajes de tamaño reducido en ambos sentidos. La latencia en la transmisión, y no el throughput, es el parámetro más importante en una comunicación de este tipo, ya que el diálogo entre las dos partes requiere para avanzar de un intercambio continuo en ambos sentidos. Este tipo de comportamiento se ajusta al proporcionado por  la conexión de control FTP, ya que el protocolo se  basa en la transmisión de peticiones y respuestas de pequeño tamaño (normalmente menor de 64  bytes). En la Fig. 4 se muestra la evolución del tiempo de ida y vuelta (Round Trip Time) de una conexión de control FTP. También puede observarse cómo para determinados grupos de paquetes el tiempo de ida y vuelta es mayor. Esto se debe a que,  paralelamente a la conexión de control FTP,

265

eventualmente se establecen conexiones de datos. La finalidad de estas conexiones de datos es la transferencia de datos de tamaño algo mayor, como listados de directorios. Aunque los datos transmitidos en estas conexiones son menos de 264 bytes en las pruebas realizadas se ha observado que el tiempo de ida y vuelta se llega a incrementar en más 500 ms con respecto al valor  típico. Para conseguir mejorar los tiempos de respuesta de las aplicaciones resulta necesario reducir al mínimo posible el tamaño de los mensajes enviados. En la Fig.4 se puede observar que el tiempo de ida y vuelta máximo llega a ser de 2,8 segundos. Aprovechando que las implementaciones  probadas de TCP soportan la utilización de marcas de tiempo se ha podido llegar a la conclusión de que este excesivo retardo se ha originado en el sentido del terminal móvil al servidor. La causa de este retraso puede estar en el mecanismo de retransmisión que incorporan los protocolos de acceso radio para ofrecer una transmisión de datos fiable ante eventuales pérdidas de tramas. Por otro lado, el tráfico intensivo se caracteriza por el envío continuo de datos en el mismo sentido de transmisión. El tamaño de los mensajes es mayor que en el tráfico interactivo. Para estudiar este tipo de transmisiones se han analizado las conexiones de datos para la descarga de ficheros vía FTP. En las siguientes gráficas se representa la transferencia de un fichero de 70 KBytes. Como se aprecia en la Fig. 5, el tiempo de ida y vuelta medio para una conexión de datos es mayor que para la conexión de control (unos 2 segundos), pero esto no es crítico, ya que en este caso la magnitud que determina la percepción que el usuario tiene del rendimiento es el tiempo total de transferencia, que está estrechamente relacionado con el throughput. El throughput medio observado en la Fig. 6 es de unos 27kbps, tardándose 20,5 segundos en transmitir los 70KBytes del fichero. Para archivos de mayor tamaño podría resultar algo mayor, ya que durante la transferencia llegan a alcanzarse los 32kbps. La Fig.7 representa la evolución de los números de secuencia enviados y confirmados. En la aplicación utilizada los ficheros se envían en  bloques de 4096 bytes, pero estos se fragmentan en segmentos TCP de tamaño máximo 1356 bytes.

266

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

Figura 4.

Figura 5.

Tiempo de ida y vuelta de una conexión de control Ftp

Evolución de la conexión de datos de una sesión Ftp

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

Puede apreciarse cómo el tamaño de la ventana de recepción del terminal móvil tiene un tamaño considerable, 48KBytes. Disponer de una ventana de recepción suficientemente grande  permite obtener un buen aprovechamiento de la conexión GPRS, al posibilitarse el envío de múltiples mensajes simultáneamente por parte del emisor. 4.3. Pruebas con otra plataforma

Para hacernos una idea más precisa de la bondad de Symbian OS en lo referido a comunicaciones, resulta adecuado realizar una comparación con otras plataformas que permitan la ejecución de aplicaciones. Una tendencia muy común actualmente es la utilización de máquinas virtuales para conseguir una mayor portabilidad, un ejemplo de ello es Mophun. Se han realizado  pruebas similares a las anteriores utilizando los terminales T310 y T610 de SonyEricsson.

Figura 6.

267

Como resultado de las pruebas realizadas se ha detectado que existe un problema en el interfaz entre la pila de comunicaciones TCP/IP del terminal y la aplicación Mophun cuando los mensajes intercambiados no son de tamaño reducido. El problema detectado consiste en que, cuando una aplicación que corre sobre el terminal móvil está recibiendo datos, la aplicación deja de recibir datos sin motivo aparente. Las implementaciones probadas presentan limitaciones en el tamaño máximo de bloque leído, que es de 255 bytes. Así, al disponer los terminales utilizados de una ventana de recepción de 1536 bytes (bastante más reducida que en los terminales Symbian utilizados), la aplicación debe realizar varias lecturas para poder leer todos los datos disponibles. Aunque a partir de los retardos de transmisión observados la comunicación podría ser moderadamente más rápida, los retardos en el interfaz con la aplicación y la reducción del tamaño de los mensajes enviados para garantizar  la fiabilidad reduce el rendimiento considerablemente, obteniéndose un throughput menor de 3 kbps.

Throughput de una conexión de datos Ftp

268

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

Figura 7.

Evolución de la conexión de datos de una sesión FTP

Cuando la ventana de recepción se llena, tras varias lecturas consecutivas se llega a un estado en el que no se informa a la aplicación de que quedan datos disponibles. Sin embargo, analizando el tráfico generado, se observa que en la ventana de recepción todavía hay datos que no han sido entregados a la aplicación. Para evitar  esto los bloques de datos intercambiados a nivel de aplicación deben ser de tamaño reducido. Una importante deficiencia encontrada reside en que la interacción con la aplicación introduce mucho retardo en las comunicaciones, una confirmación a nivel de aplicación acarrea un retardo unos 600ms mayor que el asociado a las confirmaciones propias de TCP. Esto contrasta claramente con los resultados obtenidos para Symbian donde no da tiempo a que se envíen mensajes únicamente de confirmación TCP cuando se responde a nivel de aplicación. Resulta aparente que el interfaz entre la capa de comunicaciones y la aplicación es mucho más fluido en Symbian.

5. Conclusiones Debido a la especial problemática de las  plataformas móviles, resulta necesario llevar a cabo un análisis de las comunicaciones a distintos niveles para detectar posibles cuellos de botella y causas de error para las aplicaciones. A la vista de las pruebas realizadas, se ha puesto de manifiesto que en entornos de ejecución de tipo máquina virtual es necesario tener en cuenta posibles deficiencias y pérdidas de rendimiento en el acceso a las funciones propias de los terminales. Symbian es un sistema operativo que ha demostrado ser altamente eficiente, permitiendo el desarrollo de aplicaciones en el lenguaje nativo del terminal, por lo que desde el punto de vista del rendimiento resulta ser una buena base para el desarrollo de aplicaciones de comunicación. Aunque desde el punto de vista del desarrollador Symbian presenta carencias en la documentación de las APIS (escasez de ejemplos, funciones no documentadas, funciones que si

XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)

están documentadas pero no están implementadas…) como en las herramientas de depuración, tanto para el terminal como para el emulador. Por otra parte, los retardos observados en las conexiones GPRS sobre Symbian pueden ser  excesivos para aplicaciones sujetas a requisitos estrictos de tiempo real (como aplicaciones de voz sobre IP), sobre todo si el tráfico generado es fuertemente bidireccional (full-duplex). Sin embargo, ya que el throughput obtenido es  bastante alto, se abre la posibilidad para el desarrollo de aplicaciones con requisitos más relajados como el streaming (que admite latencias mayores pero con jitter acotado) o el Push To Talk  (punto a multipunto). Uno de los puntos hacia los que se enfocarán futuros trabajos es al análisis de las prestaciones obtenidas para aplicaciones sobre terminales UMTS Symbian, donde es posible especificar  distintos grados de calidad de servicio para ajustarse a necesidades específicas.

Referencias [1] Almudena Díaz PFC “Cliente de Correo para teléfonos móviles” ETSIT Universidad de Málaga. 2004 [2] F. Javier Rivas PFC “Plataforma móvil para acceso a servicios domóticos” ETSIT Universidad de Málaga. 2004 [3] Juan C. Cuevas, Pedro Merino, F. Javier  Rivas, Pedro J. Reche “Migrando una aplicación domótica a entornos móviles” XIV Jornadas Telecom I+D 2004 [4] Leigh Edwars, Richard Barker, and the Staff  of EMCC of Software Ltd. “Developing Series 60 Applications. A Guide for Symbian OS C++ Developers” Addison Wesley, 2004

269

[5] Richard Harrison “Symbian OS C++ for  Mobile Phones” Ed. John Wiley and Sons, LTD.2003 [6] Digia Inc “Programming for the Series 60 Platform and Symbian OS” Ed. John Wiley and Sons, LTD. 2002 [7] Kevin Dixon ”Symbian OS Version 7.0s. Functional description” Revision 2.1, Junio 2003, Symbian Ltd. [8] RFC 3235 “Network Address Translator  (NAT)-Friendly Design Guidelines” 2002 [9] ] RFC 3314 “Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standars” 2002 [10] The 3G Partnership Project: http://www.3gpp.org [11] Symbian OS - the mobile operating system: www.symbian.com [12] Forum Nokia - Developer Resources www.forum.nokia.com [13] NewLC, the Symbian OS C++ developer   portal: www.newlc.com [14] Sun Developer Network Site: http://developers.sun.com/techtopics/mobility/ [15] Embedded Linux Consortium: http://www.embedded-linux.org [16] Mophun web site: http://www.mophun.com [17] Qualcomm brew home: http://brew.qualcomm.com/brew/es/ [18] Microsoft Windows Embedded Developer  Center: http://msdn.microsoft.com/embedded/default. aspx [19] Blackberry Developer Home: http://www.blackberry.com/developers/index. shtml