Your SlideShare is downloading. ×
Descripcion del S.O. Symbian para el desarrollo de aplicaciones en la red GPRS
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Descripcion del S.O. Symbian para el desarrollo de aplicaciones en la red GPRS

352
views

Published on

Published in: Devices & Hardware

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
352
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Análisis de Symbian OS para desarrollar aplicacionesdistribuidas sobre terminales GPRSAlmudena Díaz, Pedro Merino, Fº Javier RivasDept. de Lenguajes y Ciencias de la ComputaciónETSI de TelecomunicaciónUniv. de Málaga29071 Málaga{almudiaz,pedro}@lcc.uma.es, javier_rivas@eresmas.comResumenEl papel que desempeñan los teléfonos móviles enen el ámbito de los sistemas distribuidos haevolucionado en los últimos años hasta llegar aconvertirse en entornos en los que se puedendesarrollar complejas aplicaciones. Por esta razónhan surgido numerosas plataformas, tales comoSymbian, cuyo objetivo es adaptarse a laslimitaciones de los terminales móviles y proveeral desarrollador de las herramientas necesariaspara la programación de aplicaciones enterminales móviles. Symbian OS es un sistemaoperativo especialmente diseñado para adaptarse alos requerimientos de un teléfono móvil. En esteartículo se revisan loas aspectos que pueden tenermás impacto en las aplicaciones desarrolladassobre este sistema operativo en los terminalesGPRS actuales. También se lleva a cabo unaevaluación cuantitativa de las comunicaciones dedatos sobre dicha plataforma que permite extraerconclusiones acerca de la experiencia de losusuarios de aplicaciones en terminales móviles.1. IntroducciónLos teléfonos móviles con tecnología GPRS(General Packet Radio Service) o UMTS(Universal Mobile Telecommunications System)comienzan a sustituir a los ordenadores personalescomo terminales de Internet tanto en usoprofesional como de ocio. Sin embargo, al tratarsede dispositivos con características propias comolas limitaciones de memoria, CPU o bateríaresulta necesario desarrollar nuevos sistemasoperativos y entornos de desarrollo específicosque se ajusten a las exigencias de dichosterminales.En este artículo se revisan nuestrasexperiencias con el sistema operativo SymbianOS, tanto desde el punto de vista del desarrolladorcomo de las prestaciones que ofrecen al usuariofinal. En este trabajo nos centramos en losaspectos que se han revelado críticos para mejorarla percepción del usuario cuando emplea TCP/IPsobre estos terminales. Muchas de las experienciasprovienen de desarrollos recientes como clientesde correo [1] y clientes para domótica [2][3] paraterminales móviles.Las velocidades proporcionadas por GPRShan propiciado el desarrollo de aplicaciones quehacen un uso intensivo de las comunicaciones.Con la reciente puesta en marcha de UMTS lasvelocidades medias alcanzadas pueden llegarhasta los 384 kbits. Esto junto con las elevadasprestaciones de los teléfonos de últimageneración, usualmente llamados smartphones,permite el desarrollo aplicaciones multimedia queexplotan el concepto de movilidad en su sentidomás amplio.En este escenario han ido surgiendo una granvariedad de sistemas operativos y plataformasorientadas al desarrollo de aplicaciones paradispositivos móviles: Symbian OS [12], LinuxEmbedded[16], Microsoft CE[19], BlackberryOS[20], Brew[18], J2ME[14], Mophun[17]. Detodas ellas, el sistema operativo Symbian OSActas de las XIII Jornadas de Concurrencia y Sistemas Distribuidos, pp.259-269ISBN: 84-9732-432-3 © 2005 Los autores, Thomson
  • 2. tiene dos características que posiblemente lo harándestacarse a medio plazo. Por una parte, su diseñose realizó directamente para terminales móviles,en lugar de ser una adaptación de otro sistemaexistente. Por otra parte, no está ligado a un únicofabricante, sino que es fruto de un consorcio en elque participan la mayoría de ellos.En este artículo se lleva a cabo un análisis delsistema operativo Symbian centrándose en elsoporte que ofrece para las comunicaciones y enlas decisiones adoptadas en su diseño paraadaptarse a las peculiaridades de los terminalesmóviles. El objetivo es dar una visión de losaspectos más relevantes que deben conocer losdesarrolladores de nuevos servicios telemáticos.La organización del artículo es la siguiente.En la sección 2 se describe la arquitectura delsistema operativo. En la sección 3 se describe elmodelo de programación de objetos activos y lasparticularidades de la programación sobreSymbian. La sección 4 trata la problemáticaasociada a los contextos PDP y el uso de NAT porparte de los operadores. En la sección 5 sediscuten aspectos de rendimiento de lascomunicaciones a partir de experiencias deproyectos concretos. Finalmente se presentan lasconclusiones.2. Visión general de Symbian OSEl consorcio Symbian fue constituido en 1998 yesta integrado por los principales fabricantes delsector de la telefonía móvil Fig 1. Su objetivo departida fue el desarrollo de un sistema operativoespecífico para teléfonos móviles con capacidadpara la comunicación de datos. Symbian OS seasienta en la experiencia de Psion en el desarrollode EPOC, el primer sistema operativoverdaderamente enfocado hacia terminalesmóviles con capacidades para comunicaciones.Symbian OS es actualmente un sistemaoperativo multitarea de 32 bits basado en ROMcon una arquitectura de micro-kernel altamentemodular que ofrece numerosas APIs (ApplicationProgramming Interfaces) para el desarrollo deaplicaciones de comunicaciones y soporta losprincipales estándares de la industria inalámbricaWAP, XHTML, J2ME, MIDP, MMS, Bluetooth,GPRS, CDMA, SyncML, IPv6, IPsec, etc.Para la programación de aplicaciones sepueden utilizar distintos lenguajes: Visual Basic,Java, OPL y C++. Siendo este último el lenguajenativo de Symbian y el que proporciona acceso aun mayor número de funcionalidades.Existen diferentes SDKs (SoftwareDevelopment Kit) para el desarrollo. El SDKproporciona las herramientas y la documentaciónnecesarias para el desarrollo de aplicaciones enSymbian y un emulador del terminal móvil paraPC. Los distintos SDKs están ligados a diferentesplataformas. Cada una de estas plataformasproporciona una interfaz de usuario y un conjuntode aplicaciones del sistema para mensajería,telefonía, multimedia, agenda y otras tareas, quepermite a los diferentes fabricantes personalizarsus entornos de desarrollo. Estas aplicacioneshacen uso de los motores de aplicación genéricosproporcionados por Symbian OS. Las principalesplataformas existentes son UIQ, Nokia Serie 60 yNokia Communicator.Figura 1. Fabricantes de teléfonos móviles con licenciaSymbian en 20052.1. Arquitectura en capasEl sistema operativo Symbian presenta unaestructura en capas (Fig 2).La capa base constituye el núcleo de Symbiany está formada por las librerías de usuario, elservidor de ficheros, el microkernel, y loscontroladores de dispositivos.El microkernel separa el núcleo funcional delsistema operativo de extensiones y partesespecíficas del sistema. El tamaño del núcleo delkernel en Symbian OS constituyeaproximadamente un 5% del tamaño total delsistema operativo. Esta separación proporciona alsistema una alta modularidad y mejora laportabilidad, el refinamiento y la personalización260 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)
  • 3. de la plataforma. Las funciones que no se puedenincluir en el microkernel debido a su complejidadson separadas en servidores internos. Losservidores internos extienden la funcionalidad delnúcleo.El kernel se ejecuta en modo privilegiado,posee los controladores de dispositivos,implementa la política de planificación, gestionael consumo de potencia y la asignación dememoria tanto para él como para los procesos quese ejecutan en modo usuario. Se ejecutanativamente sobre núcleos ARM (menor consumoque los procesadores x86 de Intel y mejor relaciónrendimiento-precio). El kernel implementa unmarco de trabajo de paso de mensajes usado parala comunicación cliente-servidor.Los subsistemas más destacados, en cuanto ala funcionalidad que ofrecen, son el de telefonía,el de comunicaciones y el de mensajería.El subsistema de telefonía proporciona un APImultimodo para sus clientes. Entres las redesmóviles abstraídas se encuentras GSM, GPRS,EDGE, CDMA (IS-95) , 3GPP cdma2000 y 3GPPW-CDMA.El subsistema de comunicaciones proporcionael marco de trabajo y los servicios del sistemapara las comunicaciones y el establecimiento deconexiones de red. Este subsistema será analizadocon más detalle en el siguiente apartado.El marco de trabajo de mensajería proporcionasoporte para los protocolos de envió y recepciónde SMS (Short Message Service), EMS(Enhanced Message System), MMS (MultimediaMessage System), correo electrónico y fax.Figura 2. Arquitectura en capas de SymbianXIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 261
  • 4. 3. Desarrollo de servicios para InternetUna de las características más representativas deSymbian OS es que se trata de un sistemaoperativo orientado al manejo de eventos en lugarde al manejo de hebras. Aunque la programaciónmultihebra está soportada y es usada internamenteen el sistema operativo, para las aplicaciones serecomienda evitar su uso debido a la sobrecargaque introducen, ya que, en principio, en unaaplicación basada en eventos no se necesitaríarealizar ningún cambio de contexto, con lo cual lasobrecarga, en este caso, sería menor que si seemplearan hebras.A continuación se analizarán algunas de losaspectos más relevantes de Symbian, como son elconcepto de objeto activo y las técnicas de gestiónde memoria usadas.3.1. Modelo de programación: Objetos ActivosUn objeto activo es una entidad manejadora deeventos. Un planificador coordina los diferentesobjetos activos existentes para gestionar loseventos procedentes del terminal y de lasaplicaciones. Cada objeto activo tiene una funciónvirtual llamada RunL(). Esta función es atómica yes llamada cuando tiene lugar un evento del cualel objeto activo es responsable. Dentro de estafunción se lleva a cabo un preprocesamiento delevento para identificarlo y actuar en consecuencia.Los objetos activos son planificados enfunción de su prioridad al igual que las hebras. Laplanificación de los objetos activos se lleva a cabode forma no expropiativa, es decir, laplanificación sólo se lleva a cabo cuando lafunción RunL() en ejecución se ha completado, eneste momento el objeto activo con mayorprioridad que esté esperando pasa a ejecutarse, sino existe ningún objeto activo el sistema operativose mantiene a la espera de nuevos eventos.De esta forma al no planificarseexpropiativamente no es necesaria la utilizaciónde semáforos, secciones críticas u otras técnicasde sincronización, que implican una sobrecargasignificativa del sistema.La elección de un sistema basado en eventostambién influye en el ahorro de batería ya que elsistema sólo actúa cuando se produce un evento,mientras tanto el sistema se mantiene a la esperasin consumir ningún ciclo del procesador y portanto batería. Esta forma de operar es diferente ala de los de los sistemas orientados al manejo dehebras en los cuales se llevan a cabos sondeospara detectar si en algunas de las hebras se haproducido algún cambio, y por tanto existeconsumo de batería en periodos en los que enteoría el sistema no debería estar operando.3.2. Arquitectura cliente-servidorLa arquitectura cliente-servidor es otra de lasclaves del diseño de Symbian OS. Lasaplicaciones de los usuarios y los procesos delsistema son clientes que comparten los recursos deuna amplia variedad de servidores del sistema.Prácticamente todos los servidores se ejecutan conuna prioridad alta, pero sin privilegios paraasegurar una respuesta puntual a sus clientesmientras controlan el acceso a los recursos delsistema.La arquitectura cliente servidor permitemejorar la extensibilidad (a través del uso deplugins), la eficiencia (varios clientes pueden seratendidos por el mismo servidor), la seguridad(los servidores y sus clientes se ejecutan enprocesos separados y se comunican a través de unmecanismo de paso de mensajes proporcionadopor el kernel,) y la asincronía (los servidores sonimplementados a través de objetos activos deforma que los clientes se suspenden mientrasesperan a que sus peticiones sean atendidas enlugar de llevar a cabo sondeos para comprobar elestado de esta, con la consecuente reducción en elnúmero de ciclos de procesador necesarios paraatenderla).3.3. Mecanismos de gestión de memoriaA la hora de programar en Symbian es necesariotener en cuenta ciertas peculiaridades que ayudana evitar errores y a entender mejor su estilo deprogramación.PilaExisten ciertas divergencias entre el espaciode pila disponible en el emulador para PC y eldisponible en el terminal. El tamaño de la pila enel emulador para PC no está limitado como ocurreen el terminal ya que se usa la propia pila deWindows. Para prevenir desbordamientos de la262 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)
  • 5. pila es recomendable localizar los descriptores enel heap, usar únicamente objetos automáticos paradatos y cadenas de pequeño tamaño y evitarprogramar recursivamente (si esto último fuerainevitable deberían ser minimizados los tamañosde los parámetros pasados y de las variablesautomáticas usadas en la parte recursiva).CleanUp StackEn un sistema limitado en memoria como esun teléfono móvil se debe prestar especialatención a la gestión de la memoria, para este finSymbian implementa un mecanismo propiodenominado Cleanup Stack.El Cleanup Stack es una pila especial quealmacena los punteros a los objetos que necesitanser liberados cuando ocurre una excepción. Todaslas aplicaciones tienen su propio Cleanup Stackque es creado por defecto.Cualquier puntero definido localmente queapunte a un objeto localizado en el heap debe serañadido al Cleanup Stack si existe riesgo de queuna excepción tenga lugar y no hay ninguna otrareferencia al objeto. Si no tiene lugar ningunaexcepción los punteros deberán ser borrados de lapila por el programador.Los datos pertenecientes a las instancias deuna clase no pueden ser añadidos al CleanupStack ya que son eliminados por el destructor dela clase.Construcción en dos fasesPor el mismo motivo que antes losconstructores y los destructores de los objetos nopueden generar excepciones ya que si esto ocurrese podrían producir fugas de memoria. Parasolucionar esto la construcción de objetos se llevaa cabo en dos fases. En una primera fase seprocede a la inicialización del objeto y en unasegunda fase, y usando el CleanUp Stack, se llevaa cabo la asignación de memoria, de forma que sien esta fase se produjera alguna excepción lamemoria asignada hasta ese momento seríacorrectamente liberada.Manejo de excepcionesSymbian proporciona sus propios mecanismospara el manejo de excepciones. El sistema deexcepciones de Symbian está adaptado a lasnormas 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 elmecanismo de manejo de excepciones de C++(try, catch y throw).El manejo de excepciones empleado enSymbian se basa fundamentalmente en la macroTRAP y sus variantes (p.e. TRAPD permite que elcódigo se ejecute en un ambiente protegido (trapharness)) y en la llamada User::Leave() la cual, encaso de malfuncionamiento, termina la ejecuciónde la función actual y devuelve el código delerror.ProcesadorLos procesadores de los dispositivos másrecientes son procesadores RISC con frecuenciasde reloj que rondan los 200MHz, frecuencia queresulta adecuada para la mayoría de lasaplicaciones. Sin embargo el desarrollador deberíatener en mente que los procesadores no disponende unidad de punto flotante (UPF). Por estemotivo se recomienda evitar en la medida de loposible el uso de notación en punto flotante, yaque la velocidad de ejecución de la aplicaciónpodría experimentar una disminuciónconsiderable.3.4. Subsistema de comunicacionesEl subsistema de comunicaciones de Symbian OSproporciona los siguientes servicios:• Gestor de base de datos que se encarga decontrolar la configuración de todo el sistemade comunicaciones.• Servidor de sockets y un API de cliente quepermite la implementación de distintosprotocolos de comunicación a través delinterfaz de sockets. Los protocolos puedenser cargados dinámicamente a través deplugins.• Administrador de red que proporciona elmarco de trabajo para la conexión con otrosordenadores o redes. El administradorproporciona los mecanismos necesarios paraque el cliente pueda monitorizar el progreso através de, por ejemplo, una conexión PPP.XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 263
  • 6. • Servidor de comunicaciones serie queproporciona la abstracción de un puerto serie(RS232C) lo que permite a los teléfonosSymbian actuar como un DCE y un DTE. Losmódulos de comunicación se pueden cargardinámicamente para comunicarse con loscontroladores y las diferentes pilas deprotocolos.Symbian proporciona una pila dual quesoporta tanto IPv4 como IPv6. La pila IPproporciona una arquitectura basada en pluginsque permite la implementación de extensiones.Los plugins pueden interactuar con los nivelesOSI 2, 3 y 4, y pueden ser instalados, cargados ydescargados y en tiempo de ejecución. Uno delos plugin más destacados es el IPSec, para laseguridad en las comunicaciones.3.5. Contextos PDP (Packet Data Protocol)Para el establecimiento de una comunicación dedatos a través de GPRS el usuario debeproporcionar los datos de la sesión y enviar lapetición a la red. Para establecer una sesión conuna red de paquetes (PDN) como Internet se debeaportar una descripción de las características delflujo de datos que se desea establecer y la redGSM/GPRS en función los datos recibidosanalizará la viabilidad del establecimiento dedicho flujo de datos.Se denomina contexto PDP a la conexiónentre el terminal de usuario y la GGSN (GatewayGPRS Support Node) del operador. Para elestablecimiento de esta conexión es necesario elenvío de un paquete de activación del contextoPDP en el que se incluye información acerca deltipo de red de paquetes de datos (p. e IPv4), ladirección de red asignada (p.e. una dirección IPv4192.168.2.1), los requerimientos de calidad deservicio (QoS) y el nombre del punto de acceso(APN), a través del cual el tráfico será enrutadohacia la red de paquetes de datos. Actualmente elcampo de la dirección IP se envía en blanco y esel operador el encargado de asignar una direcciónIP dinámica que puede ser pública o privada,implicando esta última opción la imposibilidad deestablecer comunicaciones directas entreterminales.Un terminal móvil puede tener más de uncontexto PDP activo a la vez, y tener por tantomás de una dirección IP, lo que a todo los efectossupone tener más de un interfaz de red. Es decir,si un terminal móvil soporta varios contextos PDPun navegador WAP puede usar un punto deacceso para wap mientras un cliente de correo usaun punto de acceso GPRS, y estar ambasaplicaciones conectadas y transmitiendo datos.Cuando el terminal está negociando con la redel establecimiento de una sesión de datos se debeespecificar el nombre del punto de acceso (APN).El punto de acceso puede identificar un servicio ouna red externa (p.e. Internet) y suele expresarse através de un identificador de red que no es másque la URL usada por el SGSN (Serving GPRSSupport Node) para consultar en el DNS deloperador la GGSN que proporciona el APNsolicitado por el cliente. Este mecanismo permiteenrutar el tráfico desde y hacia la intranet deloperador.4. Eficiencia de las comunicacionesA la hora de evaluar las características de lacomunicación sobre Symbian, se ha aprovechadola experiencia obtenida en la evaluación deaplicaciones sobre otras plataformas comoMophun [1][2][3]. Los resultados obtenidos paradichas plataformas han ayudado a identificaraspectos de interés y puntos fuertes de SymbianOS.Figura 3. Escenario de captura de tráfico264 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)
  • 7. 4.1. Escenarios de captura de tráficoDurante las primeras fases del desarrollo de unaaplicación las pruebas se realizan normalmenteutilizando un emulador sobre un PC. Este tipo deherramienta resulta apropiado en primera instanciaal no requerirse de terminales reales, pero por otrolado puede enmascarar posibles limitaciones delas implementaciones en terminales reales. Sinembargo, para analizar el comportamiento de unaaplicación sobre un terminal real, es necesarioutilizar una configuración como la de la Fig. 3.Para reproducir un escenario habitual, se hautilizado un equipo conectado a Internet a travésde un router ADSL, la transmisión de datos conel terminal móvil se realiza mediante unaconexión GPRS, la red GPRS empleadas es unared en explotación. El tráfico generado por laaplicación se ha capturado utilizando unanalizador de protocolos en la red local del equiposervidor.4.2. Pruebas con terminales SymbianPara la realización de pruebas con terminalesreales se han utilizado los teléfonos Nokia 6600 yNokia 7610 que incorporan la versión 7.0 deSymbian OS.Con el objetivo de caracterizar elcomportamiento de las comunicaciones se hautilizado una aplicación de FTP para generar dostipos de tráfico diferenciados: interactivo eintensivo.El tráfico interactivo se caracteriza por elenvío de mensajes de tamaño reducido en ambossentidos. La latencia en la transmisión, y no elthroughput, es el parámetro más importante enuna comunicación de este tipo, ya que el diálogoentre las dos partes requiere para avanzar de unintercambio continuo en ambos sentidos. Este tipode comportamiento se ajusta al proporcionado porla conexión de control FTP, ya que el protocolo sebasa en la transmisión de peticiones y respuestasde pequeño tamaño (normalmente menor de 64bytes). En la Fig. 4 se muestra la evolución deltiempo de ida y vuelta (Round Trip Time) de unaconexión de control FTP.También puede observarse cómo paradeterminados grupos de paquetes el tiempo de iday vuelta es mayor. Esto se debe a que,paralelamente a la conexión de control FTP,eventualmente se establecen conexiones de datos.La finalidad de estas conexiones de datos es latransferencia de datos de tamaño algo mayor,como listados de directorios. Aunque los datostransmitidos en estas conexiones son menos de264 bytes en las pruebas realizadas se haobservado que el tiempo de ida y vuelta se llega aincrementar en más 500 ms con respecto al valortípico. Para conseguir mejorar los tiempos derespuesta de las aplicaciones resulta necesarioreducir al mínimo posible el tamaño de losmensajes enviados.En la Fig.4 se puede observar que el tiempo deida y vuelta máximo llega a ser de 2,8 segundos.Aprovechando que las implementacionesprobadas de TCP soportan la utilización de marcasde tiempo se ha podido llegar a la conclusión deque este excesivo retardo se ha originado en elsentido del terminal móvil al servidor. La causa deeste retraso puede estar en el mecanismo deretransmisión que incorporan los protocolos deacceso radio para ofrecer una transmisión de datosfiable ante eventuales pérdidas de tramas.Por otro lado, el tráfico intensivo secaracteriza por el envío continuo de datos en elmismo sentido de transmisión. El tamaño de losmensajes es mayor que en el tráfico interactivo.Para estudiar este tipo de transmisiones se hananalizado las conexiones de datos para la descargade ficheros vía FTP. En las siguientes gráficas serepresenta la transferencia de un fichero de 70KBytes.Como se aprecia en la Fig. 5, el tiempo de iday vuelta medio para una conexión de datos esmayor que para la conexión de control (unos 2segundos), pero esto no es crítico, ya que en estecaso la magnitud que determina la percepción queel usuario tiene del rendimiento es el tiempo totalde transferencia, que está estrechamenterelacionado con el throughput.El throughput medio observado en la Fig. 6 esde unos 27kbps, tardándose 20,5 segundos entransmitir los 70KBytes del fichero. Para archivosde mayor tamaño podría resultar algo mayor, yaque durante la transferencia llegan a alcanzarse los32kbps.La Fig.7 representa la evolución de losnúmeros de secuencia enviados y confirmados. Enla aplicación utilizada los ficheros se envían enbloques de 4096 bytes, pero estos se fragmentanen segmentos TCP de tamaño máximo 1356 bytes.XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 265
  • 8. Figura 4. Tiempo de ida y vuelta de una conexión de control FtpFigura 5. Evolución de la conexión de datos de una sesión Ftp266 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)
  • 9. Puede apreciarse cómo el tamaño de laventana de recepción del terminal móvil tiene untamaño considerable, 48KBytes. Disponer de unaventana de recepción suficientemente grandepermite obtener un buen aprovechamiento de laconexión GPRS, al posibilitarse el envío demúltiples mensajes simultáneamente por parte delemisor.4.3. Pruebas con otra plataformaPara hacernos una idea más precisa de la bondadde Symbian OS en lo referido a comunicaciones,resulta adecuado realizar una comparación conotras plataformas que permitan la ejecución deaplicaciones. Una tendencia muy comúnactualmente es la utilización de máquinasvirtuales para conseguir una mayor portabilidad,un ejemplo de ello es Mophun. Se han realizadopruebas similares a las anteriores utilizando losterminales T310 y T610 de SonyEricsson.Como resultado de las pruebas realizadas seha detectado que existe un problema en el interfazentre la pila de comunicaciones TCP/IP delterminal y la aplicación Mophun cuando losmensajes intercambiados no son de tamañoreducido. El problema detectado consiste en que,cuando una aplicación que corre sobre el terminalmóvil está recibiendo datos, la aplicación deja derecibir datos sin motivo aparente.Las implementaciones probadas presentanlimitaciones en el tamaño máximo de bloqueleído, que es de 255 bytes. Así, al disponer losterminales utilizados de una ventana de recepciónde 1536 bytes (bastante más reducida que en losterminales Symbian utilizados), la aplicación deberealizar varias lecturas para poder leer todos losdatos disponibles. Aunque a partir de los retardosde transmisión observados la comunicación podríaser moderadamente más rápida, los retardos en elinterfaz con la aplicación y la reducción deltamaño de los mensajes enviados para garantizarla fiabilidad reduce el rendimientoconsiderablemente, obteniéndose un throughputmenor de 3 kbps.Figura 6. Throughput de una conexión de datos FtpXIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 267
  • 10. Figura 7. Evolución de la conexión de datos de una sesión FTPCuando la ventana de recepción se llena, trasvarias lecturas consecutivas se llega a un estadoen el que no se informa a la aplicación de quequedan datos disponibles. Sin embargo,analizando el tráfico generado, se observa que enla ventana de recepción todavía hay datos que nohan sido entregados a la aplicación. Para evitaresto los bloques de datos intercambiados a nivelde aplicación deben ser de tamaño reducido.Una importante deficiencia encontrada resideen que la interacción con la aplicación introducemucho retardo en las comunicaciones, unaconfirmación a nivel de aplicación acarrea unretardo unos 600ms mayor que el asociado a lasconfirmaciones propias de TCP.Esto contrasta claramente con los resultadosobtenidos para Symbian donde no da tiempo a quese envíen mensajes únicamente de confirmaciónTCP cuando se responde a nivel de aplicación.Resulta aparente que el interfaz entre la capa decomunicaciones y la aplicación es mucho másfluido en Symbian.5. ConclusionesDebido a la especial problemática de lasplataformas móviles, resulta necesario llevar acabo un análisis de las comunicaciones a distintosniveles para detectar posibles cuellos de botella ycausas de error para las aplicaciones. A la vista delas pruebas realizadas, se ha puesto de manifiestoque en entornos de ejecución de tipo máquinavirtual es necesario tener en cuenta posiblesdeficiencias y pérdidas de rendimiento en elacceso a las funciones propias de los terminales.Symbian es un sistema operativo que hademostrado ser altamente eficiente, permitiendo eldesarrollo de aplicaciones en el lenguaje nativodel terminal, por lo que desde el punto de vista delrendimiento resulta ser una buena base para eldesarrollo de aplicaciones de comunicación.Aunque desde el punto de vista deldesarrollador Symbian presenta carencias en ladocumentación de las APIS (escasez de ejemplos,funciones no documentadas, funciones que si268 XIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005)
  • 11. están documentadas pero no estánimplementadas…) como en las herramientas dedepuración, tanto para el terminal como para elemulador.Por otra parte, los retardos observados en lasconexiones GPRS sobre Symbian pueden serexcesivos para aplicaciones sujetas a requisitosestrictos de tiempo real (como aplicaciones de vozsobre IP), sobre todo si el tráfico generado esfuertemente bidireccional (full-duplex). Sinembargo, ya que el throughput obtenido esbastante alto, se abre la posibilidad para eldesarrollo de aplicaciones con requisitos másrelajados como el streaming (que admite latenciasmayores pero con jitter acotado) o el Push To Talk(punto a multipunto).Uno de los puntos hacia los que se enfocaránfuturos trabajos es al análisis de las prestacionesobtenidas para aplicaciones sobre terminalesUMTS Symbian, donde es posible especificardistintos grados de calidad de servicio paraajustarse a necesidades específicas.Referencias[1] Almudena Díaz PFC “Cliente de Correo parateléfonos móviles” ETSIT Universidad deMálaga. 2004[2] F. Javier Rivas PFC “Plataforma móvil paraacceso a servicios domóticos” ETSITUniversidad de Málaga. 2004[3] Juan C. Cuevas, Pedro Merino, F. JavierRivas, Pedro J. Reche “Migrando unaaplicación domótica a entornos móviles” XIVJornadas Telecom I+D 2004[4] Leigh Edwars, Richard Barker, and the Staffof EMCC of Software Ltd. “DevelopingSeries 60 Applications. A Guide for SymbianOS C++ Developers” Addison Wesley, 2004[5] Richard Harrison “Symbian OS C++ forMobile Phones” Ed. John Wiley and Sons,LTD.2003[6] Digia Inc “Programming for the Series 60Platform and Symbian OS” Ed. John Wileyand Sons, LTD. 2002[7] Kevin Dixon ”Symbian OS Version 7.0s.Functional description” Revision 2.1, Junio2003, Symbian Ltd.[8] RFC 3235 “Network Address Translator(NAT)-Friendly Design Guidelines” 2002[9] ] RFC 3314 “Recommendations for IPv6 inThird 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 Resourceswww.forum.nokia.com[13] NewLC, the Symbian OS C++ developerportal: 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 DeveloperCenter:http://msdn.microsoft.com/embedded/default.aspx[19] Blackberry Developer Home:http://www.blackberry.com/developers/index.shtmlXIII Jornadas de Concurrencia y Sistemas Distribuidos (JCSD 2005) 269