ESTUDIOS DE INGENIERÍA DE TELECOMUNICACIÓN PROYECTO FIN DE CARRERA. Plataforma de Trabajo Colaborativo sobre Middleware DDS

Transcripción

1 ESTUDIOS DE INGENIERÍA DE TELECOMUNICACIÓN PROYECTO FIN DE CARRERA Plataforma de Trabajo Colaborativo sobre Middleware DDS CURSO: 07/08 José María López Vega

2

3 ESTUDIOS DE INGENIERÍA DE TELECOMUNICACIÓN Plataforma de Trabajo Colaborativo sobre Middleware DDS REALIZADO POR: José María López Vega DIRIGIDO POR: Juan Manuel López Soler DEPARTAMENTO: Teoría de la Señal, Telemática y Comunicaciones Granada, Octubre de 2008

4

5 Plataforma de Trabajo Colaborativo sobre Middleware DDS José María López Vega PALABRAS CLAVE: middleware, DDS, calidad de servicio, tiempo real, videoconferencia, multimedia, audio, video RESUMEN: El proyecto desarrollado propone una nueva aproximación para el diseño de una herramienta de trabajo colaborativo. En concreto, el sistema implementado utiliza el paradigma publicación/subscripción, para proporcionar un servicio de videoconferencia entre distintos puntos finales remotos. El diseño realizado define el concepto de sala virtual, lugar en el que los diferentes usuarios interactúan entre sí (mediante el intercambio de audio, vídeo y mensajes de texto). Por tanto, el sistema propuesto es una prueba concepto sobre la viabilidad de implementar aplicaciones de muchos a muchos con contenidos de audio/vídeo sobre middleware DDS (Data Distribution Service) [1]. DDS es un estándar de la OMG [2] cuyo objetivo es abstraer al programador de las tareas necesarias para la transmisión fiable de datos en entornos distribuidos con requisitos de tiempo-real. Con el desarrollo del proyecto se pone de manifiesto la utilidad de incorporar las así llamadas políticas de QoS (Quality of Service), que no son sino la definición de modelos de comportamiento para las entidades que generan o consumen información. KEY WORDS: middleware, DDS, quality of service, real-time, video-conference, multimedia, audio, video ABSTRACT: This project proposes a new approach for designing collaborative working systems. In particular, the implemented platform is based on the public/subscribe communications paradigm. We provide the videoconference service among remotely dispersed end-points. Our design defines the virtual-room concept, as the place where several users can be in touch (by using audio, video, and text data) In this sense, the proposed scheme is a prove of concept about the viability of developing much-tomuch communications with audio ad video contents over DDS middleware [1]. The Data Distribution Service is an OMG standard [2]. Its goal is to ease the job of application programmers regarding transmission reliability in distributed environments with real-time requirements. With this project we prove the benefits of using the so-called QoS (Quality of Services) policies. These are a set of behaviour models for DDS entities that generate or consume information.

6

7 D. Juan Manuel López Soler, Profesor Titular de Ingeniería Telemática del departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada, como director del Proyecto Fin de Carrera de D. José María López Vega. Informa: que el presente trabajo, titulado: Plataforma de Trabajo Colaborativo sobre Middleware DDS Ha sido realizado y redactado por el mencionado alumno bajo mi dirección, y con esta fecha autorizo a su presentación. Granada, a 9 de Octubre de 2008 Fdo.

8

9 Los abajo firmantes autorizan a que la presente copia de Proyecto Fin de Carrera se ubique en la Biblioteca del Centro y/o departamento para ser libremente consultada por las personas que lo deseen. Granada, a 9 de Octubre de 2008 José María López Vega Juan Manuel López Soler DNI: A DNI: C

10

11 Agradecimientos En primer lugar, me gustaría dar las gracias a mis padres, por su apoyo incondicional, sin el cual no estaría ahora escribiendo estas líneas. En segundo lugar, a Adela, por todas las noches en vela sin dormir de estos últimos días de frenética documentación, noches que sin duda recordaremos. Y lo que es más importante, por enseñarme a soñar. No puedo olvidarme tampoco de Blanca ni Laura, que de tanto creer en mí a veces consiguen que yo también crea un poco. Y por supuesto que no paso por alto a nuestro Paladín!... gracias David, por estar siempre ahí aunque ahora mismo ahí esté a km. A Juanjo, por su ayuda con los problemas con Java, así como por el apoyo e interés mostrado. A Javier (Gori), por su inestimable apoyo lingüístico y musical. A RTI por todas las facilidades que me han dado para terminar este proyecto, especialmente estos últimos días. Y por último, agradecer especialmente a Juanma, por su calidad humana, comprensión y tiempo, que ha hecho no sólo posible, sino mucho más llevadera, la realización de este proyecto. Sinceramente, gracias.

12

13 A mis padres, a Adela. Porque este proyecto es más vuestro que mío.

14

15 Índice general CAPÍTULO 0. INTRODUCCIÓN DEFINICIÓN DEL PROBLEMA OBJETIVOS RECURSOS HUMANOS HARDWARE SOFTWARE FASES DE DESARROLLO RESTRICCIONES FACTORES DATO FACTORES ESTRATÉGICOS ANTECEDENTES Y ESTADO DEL ARTE ANTECEDENTES EN PLATAFORMAS VIDEOCONFERENCIA ESTADO DEL ARTE EN PLATAFORMAS DE VIDEOCONFERENCIA ANTECEDENTES EN MIDDLEWARE DDS ESTADO DEL ARTE EN DISTRIBUCIÓN DE DATOS CON DDS APROXIMACIÓN A LA SOLUCIÓN PROPUESTA CONCEPTOS BÁSICOS ARQUITECTURA PROPUESTA Descubrimiento de las salas Moderación del canal de audio. Figura del moderador PRINCIPALES APORTACIONES DEL PROYECTO Y CONCLUSIONES SUBAPARTADO ESTRUCTURA DE LA MEMORIA CAPÍTULO 1. INTRODUCCIÓN A DDS I

16 Plataforma de Trabajo Colaborativo sobre Middleware DDS 1.1 NOCIONES BÁSICAS QUÉ ES EL MIDDLEWARE? MODELOS DE COMUNICACIÓN QUÉ ES DDS? QUÉ ES RTI DDS? Características de RTI Data Distribution Service COMUNICACIONES PUBLICACIÓN-SUBSCRIPCIÓN CENTRADAS EN DATOS QUÉ ES DCPS? DCPS con Requerimientos de Tiempo Real TERMINOLOGÍA Y CONCEPTOS ADICIONALES Tipos de datos Entidades DCPS Muestras, instancias y claves Dominios y DomainParticipants CALIDAD DE SERVICIO (QOS) DESCUBRIMIENTO DE APLICACIONES CONCLUSIONES CAPÍTULO 2. POLÍTICAS QOS EN DDS CONTROL DE LAS COMUNICACIONES MEDIANTE POLÍTICAS DE QOS POLÍTICAS QOS ADECUADAS PARA AUDIO/VÍDEO [55] POLÍTICA DEADLINE Propiedades Utilidad para transmisión de audio y vídeo POLÍTICA LIFESPAN Propiedades Utilidad para transmisión de audio y vídeo POLÍTICA LIVELINESS Propiedades Consideraciones adicionales Utilidad para Transmisión de Audio y Vídeo POLÍTICA OWNERSHIP Cómo se selecciona qué DataWriter es el dueño de la instancia Propiedades Utilidad para transmisión de audio y vídeo POLÍTICA OWNERSHIP_STRENGTH Propiedades Utilidad para transmisión de audio y vídeo POLÍTICA PRESENTATION Acceso coherente Acceso ordenado Propiedades Utilidad para transmisión de audio y vídeo POLÍTICA TIME_BASED_FILTER Propiedades II

17 Índice general Utilidad para transmisión de audio y vídeo CONCLUSIONES CAPÍTULO 3. MODELADO DE REQUISITOS REQUISITOS FUNCIONALES CLIENT.MAIN Definición de actores: Identificación de casos de uso por actores: Descripción de casos de uso: Diagrama de Casos de Uso: CLIENT.AUDIOPACKET Definición de actores: Identificación de casos de uso por actores: Descripción de casos de uso: Diagrama de Casos de Uso: COMMUNICATIONDDS.VIDEOFRAME Definición de actores: Identificación de casos de uso por actores: Descripción de casos de uso: Diagrama de Casos de Uso: COMMUNICATIONDDS.AUDIOPACKET Definición de actores: Identificación de casos de uso por actores: Descripción de casos de uso: Diagrama de Casos de Uso: COMMUNICATIONDDS.SIGNALING Definición de actores: Identificación de casos de uso por actores: Descripción de casos de uso: Diagrama de Casos de Uso: COMMUNICATIONDDS.MESSENGER Definición de actores: Identificación de casos de uso por actores: Descripción de casos de uso: Diagrama de Casos de Uso: COMMUNICATIONIPCAMERA Definición de actores: Identificación de casos de uso por actores: Descripción de casos de uso: Diagrama de Casos de Uso: REQUISITOS NO FUNCIONALES COMUNES A TODOS LOS SUBSISTEMAS Implementación Interfaz Facilidad de Uso Fiabilidad III

18 Plataforma de Trabajo Colaborativo sobre Middleware DDS Operaciones Rendimiento Soporte Empaquetamiento ESPECÍFICOS DE CLIENT.AUDIOPACKET Implementación ESPECÍFICOS DE COMMUNICATIONIPCAMERA Implementación Interfaz Fiabilidad Operaciones CONCLUSIONES CAPÍTULO 4. DISEÑO DIAGRAMA DE PAQUETES POLÍTICAS DE CALIDAD DE SERVICIO INCORPORADAS AL SISTEMA POLÍTICAS DEADLINE Y TIME_BASED_FILTER POLÍTICA LIVELINESS POLÍTICA PRESENTATION POLÍTICA LIFESPAN POLÍTICA OWNERSHIP Y OWNERSHIP_STRENGTH DIAGRAMAS DE CLASES PAQUETE CLIENT.MAIN PAQUETE CLIENT.AUDIOPACKET PAQUETE COMMUNICATIONDDS.VIDEOFRAME PAQUETE COMMUNICATIONDDS.AUDIOPACKET PAQUETE COMMUNICATIONDDS.SIGNALING PAQUETE COMMUNICATIONDDS.MESSENGER PAQUETE COMMUNICATIONIPCAMERA DIAGRAMAS DE SECUENCIA SUBSISTEMA CLIENT.MAIN Iniciar/cerrar sistema Buscar salas Unirse a sala Abandonar sala Notificar problemas en vídeo SUBSISTEMA CLIENT.AUDIOPACKET Iniciar/finalizar captura Iniciar/finalizar reproducción Cambiar audio OWNERSHIP Publicar/reproducir paquete de audio SUBSISTEMA COMMUNICATIONDDS.VIDEOFRAME Iniciar/terminar subscripción Iniciar/terminar publicación Publicar/recibir VideoFrame IV

19 Índice general Notificar expiración de DW DEADLINE Notificar expiración de DR DEADLINE Notificar cambio en LIVELINESS Comprobar estado de DW DEADLINE Comprobar estado de DR DEADLINE SUBSISTEMA COMMUNICATIONDDS.AUDIOPACKET Iniciar/terminar subscripción Iniciar/terminar publicación Publicar/recibir AudioPacket Cambiar OWNERSHIP Notificar cambio en LIVELINESS SUBSISTEMA COMMUNICATIONDDS.SIGNALING Iniciar/terminar subscripción Iniciar/terminar publicación Publicar/recibir SessionSignaling Notificar cambio en LIVELINESS SUBSISTEMA COMMUNICATIONDDS.MESSENGER Iniciar/terminar subscripción Iniciar/terminar publicación Publicar/recibir ImMessage Notificar cambio en LIVELINESS SUBSISTEMA COMMUNICATIONIPCAMERA Conectar/desconectar sistema Cambiar calidad Publicar frame de vídeo CONCLUSIONES CAPÍTULO 5. IMPLEMENTACIÓN DESCRIPCIÓN IDL DE LOS TIPOS DE DATOS INTERCAMBIADOS VIDEOFRAME AUDIOPACKET SESSIONSIGNALING IMMESSAGE HERRAMIENTA RTIDDSGEN COMUNICACIÓN CON CÁMARA IP COMUNICACIÓN CON CÁMARA IP AXIS 207W. VAPIX ARCHIVO XML DE CONFIGURACIÓN DE CÁMARA IP GESTIÓN DE AUDIO INTEGRACIÓN EN EL SISTEMA. CODEC DE AUDIO SPEEX. JSPEEX Codec de audio SPEEX Librería JSPEEX CONCLUSIONES CAPÍTULO 6. ESTIMACIÓN DE COSTES V

20 Plataforma de Trabajo Colaborativo sobre Middleware DDS 6.1 TAREAS Y TEMPORIZACIÓN COSTES INFRAESTRUCTURAS ESFUERZO DE DESARROLLO DEL SISTEMA CONCLUSIONES CAPÍTULO 7. RESULTADOS Y TRABAJO FUTURO PRINCIPALES CONTRIBUCIONES DEL PROYECTO TRABAJO FUTURO BIBLIOGRAFÍA ANEXO A VI

21 Índice de figuras CAPÍTULO 0. INTRODUCCIÓN FIGURA 0.1 PICTUREPHONE... 5 FIGURA 0.2 CU SEEME... 6 FIGURA 0.3 SISTEMA INTELLIGENT LINKING... 7 FIGURA 0.4 EJEMPLO DE INTERACCIÓN ENTRE NODOS ISABEL... 8 FIGURA 0.5 MULTIVIDEOCONFERENCIA CONNECTA FIGURA 0.6 INTEROPERABILIDAD OFFICE COMMUNICATION SERVER Y PBX... 9 FIGURA 0.7 ARQUITECTURA PROPUESTA CAPÍTULO 1. INTRODUCCIÓN A DDS FIGURA 1.1 SITUACIÓN DE LA CAPA MIDDLEWARE SOBRE LA PILA DE PROTOCOLOS DE RED FIGURA 1.2 MODELOS DE COMUNICACIÓN FIGURA 1.3 ENTIDADES DCPS [42] FIGURA 1.4 COMUNICACIÓN A TRAVÉS DE TÓPICOS CAPÍTULO 2. POLÍTICAS QOS EN DDS FIGURA 2.1 RELACIÓN ENTRE MINIMUM_SEPARATION Y DEADLINE CAPÍTULO 3. MODELADO DE REQUISITOS FIGURA 3.1 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA CLIENT.MAIN FIGURA 3.2 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA CLIENT.AUDIOPACKET FIGURA 3.3 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA COMMUNICATIONDDS.VIDEOFRAME FIGURA 3.4 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA COMMUNICATIONDDS.AUDIOPACKET FIGURA 3.5 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA COMMUNICATIONDDS.SIGNALING FIGURA 3.6 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA COMMUNICATIONDDS.MESSENGER FIGURA 3.7 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA COMMUNICATIONDDS.COMMUNICATIONIPCAMERA VII

22 Plataforma de Trabajo Colaborativo sobre Middleware DDS CAPÍTULO 4. DISEÑO FIGURA 4.1 DIAGRAMA DE PAQUETES FIGURA 4.2 PAQUETE CLIENT.MAIN FIGURA 4.3 PAQUETE CLIENT.AUDIOPACKET FIGURA 4.4 PAQUETE COMMUNICATIONDDS.VIDEOFRAME FIGURA 4.5 PAQUETE COMMUNICATIONDDS.AUDIOPACKET FIGURA 4.6 PAQUETE COMMUNICATIONDDS.SIGNALING FIGURA 4.7 PAQUETE COMMUNICATIONDDS.MESSENGER FIGURA 4.8 PAQUETE COMMUNICATIONIPCAMERA FIGURA 4.9 DIAGRAMA DE SECUENCIA INICIAR/CERRAR SISTEMA FIGURA 4.10 DIAGRAMA DE SECUENCIA BUSCAR SALAS FIGURA 4.11 DIAGRAMA DE SECUENCIA UNIRSE A SALA FIGURA 4.12 DIAGRAMA DE SECUENCIA ABANDONAR SALA FIGURA 4.13 DIAGRAMA DE SECUENCIA NOTIFICAR PROBLEMAS VÍDEO FIGURA 4.14 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR CAPTURA FIGURA 4.15 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR REPRODUCCIÓN FIGURA 4.16 DIAGRAMA DE SECUENCIA CAMBIAR AUDIO OWNERSHIP FIGURA 4.17 DIAGRAMA DE SECUENCIA PUBLICAR/REPRODUCIR PAQUETE DE AUDIO FIGURA 4.18 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR SUBSCRIPCIÓN FIGURA 4.19 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR PUBLICACIÓN FIGURA 4.20 DIAGRAMA DE SECUENCIA PUBLICAR/RECIBIR VIDEOFRAME FIGURA 4.21 DIAGRAMA DE SECUENCIA NOTIFICAR EXPIRACIÓN DE DW DEADLINE FIGURA 4.22 DIAGRAMA DE SECUENCIA NOTIFICAR EXPIRACIÓN DE DR DEADLINE FIGURA 4.23 DIAGRAMA DE SECUENCIA NOTIFICAR CAMBIO EN LIVELINESS FIGURA 4.24 DIAGRAMA DE SECUENCIA COMPROBAR ESTADO DE DW DEADLINE FIGURA 4.25 DIAGRAMA DE SECUENCIA COMPROBAR ESTADO DE DR DEADLINE FIGURA 4.26 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR SUBSCRIPCIÓN FIGURA 4.27 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR PUBLICACIÓN FIGURA 4.28 DIAGRAMA DE SECUENCIA PUBLICAR/RECIBIR AUDIO PACKET FIGURA 4.29 DIAGRAMA DE SECUENCIA CAMBIAR OWNERSHIP FIGURA 4.30 DIAGRAMA DE SECUENCIA NOTIFICAR CAMBIO EN LIVELINESS FIGURA 4.31 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR SUBSCRIPCIÓN FIGURA 4.32 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR PUBLICACIÓN FIGURA 4.33 DIAGRAMA DE SECUENCIA PUBLICAR/RECIBIR SESSIONSIGNALING FIGURA 4.34 DIAGRAMA DE SECUENCIA NOTIFICAR CAMBIO EN LIVELINESS FIGURA 4.35 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR SUBSCRIPCIÓN FIGURA 4.36 DIAGRAMA DE SECUENCIA INICIAR/TERMINAR PUBLICACIÓN FIGURA 4.37 DIAGRAMA DE SECUENCIA PUBLICAR/RECIBIR IMMESSAGE FIGURA 4.38 DIAGRAMA DE SECUENCIA NOTIFICAR CAMBIO EN LIVELINESS FIGURA 4.39 DIAGRAMA DE SECUENCIA CONECTAR/DESCONECTAR SISTEMA FIGURA 4.40 DIAGRAMA DE SECUENCIA CAMBIAR CALIDAD FIGURA 4.41 DIAGRAMA DE SECUENCIA PUBLICAR FRAME DE VÍDEO ANEXO A. MANUAL DE USUARIO FIGURA A.1 VENTANA CREACIÓN/DESCUBRIMIENTO DE SALAS FIGURA A.2 SECCIÓN BUSCAR SALAS FIGURA A.3 VENTANA DE SALA VIII

23 Índice de figuras FIGURA A.4 CREACIÓN DE SALA PÚBLICA FIGURA A.5 LOCALIZACIÓN DE SALA PÚBLICA FIGURA A.6 INICIO DE PUBLICACIÓN DE VÍDEO FIGURA A.7 INICIO DE SUBSCRIPCIÓN A VÍDEO FIGURA A.8 SUBSCRIPCIÓN A VÍDEO FIGURA A.9 CREACIÓN DE SALA PRIVADA FIGURA A.10 USUARIOS CON PERMISO DE ACCESO A LA SALA FIGURA A.11 DESCUBRIMIENTO DE SALAS PRIVADAS FIGURA A.12 DIFERENTES ESTADOS PARA LOS USUARIOS DE LA SALA FIGURA A.13 INFORMACIÓN DE ESTADO DE USUARIO FIGURA A.14 MENSAJES DE SALIDA DE USUARIOS IX

24 Plataforma de Trabajo Colaborativo sobre Middleware DDS X

25 Índice de tablas CAPÍTULO 2. POLÍTICAS QOS EN DDS TABLA 2.1 POLÍTICAS DE QOS ADECUADAS PARA TRANSMISIÓN DE AUDIO Y VÍDEO TABLA 2.2 POLÍTICA DEADLINE TABLA 2.3 POLÍTICA LIFESPAN TABLA 2.4 POLÍTICA LIVELINESS TABLA 2.5 COMBINACIONES PERMITIDAS PARA LA POLÍTICA LIVELINESS TABLA 2.6 POLÍTICA OWNERSHIP TABLA 2.7 POLÍTICA OWNERSHIP_STRENGTH TABLA 2.8 POLÍTICA PRESENTATION TABLA 2.9 EFECTO DE LA CONFIGURACIÓN ACCESO ORDENADO SOBRE LA QOS PRESENTATION TABLA 2.10 COMBINACIONES PERMITIDAS PARA EL ACCESO ORDENADO TABLA 2.11 COMBINACIONES PERMITIDAS PARA EL ACCESO COHERENTE TABLA 2.12 POLÍTICA OWNERSHIP_STRENGTH CAPÍTULO 5. IMPLEMENTACIÓN TABLA 5.1 PARÁMETROS DE CONFIGURACIÓN DE LA CÁMARA MEDIANTE HTTP CAPÍTULO 6. ESTIMACIÓN DE COSTES TABLA 6.1 TAREAS REALIZADAS Y DURACIÓN ESTIMADA TABLA 6.2 INFRAESTRUCTURAS NECESARIAS PARA EL DESARROLLO DEL SISTEMA TABLA 6.3 INFRAESTRUCTURAS NECESARIAS PARA LA EXPLOTACIÓN DEL SISTEMA TABLA 6.4 LÍNEAS DE CÓDIGO DEL PROYECTO TABLA 6.5 PARÁMETROS PARA CALCULAR COSTES MEDIANTE COCOMO II TABLA 6.6 DISTRIBUCIÓN DE ACTIVIDADES POR PERSONAS/MES PARA EL MODELO COCOMO II XI

26 Plataforma de Trabajo Colaborativo sobre Middleware DDS XII

27 Índice de listados CAPÍTULO 5. IMPLEMENTACIÓN LISTADO 5.1 MODELO IDL VIDEOFRAME LISTADO 5.2 MODELO IDL AUDIOPACKET LISTADO 5.3 MODELO IDL SESSIONSIGNALING LISTADO 5.4 MODELO IDL IMMESSAGE LISTADO 5.5 ESQUEMA XML AL QUE HAN DE AJUSTARSE LOS ARCHIVOS DE CONFIGURACIÓN DE LA CÁMARA IP LISTADO 5.6 EJEMPLO DE ARCHIVO DE CONFIGURACIÓN XIII

28 Plataforma de Trabajo Colaborativo sobre Middleware DDS XIV

29 Glosario API CELP COCOMO codec CORBA DCOM DCPS DCT DDS DLRL DP DR DW GNU GUID IEEE INC ISO Application Programming Interface Code Excited Linear Prediction Constructive Cost Model coder-decoder Common Object Request Broker Architecture Distributed Component Object Model Data-Centric Publish-Subscribe Discrete Cosine Transform Data Distribution Service Data Local Reconstruction Layer Domain Participant Datawriter Datareader GNU is Not Unix Globally Unique Identifier Institute of Electrical and Electronics Engineers Incorporation International Organization of Standarization XV

30 Plataforma de Trabajo Colaborativo sobre Middleware DDS ITU JMF JMS JNI JPEG H HTTP HVQ L MCU MPEG N NASA NATO OMG OTAN PS PBX PC QCIF QoS RMI RPC RT RTI RTP SIMPLE International Telecommunication Union Java Media Framework Java Message Service Java Native Interface Joint Photographic Experts Group High Hypertext Transfer Protocol Hierarchical Vector Quantization Low Multipoint Control Unit Moving Picture Experts Group Normal National Aeronautics and Space Administration North Atlantic Treaty Organization Object Management Group Organización del Tratado Atlántico Norte Publicación/subscripción Private Branch Exchange Personal Computer Quarter Common Intermediate Format Quality of Service Remote Method Invocation Remote Procedure Call Real Time Real-Time Innovations Real-Time Transport Protocol SIP for Instant Messaging and Presence Leveraging Extensions XVI

31 Índice de figuras SIP SOA T UDP USB USC VGA VH XH XML XSD Session Initiation Protocol Service Oriented Architecture Topic User Datagram Protocol Universal Serial Bus University of Southern California Video Graphics Array very High Extra High Extensible Markup Language XML Schema Definition XVII

32 Plataforma de Trabajo Colaborativo sobre Middleware DDS XVIII

33 Capítulo 0. Introducción 0.1 Definición del problema La progresiva globalización y deslocalización de las empresas y la dispersión de sus distintas sedes generan nuevas necesidades para la comunicación de los diferentes equipos que las conforman. Del mismo modo, la popularización de la educación a distancia, que permite la asistencia a clases impartidas en localizaciones remotas, justifican el uso de diferentes plataformas para el trabajo colaborativo. Algunos ejemplos de estas plataformas los encontramos en aplicaciones como Click to Meet [3], Isabel [4], Connecta 2000 [5] o Microsoft Office Communication Server [6]. Dichos sistemas mejoran la productividad en entornos empresariales y académicos mediante servicios de presencia y comunicación multimedia en tiempo real. En el proyecto que nos ocupa se presentará el desarrollo y evaluación de un sistema de trabajo colaborativo. En concreto, el sistema permitirá la videoconferencia entre distintos clientes remotos, que se conectarán a una determinada sala virtual donde podrán interactuar con el resto de participantes (mediante audio, vídeo y mensajes de texto). Además, el sistema propuesto pretende demostrar la viabilidad de implementar aplicaciones de streaming de audio/vídeo sobre middleware DDS (Data Distribution Service) [1]. DDS es un estándar de la OMG [2] diseñado con el fin de abstraer al programador de las tareas necesarias para el envío y recepción de datos distribuidos. La utilización de middleware DDS permite acortar el tiempo de desarrollo de aplicaciones de tiempo real, configurando el comportamiento del mismo mediante un conjunto de políticas de QoS (Quality of Service). Esto es posible debido a que el middleware facilita una capa adicional que desacopla a la aplicación de las dificultades inherentes en la comunicación. Para el intercambio de información, DDS aplica un modelo data-oriented [7]. Dicho modelo se caracteriza por la existencia de una serie de productores y consumidores de información (publicadores y subscriptores respectivamente) que tienen acceso a un conjunto de datos de interés. En este caso no importa tanto la procedencia o destino de la información, sino disponer en cada momento de versiones actualizadas de los datos. Un claro ejemplo de este modelo lo encontramos en la monitorización de sensores: lo relevante no es la localización o el número de sensores, sino que el monitor cuente con los valores más recientes de los parámetros medidos y, por supuesto, que dicha información sea fiable. 1

34 Plataforma de Trabajo Colaborativo sobre Middleware DDS Como se ha comentado con anterioridad, existen en el mercado numerosas soluciones comerciales y de código abierto que cubren las necesidades de la mayoría de usuarios existentes (especialmente en el ámbito académico y corporativo). La meta principal de este proyecto no es, por tanto, aportar nuevas funcionalidades a las disponibles en otras plataformas existentes, sino desarrollar y evaluar la implantación de este tipo de sistemas sobre middleware DDS identificando las ventajas que este enfoque proporciona en términos de modularidad, extensibilidad, escalabilidad, robustez frente a fallos y en tiempo de desarrollo de aplicaciones. 0.2 Objetivos En este apartado se detallan los objetivos que persigue este proyecto. Desarrollo de una prueba de concepto de sistema de multivideoconferencia sobre middleware DDS. El principal objetivo del proyecto es, sin duda, demostrar la viabilidad del desarrollo de aplicaciones de trabajo colaborativo y en particular de videoconferencia sobre middleware DDS, evaluando el producto final en aspectos como escalabilidad, facilidad de implementación y extensibilidad posterior. Para ello, se analizarán las capacidades de middleware DDS y las políticas de calidad de servicio de que dispone. Asimismo, es objetivo del proyecto que la presente memoria pueda servir como guía de referencia para el desarrollo posterior de aplicaciones similares sobre middleware DDS. Para ello, a lo largo de los próximos capítulos se introducirán los diversos conceptos relativos a middleware y políticas de calidad de servicio adecuadas para el desarrollo de una plataforma de estas características. 0.3 Recursos El desarrollo y explotación del presente proyecto no requiere recursos especiales. A continuación se presentan los recursos humano, hardware y software que se han dedicado durante su desarrollo Humanos Profesor D. Juan Manuel López Soler, profesor del Departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada, como tutor del proyecto. D. José María López Vega, alumno de la Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación de la Universidad de Granada, que ha sido el encargado de desarrollar el proyecto siguiendo las directrices marcadas por el tutor Hardware Como se indicó anteriormente, para la realización y explotación del proyecto no es necesario emplear hardware especializado. Concretamente, el hardware utilizado ha sido: Ordenador portátil Diversos ordenadores de sobremesa para pruebas de funcionamiento Cámara IP (modelo 207W) de la marca AXIS [8] 2

35 Capítulo 0. Introducción Router Switch Software El proyecto ha sido implementado haciendo uso de la versión comercial de middleware DDS desarrollada por Real-Time Innovations (en adelante RTI) [9], empresa clave en el desarrollo del estándar de la OMG DDS y con la que la que el Departamento de Teoría de la Señal, Telemática y Comunicaciones de la Universidad de Granada mantiene una estrecha colaboración. Concretamente, el sistema ha sido desarrollado sobre la versión estable NDDS 4.2e. Además, se ha hecho uso de los siguientes recursos: Sistema Operativo Windows XP SP2 Sistema Operativo GNU/Linux Ubuntu 7.10 Paquetes de ofimática Entorno de desarrollo Eclipse [10] Librería de audio JSPEEX [11] 0.4 Fases de desarrollo El desarrollo del proyecto se dividirá en distintas fases, organizadas de forma secuencial en el tiempo: 1) Revisión del estado del arte. En esta fase se realizará un estudio de DDS, sus implementaciones, así como una caracterización de la funcionalidad de diferentes sistemas de trabajo colaborativo existentes. Para ello se utilizarán todos los recursos bibliográficos y electrónicos disponibles. 2) Especificación y diseño de la plataforma. Durante esta fase del proyecto se caracterizarán las funcionalidades que cabe esperar de la aplicación, materializadas en la especificación de la misma. El objetivo será integrar y proveer el conjunto de servicios y herramientas especificados de una forma compacta y unificada. 3) Implementación. Una vez concluido la especificación y el diseño, se implementará el código necesario para demostrar la viabilidad de la propuesta realizada. 4) Evaluación. Finalmente se evaluará el sistema diseñado y su implementación en un entorno real identificando los beneficios obtenidos al adoptar una aproximación distinta a la habitual. 5) Documentación: Coincidente en el tiempo con las etapas anteriores, se procederá a la generación de la documentación pertinente de los resultados. 3

36 Plataforma de Trabajo Colaborativo sobre Middleware DDS 0.5 Restricciones Cuando se desarrolla un proyecto, es fundamental establecer una serie de restricciones que limitan el desarrollo del mismo, ayudando a tomar decisiones. A continuación se describen dichas restricciones Factores dato Los factores dato son aquellos que vienen dados de forma ajena al desarrollador de la aplicación. En este proyecto se han identificado los siguientes: La aplicación debe ser multiplataforma o, al menos, portable. Es decir, debe poder ser utilizada en diversas arquitecturas y sistemas operativos o en su defecto poder ser fácilmente adaptada a los mismos. La aplicación ha de ser de código abierto, o al menos fácilmente extensible. Se recomienda que la aplicación sea modular, para facilitar su mantenimiento y extensibilidad. El sistema deberá realizar la totalidad de las comunicaciones sobre middleware DDS y, más concretamente, sobre la implementación de RTI. Para captura de vídeo, se utilizará una cámara IP modelo 207W del fabricante AXIS. Con este fin, será necesario implementar un puente HTTP/DDS Factores estratégicos Se denomina factores estratégicos a aquellas decisiones que toma el desarrollador en las fases más tempranas del proyecto y que no vienen impuestas externamente: Elección de lenguaje de programación: En primer lugar, se determinó que se usaría un lenguaje orientado a objetos, al aportar mayor uniformidad y reusabilidad al código generado. De este modo, se estudiaron dos opciones: o Desarrollo en C++: Esta aproximación permitiría el desarrollo de un sistema más eficiente que el desarrollado sobre Java, especialmente para la captura y reproducción de audio. o Desarrollo en Java: Aunque por tratarse de un lenguaje interpretado la eficiencia podría ser menor que la alcanzable con C++, Java presenta una serie de ventajas que llevaron al autor del proyecto a decantarse por este lenguaje. En primer lugar, se trata de un lenguaje multiplataforma, lo que se ajusta perfectamente al primer factor dato antes mencionado. Además, tiene un soporte excelente para prototipado rápido, gracias a bibliotecas como SWING o AWT, que permiten el desarrollo rápido de interfaces gráficas de usuario y que están incluidas en la API estándar del lenguaje. Finalmente, Java dispone de forma nativa de la herramienta Javadoc para la generación de la documentación del código desarrollado, evitando la necesidad de acudir a herramientas externas. Elección de entorno de desarrollo: Se ha elegido el entorno libre Eclipse, ya que se trata de una herramienta muy potente para la programación Java, permitiendo además su extensibilidad mediante un sistema de plugins. 4

37 Capítulo 0. Introducción 0.6 Antecedentes y estado del arte En este apartado se estudiarán el estado actual y antecedentes de los temas abordados por el proyecto. Concretamente, se hará un breve recorrido por la historia de los sistemas de trabajo colaborativo y el middleware de publicación-subscripción DDS. Finalmente, se presentarán diversas soluciones existentes para el trabajo colaborativo y la distribución de datos con DDS Antecedentes en plataformas de videoconferencia Los orígenes de los sistemas de videoconferencia se remontan a 1964, cuando AT&T presentó en la feria de comercio mundial de Nueva York un prototipo de videoteléfono llamado Picturephone (ver figura 0.1) que podía transmitir vídeo [12]. Para esta primera transmisión fue necesario utilizar comunicaciones vía satélite, ya que la red telefónica era incapaz de soportar el ancho de banda requerido. Debido a lo anterior, el coste aproximado de esta primera transmisión ascendió a 1000 dólares el segundo. Figura 0.1 Picturephone Posteriormente, en los años 70 los proveedores de redes telefónicas mejoraron sustancialmente sus redes, iniciándose una transición hacia métodos de transmisión digital. Además, mejoraron considerablemente las técnicas de procesamiento, muestreo y conversión de señales analógicas en señales digitales. A principios de los años 80 se introdujo la tecnología de codificación por Transformada Discreta de Coseno (DCT) [13], que permitió obtener razones de compresión 60:1. Por otro lado, la compañía Compression Labs Inc.[14], introdujo el primer codec, consiguiendo una razón de compresión de 117:1 (768 Kbps). Con estos avances se redujo el coste asociado era aproximadamente 1000 dólares la hora. Posteriormente, Picture Tel introdujo un nuevo codec que mediante Cuantificación Jerárquica de Vectores (HVQ) alcanzando una compresión de 1600:1 (56Kbps). 5

38 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 0.2 CU SeeMe En 1992 se lanzó un sistema de videoconferencia llamado CU SeeMe para Macintosh (ver figura 0.2) [15] [16]. Aunque la primera versión no soportaba audio, fue la primera plataforma de este tipo que se desarrolló para un ordenador personal. En 1993 el programa tenía capacidad multipunto y en 1994 era un verdadero sistema de videoconferencia con audio. Aunque en un principio este programa sólo era compatible con plataformas MAC, finalmente se consiguió portarlo con funcionalidad completa a Windows en El boom había comenzado, a partir de este momento numerosas compañías iniciaron el desarrollo de software y equipos de videoconferencia Estado del arte en plataformas de videoconferencia En la actualidad existen multitud de plataformas de trabajo colaborativo y videoconferencia, cada una con una serie de características que la hacen apropiada para un público determinado. A continuación se presentan algunas de ellas. Click to Meet [17]: Desarrollada por Radvision [18], es una solución altamente escalable para la entrega de voz, vídeo y compartición de datos. El modelo de comunicación utilizado en este caso es cliente-servidor, existiendo uno o varios servidores distribuidos que reciben los distintos flujos de datos, recodificándolos y enviándolos hacia los destinatarios. Para conseguir una distribución de datos óptima, Click to Meet implementa Intelligent Linking [17], una tecnología que puede trabajar sobre entornos multicast y unicast, optimizando el ancho de banda necesario (ver figura 0.3). Además, Click to Meet implementa comunicaciones seguras, encriptando los streams de audio y vídeo, así como todos los datos intercambiados. 6

39 Capítulo 0. Introducción Figura 0.3 Sistema Intelligent Linking Isabel [19]: Es una aplicación peer-to-peer de trabajo colaborativo multipunto desarrollada por la Universidad Politécnica de Madrid. El desarrollo de Isabel se inició en 1993, cuando fue creada para soportar la realización distribuida de los Cursos de Verano en Comunicaciones Avanzadas Banda ancha de RACE/ACTS. Isabel cuenta con diferentes patrones de funcionamiento denominados servicios, cada uno con una serie de características que lo hacen especialmente adecuado para un tipo usuarios. Concretamente, los servicios ofrecidos son Tele-reunión (permite a todos los participantes utilizar el canal de audio y cambiar los datos intercambiados sin ninguna restricción), Tele-clase (existe la figura del moderador, que controla la plataforma), Tele-conferencia (introduce varios roles con diferentes privilegios). Isabel distingue dos capas para el intercambio de datos: una capa de entrega de datos multimedia y otra para el control de las distintas fuentes. Cada nodo Isabel tiene capacidad para actuar como un proxy, como MCU (Multipoint Control Unit) o como puerta de enlace para otros participantes. En la figura 0.4 se puede ver un ejemplo de la interacción entre diferentes nodos Isabel. 7

40 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 0.4 Ejemplo de interacción entre nodos Isabel Connecta2000: Es un software de comunicación directa (peer-to-peer) especializado en intercambio de audio y vídeo sin utilizar ningún servidor central. Permite tanto conferencias individuales sobre H.264 o MPEG-4 a 25 frames por segundo como multivideoconferencias MPEG-4 (máximo recomendado 4 o 5 participantes) o JPEG (recomendado para más de 5 participantes) a un máximo de 2 frames por segundo (ver figura 0.5). En el caso de multiconferencia, únicamente podrá hablar un usuario al mismo tiempo, por lo que se gestiona el canal de audio mediante un sistema de turnos. Para la transmisión de audio, esta plataforma hace uso del codec SPEEX [20]. Figura 0.5 Multivideoconferencia Connecta2000 Microsoft Office Communication Server: Se trata de una plataforma cliente-servidor para trabajo colaborativo desarrollada por Microsoft, basada en los protocolos SIP (Session Initiation Protocol) y SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions). Incorpora características como presencia, mensajería instantánea e intercambio 8

41 Capítulo 0. Introducción de audio y vídeo sobre RTP (Real-Time Transport Protocol). En cuanto a los codec de audio y vídeo utiliza codec privativos de Microsoft. No obstante, es posible interoperar con una PBX para el intercambio de audio mediante el uso de un servidor de mediación que realiza la conversión a codec estándar (ver figura 0.6). Figura 0.6 Interoperabilidad Office Communication Server y PBX Antecedentes en Middleware DDS Una característica importante de las grandes redes de ordenadores actuales, como Internet, es su heterogeneidad. La heterogeneidad y la estandarización nos permiten, idealmente, utilizar la mejor combinación de hardware y software, aumentando el rendimiento de las aplicaciones sin afectar a su interoperabilidad, consiguiendo un sistema coherente, eficiente y altamente operativo. Pero la práctica demuestra que cumplir los requerimientos de seguridad, eficiencia, flexibilidad y extensibilidad, en sistemas distribuidos heterogéneos es altamente complejo [21]. Estas exigencias motivaron el uso de CORBA (Common Object Request Broker Architecture). CORBA es un estándar abierto del OMG (Object Management Group) para la programación de aplicaciones distribuidas. CORBA mejoraba la flexibilidad y portabilidad de las aplicaciones y permitía al programador desentenderse de las tareas más complejas que conllevan los entornos distribuidos heterogéneos, con muy diversas máquinas, sistemas operativos y protocolos de comunicaciones. Sin embargo, cuando se trataba de sistemas distribuidos con requisitos de tiempo real, CORBA no constituía una solución adecuada, al no estar preparado para responder a las necesidades de mínimo retardo y determinismo que dichos sistemas requieren. Además, CORBA seguía el paradigma clienteservidor, con lo que se hacía necesaria la creación de un nuevo middleware que siguiera el modelo de la publicación-subscripción, más enfocado en la distribución de datos que en la interacción entre objetos. Estas carencias motivaron que empresas como RTI o Thales [22] desarrollaran nuevas soluciones orientadas a aplicaciones distribuidas de tiempo real. Finalmente, en Junio de 2004 la OMG finalizaba la especificación de DDS para sistemas de tiempo real. En dicha especificación, se unificaron las mejores prácticas presentes en los middleware de distribución de datos en tiempo real desarrollados de forma independiente por las empresas RTI y Thales. Gerardo Pardo, Chairman de la OMG, lo definió por aquel entonces como el avance más significativo para sistemas de tiempo real llevado a cabo por la OMG en los últimos años [23]. 9

42 Plataforma de Trabajo Colaborativo sobre Middleware DDS En el siguiente capítulo del presente memoria se profundizará en los conceptos de middleware de red, publicación/subscripción y se detallarán las bases del estándar DDS Estado del arte en distribución de datos con DDS Aunque inicialmente sólo existían las versiones de RTI y Thales, actualmente son numerosas las implementaciones del estándar DDS de la OMG, algunas de ellas de código abierto. A continuación se describen las principales soluciones existentes: RTI Data Distribution Service: Implementación comercial de la capa DCPS (Data-Centric Publish-Subscribe) del estándar DDS, soporta múltiples arquitecturas (incluyendo entre ellas varios sistemas empotrados) y múltiples lenguajes (C, C++, C#, Java ). Es utilizada actualmente por las fuerzas armadas estadounidenses, varias entidades bancarias, diversos servicios de ferrocarril, control aéreo, monitorización de tráfico y sistemas de automatización industrial. Está implementado casi en su totalidad en C, ofreciendo wrappers a los diferentes lenguajes soportados. PrismTech s OpenSplice DDS [24]: Implementación comercial, antiguamente desarrollada por Thales. También ha sido desarrollada para múltiples arquitecturas y lenguajes (C, C++, Java) y cuenta con herramienta para modelado gráfico de sistemas. Twin Oaks Computing s CoreDX [25]: Otra implementación comercial de la capa DCPS. La API de esta implementación soporta C y C++. OCI s OpenDDS [26]: Implementación de código abierto de la capa DCPS. Actualmente soporta la mayor parte de las características mínimas de dicha capa. Está implementado en C++. MilSOFT [27]: Es una implementación comercial del estándar DCPS. Soporta completamente las características mínimas exigidas por el estándar, pero no así otras como el servicio de persistencia (servicio mediante el cual se asegura la entrega de datos pese a que las fuentes no estén operativas). 0.7 Aproximación a la solución propuesta En este apartado se ofrecerá una visión general de la solución desarrollada. En primer lugar se introducen una serie de conceptos básicos relativos a los sistemas de videoconferencia, para luego dar paso a la arquitectura de la plataforma Conceptos básicos En este apartado se introducen una serie de conceptos básicos relativos a los sistemas de videoconferencia, muchos de los cuales aparecerán en posteriores capítulos de la memoria. Sala: Este término hace referencia a entornos virtuales aislados en los que un conjunto de usuarios pueden intercambiar mensajes de texto, voz o incluso vídeo. Así pues, un usuario de un sistema que implemente este tipo de división sólo podrá tener acceso a los contenidos intercambiados en las salas a las que esté subscrito. 10

43 Capítulo 0. Introducción Moderador: Es un usuario de una sala con privilegios especiales. Por lo general, estos privilegios incluyen la posibilidad de elegir qué usuario tiene la voz o expulsar usuarios de una sala. Descubrimiento de salas: Por lo general, antes de acceder a una sala, un usuario debe conocer que ésta existe. El descubrimiento de salas permite a un usuario obtener una lista de las salas disponibles. Existen distintas aproximaciones para este descubrimiento (centralizada, distribuida, etc.), en el sistema que nos ocupa implementará descubrimiento distribuido Arquitectura propuesta En este apartado se describirá la arquitectura de la solución propuesta, con el fin de dar al lector una visión general del sistema desarrollado. En el presente proyecto se ha desarrollado un sistema de videoconferencia aplicando el modelo de publicación subscripción. La plataforma que ha diseñado permite el intercambio de vídeo, audio, mensajes de texto y de señalización entre sistemas remotos mediante middleware DDS. Se ha optado, por tanto, por un modelo distribuido para el intercambio de información entre los distintos miembros de las salas de conferencia. Además, de acuerdo con los factores dato descritos en el apartado 0.5.1, para el envío de vídeo se ha implementado módulo que sirve de puente entre cámaras IP (que trabajan con HTTP) y middeware DDS. En la figura 0.7 se presenta la arquitectura propuesta. Como se puede observar, el sistema desarrollado permite la comunicación distribuida entre sistemas heterogéneos mediante de middeware DDS. Al aplicar un modelo de publicación-subscripción, los recursos dejan de estar centralizados en un servidor, para pasar a formar parte del denominado espacio de datos. Las ventajas de esta aproximación radican en una mayor escalabilidad, al no requerir la existencia de nodos centrales para establecer la comunicación entre los distintos sistemas remotos. Para más información sobre el modelo de publicación-subscripción, DDS y el concepto espacio de datos, se remite al lector al capítulo 1 de la presente memoria. 11

44 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 0.7 Arquitectura propuesta Descubrimiento de las salas Antes de poder interactuar con otros usuarios, es necesario acceder a una sala de conferencia. El sistema desarrollado implementa dos tipos de salas: Públicas: Como su nombre indica, estas salas están abiertas y no cuentan con ningún tipo de control de acceso. Por tanto, podrán ser descubiertas y accedidas por cualquier usuario. Privadas: En su creación se define una lista de usuarios permitidos (identificados por un número de identificación único). Por tanto, sólo los usuarios que se encuentren en la lista asociada a cada sala podrán descubrirla y acceder a la misma. En cuanto a la aproximación seguida, se ha mantenido el modelo distribuido en el descubrimiento de salas. De este modo, al iniciar la búsqueda de salas el sistema localizará dinámicamente las salas existentes mediante los mecanismos de descubrimiento con los que cuenta DDS. Para más información sobre estos mecanismos, se remite al lector a la sección del capítulo 1. 12

45 Capítulo 0. Introducción Moderación del canal de audio. Figura del moderador En los sistemas de multiconferencia, varios usuarios pueden intercambiar audio. Este hecho puede llevar a situaciones conflictivas, al no existir contacto visual directo entre los usuarios, reduciendo la calidad de la comunicación. Por tanto, al desarrollar una plataforma de multiconferencia es necesario decidir cómo se va a gestionar el canal de voz. Entre las alternativas posibles destacamos las siguientes: No hacer nada: En este caso, se espera que los usuarios se turnen para evitar interrupciones. Quizá sea la alternativa menos adecuada, por la carencia de contacto visual directo. Arbitrar un sistema de turnos automático: En este caso, es el propio sistema el que decide qué usuario tiene derecho a usar el canal de audio cada vez. Aunque mejor que el anterior, esta aproximación no es excesivamente flexible. Sala moderada: Esta aproximación es la que se ha implementado en el sistema que nos ocupa. En las salas moderadas existe un usuario especial (el moderador) que puede ceder o retirar la palabra al resto de usuarios. Así, cuando un usuario desea hablar, solicita el canal de audio al moderador, el cual aceptará o denegará la solicitud. 0.8 Principales aportaciones del proyecto y conclusiones Los resultados del desarrollo de este proyecto han sido presentados en Julio de 2008 en el IX Workshop on Distributed Object Computing for Real-time and Embedded Systems celebrado en Washington (DC, USA) bajo el título QoS Policies for Audio/Video Distribution Over DDS Middleware [73]. Este encuentro, organizado por la OMG, constituye un foro para ingenieros de software e investigadores en el campo de los sistemas distribuidos y de tiempo real. El trabajo actual ha conseguido cumplir los objetivos propuestos con las siguientes conclusiones: 1. La utilización de middleware DDS facilita el desarrollo de aplicaciones que requieren la distribución de datos en tiempo real, reduciendo el tiempo de desarrollo. 2. La aplicación del modelo de publicación-subscripción para un sistema de videoconferencia no es sólo viable, sino que además es adecuada. Esta aproximación, al no requerir de un servidor centralizado para tareas como el descubrimiento de salas o intercambio de datos, es altamente escalable. 3. Dada la arquitectura modular del sistema desarrollado, el código generado es altamente reutilizable. Concretamente, la implementación del puente DDS/HTTP para el acceso a cámaras IP puede ser integrada con facilidad en aplicaciones fuera del ámbito de la videoconferencia, tales como videovigilancia. 0.9 Estructura de la memoria Para finalizar este primer capítulo de introducción, se muestra una breve descripción de cada uno de los capítulos en los que se ha estructurado la presente memoria. 13

46 Plataforma de Trabajo Colaborativo sobre Middleware DDS Capítulo 1. En este capítulo se identifican y describen los conceptos más relevantes referentes a middleware de red. Se explicará qué es DDS, así como las ventajas que aporta y en qué situaciones es adecuada su aplicación. Además, se introducirán los fundamentos de la capa Publicación- Subscripción Centrada en Datos o DCPS (Data Centric Publish Subscribe) [1] [28] del protocolo DDS. Capítulo 2. Este capítulo se centra en la identificación de las políticas de calidad de servicio necesarias para el intercambio de audio y vídeo a través de la red. Se trata de un apartado fundamental para conseguir una calidad en la transmisión de vídeo y audio adecuada. Capítulo 3. Previo al diseño e implementación del sistema a desarrollar, para garantizar que se satisfacen todos los requerimientos, es necesario realizar un modelado de requisitos. Con este fin, en este capítulo se establecen los requerimientos del sistema. Capítulo 4. Una vez fijados los requisitos del sistema, en este capítulo se presenta el diseño de la plataforma. Con este fin, se proporcionan el diagrama de paquetes, el de clases y el de flujo. Igualmente se definen las políticas de calidad de servicio incorporadas. Capítulo 5. El presente proyecto no se ha limitado al diseño del sistema, sino que se ha llevado a cabo la implementación del mismo. En este capítulo se describen algunos detalles de la implementación que se consideran especialmente relevantes. Capítulo 6: En este capítulo se llevará a cabo un estudio económico del proyecto realizado. Capítulo 7: Este capítulo presenta las conclusiones alcanzadas tras la elaboración del presente proyecto, indicando las líneas de trabajo futuro partiendo de la base que aporta el mismo. 14

47 Capítulo 1. Introducción a DDS En este capítulo se identifican y describen los conceptos más relevantes referentes a middleware de red. Se detallará qué es DDS, así como las ventajas que aporta y en qué situaciones es adecuada su aplicación. Además, se explicarán los fundamentos de la capa Publicación-Subscripción Centrada en Datos o DCPS (Data Centric Publish Subscribe) [1] [28] del protocolo DDS. 1.1 Nociones básicas En este primer apartado se pretende situar al lector en el contexto en el que se ha desarrollado el sistema, introduciendo conceptos esenciales como DDS, DCPS o middleware Qué es el middleware? Middleware es una capa software situada entre la capa de aplicación y el sistema operativo, que aísla la aplicación de los detalles relativos a la arquitectura, sistema operativo y capas de red (ver figura 1.1) [29], [30]. Aunque el término middleware se ha popularizado recientemente, aparece referenciado por primera vez en el informe de la Conferencia de la OTAN sobre Ingeniería de Software, celebrada en 1968 [31]. Según Pardo-Castellote [29] [32], el término middleware engloba dos conceptos: modelo de servicio y protocolo de intercambio de información. El modelo de servicio está constituido a su vez por tres modelos que interactúan entre sí: Modelo de comunicaciones: Es una abstracción de cómo interactúan las aplicaciones. En la sección de este capítulo se profundizará en las diversas aproximaciones existentes. Modelo de objetos: Está formado por las entidades disponibles para permitir el acceso al servicio. Modelo de arquitectura: Describe cómo se organiza la información en un sistema distribuido. Los principales tipos son: centralizada, brokered y peer to peer. El tipo de middleware más extendido es el conocido como de red, que simplifica el desarrollo de sistemas distribuidos. Para alcanzar dicho objetivo, permite a las aplicaciones intercambiar información sin que sea necesario utilizar interfaces de bajo nivel. Algunos ejemplos de middleware de 15

48 Plataforma de Trabajo Colaborativo sobre Middleware DDS red son DCE/RPC [33], DCOM [34], CORBA [21], ICE [35], TIBCO [36], 29 West [37], JMS [38], MQ Series [39], OpenSplice [24], GigaSpaces [40] o RTI DDS [41]. Figura 1.1 Situación de la capa middleware sobre la pila de protocolos de red Middleware de publicación/subscripción. DDS está basado en un modelo de comunicaciones publicación/subscripción (en adelante, PS), proporcionando una forma simple e intuitiva de distribuir datos. DDS desacopla temporal y espacialmente a las entidades que crean y envía datos (los publicadores) de las entidades que los recibe y usan (los subscriptores). De este modo, los publicadores simplemente han de declarar su intención de publicar y posteriormente publicar los datos. Los subscriptores, por su parte, deben indicar su intención de recibir dichos datos, siendo éstos automáticamente entregados a los mismos independientemente de su localización espacial y temporal. Pese a la simplicidad del modelo, el middleware PS puede gestionar y transmitir estructuras de datos complejas, con lo que su uso permite desarrollar aplicaciones más sencillas y modulares. No obstante, la mayor ventaja de utilizar middleware de PS es que éste gestiona de forma automática el tráfico de datos en las capas situadas por debajo del mismo. Así, el middleware de PS se encarga de gestionar las conexiones, caídas de enlaces, cambios en la configuración de la red, etc., con lo que se elimina la necesidad de programar dichos casos al desarrollar una aplicación de usuario Modelos de comunicación El modelo de comunicaciones es el componente más importante en el middleware de red, ya que caracteriza cómo se intercambia información entre las aplicaciones. Dicho modelo afecta al rendimiento, a la facilidad para efectuar transacciones de información, a la naturaleza de los errores y a la robustez a diferentes condiciones de error. Desafortunadamente, no hay una aproximación que se adecue perfectamente a todas las aplicaciones distribuidas. En esta sección se describirán los tres tipos principales de modelos de comunicación. 16

49 Capítulo 1. Introducción a DDS a) Punto a punto: Teléfono, TCP. b) Cliente servidor: Sistema de archivos, base de Datos, RPC, CORBA. Información centralizada uno a muchos. data-space c) Mensajería publicación / subscripción: Distribución de datos muchos a muchos. Figura 1.2 Modelos de comunicación Modelo Punto a Punto: (Ver figura 1.2.a) Se trata de la forma más simple de comunicación, consiste en establecer una comunicación directa entre las dos entidades que van a intercambiar datos. Una vez que la comunicación se establece, es posible alcanzar una tasa de transferencia razonablemente elevada. Sin embargo, se trata de un modelo con escalabilidad reducida, generando un tráfico excesivo cuando aumenta el número de entidades que intercambian información. Modelo Cliente-servidor: Este modelo (ver figura 1.2.b) se caracteriza por una escalabilidad mucho más elevada que el anterior. En este modelo se designa un nodo servidor especial que se conecta simultáneamente a muchos nodos clientes, tratándose, por tanto, de una arquitectura muchos-a-uno. Es un modelo que funciona bien cuando la información está centralizada. Sin embargo, si la información es generada por múltiples nodos, requiere que toda la información sea enviada al servidor para una redistribución posterior a los clientes. Esta aproximación resulta ser ineficiente y elimina la predictibilidad de las comunicaciones, ya que los clientes no conocen cuándo está disponible la información, ya que el tiempo desde que la información está disponible en el servidor hasta que los clientes la solicitan añade retardo al sistema. La ventaja de este modelo es el desacoplo espacial entre los generadores de información (servidores) y los consumidores de la misma (clientes). Modelo Publicación-Subscripción: En este modelo (ver Figura 1.2.c) las aplicaciones se subscriben a los datos que necesitan y publican los datos que desean compartir. Los mensajes son transferidos directamente de los publicadores a los subscriptores, sin necesidad de ser transferidos directamente a un servidor central. Las arquitecturas publicación-subscripción son adecuadas para distribuir grandes cantidades de información con restricciones temporales de forma eficiente, incluso cuando existen mecanismos de entrega no fiables. Dado que la comunicación se produce de forma directa y simultánea, esta arquitectura es ideal para sistemas con flujos de datos complejos y de restricciones temporales críticas. Por tanto, la principal ventaja de este modelo frente a los anteriores es el desacoplo tanto espacial como temporal de la generación y recepción de información. 17

50 Plataforma de Trabajo Colaborativo sobre Middleware DDS Pese a sus muchas ventajas, el modelo PS no es la mejor opción en todos los tipos de comunicaciones, incluyendo: Transferencias de archivos Invocación de métodos remota (RMI) Arquitecturas basadas en conexión Transferencias síncronas Qué es DDS? El Servicio de Distribución de Datos es el estándar de middleware de red para aplicaciones de tiempo real distribuidas adoptado por el Grupo de Gestión de Objetos (OMG). La finalidad de DDS es simplificar el desarrollo, utilización y mantenimiento de aplicaciones con requisitos de tiempo real, proporcionando una distribución rápida y predecible de datos con restricciones de tiempo críticas permitiendo, además, trabajar sobre una gran variedad de protocolos de transporte. La especificación OMG-DDS describe dos niveles de interfaces: Un nivel bajo (DCPS) que se encarga de entregar la información a los destinatarios de forma eficiente [42]. DCPS es, además, una formalización (a través de una API estandarizada) del modelo publicación-subscripción. En la sección del presente capítulo se profundizará en este nivel. Un nivel superior (opcional), denominado Capa Local de Reconstrucción de Datos o DLRL (Data Local Reconstruction Layer) [43] [44]. El objetivo de esta capa actuar de interfaz entre la capa de aplicación y la capa DCPS. Se trata de una capa orientada a objetos, lo que permite que las aplicaciones de usuario puedan integrarla de forma simple. El Middleware DDS permite: Establecer comunicaciones complejas uno-a-muchos y muchos-a-muchos. La aplicación hace uso de la API (Application Programming Interface) estándar de la OMG (DDS) para publicar y subscribirse a datos. Personalizar aplicaciones con requisitos de tiempo-real, fiabilidad y QoS (Quality of Service). Proporcionar tolerancia a fallos y a los posibles eventos relacionados con las comunicaciones entre aplicaciones de forma transparente. Usar diferentes protocolos de transporte Qué es RTI DDS? RTI DDS es una implementación del protocolo DDS desarrollado por Real-Time Innovations. Dicha implementación proporciona los servicios de comunicación necesarios para que los diseñadores de aplicaciones distribuyan datos con restricciones de tiempo críticas entre dispositivos o nodos 18

51 Capítulo 1. Introducción a DDS embebidos y/o empresariales. Para ello, RTI DDS usa el modelo de comunicaciones publicaciónsubscripción con objeto de conseguir que la distribución de datos sea eficiente y robusta. RTI Data Distribution Service implementa la API DCPS del estándar DDS de la OMG para sistemas de tiempo real, la cual proporciona un método para transferir datos a un sistema distribuido eficiente en términos de retardo de procesamiento y muy escalable [45]. Se desarrolló con objeto de responder a la necesidad creciente de implementar CORBA [21] aplicando la aproximación publicaciónsubscripción con requisitos de tiempo real. Con RTI DDS, los diseñadores de sistemas y programadores trabajan sobre una infraestructura de comunicaciones flexible y tolerante a errores que funcionará sobre una gran variedad de arquitecturas hardware, sistemas operativos, lenguajes y protocolos de transporte. Para ello, RTI DDS es totalmente configurable, permitiendo a los programadores adaptarlo a sus necesidades. Características de RTI Data Distribution Service Como ya se ha indicado, RTI DDS soporta mecanismos que van más allá del modelo básico de publicación-subscripción. Como ya se ha indicado, la principal ventaja que aporta utilizar DDS es el desacoplo espacial y temporal entre la generación y el consumo de la información, lo que permite implementar aplicaciones más robustas frente a fallos en el intercambio de información. Además, RTI DDS proporciona un desacoplo total de las comunicaciones del resto de la aplicación. Gracias a esto, se reduce el tiempo de desarrollo de las aplicaciones: RTI DDS gestiona de forma totalmente transparente para el usuario los aspectos relativos a la entrega de mensajes, sin requerir la intervención de la aplicación, incluyendo: Determinar quién debe recibir mensajes Dónde se encuentran los destinatarios Qué ocurre si el mensaje no puede ser entregado RTI DDS ofrece un conjunto de políticas de calidad de servicio (QoS) mediante las que el usuario puede configurar los mecanismos de descubrimiento automático y especificar cómo se realiza el envío y recepción de datos. Por tanto, bastará con ajustar dichas políticas según las necesidades de la aplicación, sin que sea necesario ningún ajuste extra para establecer la comunicación. En el segundo capítulo de la presente memoria se profundizará en las políticas de calidad de servicio disponibles en RTI DDS. 1.2 Comunicaciones Publicación-Subscripción Centradas en Datos En este apartado se describe el modelo formal de comunicaciones usado en RTI DDS, el estándar Publicación-Subscripción Centrado en Datos Qué es DCPS? DCPS es la parte del estándar OMG DDS que lleva a cabo las comunicaciones publicaciónsubscripción. El estándar DDS define un modelo de comunicaciones publicación-subscripción independiente del lenguaje de programación, pudiendo ser implementado en cualquier lenguaje. Concretamente, RTI DDS ofrece versiones de la API DCPS para C, C++ y Java. 19

52 Plataforma de Trabajo Colaborativo sobre Middleware DDS El modelo publicación-subscripción para comunicaciones distribuidas es un mecanismo genérico que puede ser utilizado por diferentes tipos de aplicaciones. El modelo DCPS descrito en este apartado extiende el modelo de publicación-subscripción para adecuarse a las necesidades específicas de las aplicaciones con requerimientos de tiempo real y datos críticos. Como se puede observar, el término DCPS incluye las palabras centrado en datos, siendo éste el concepto fundamental soportado por el diseño de la API. En las comunicaciones centradas en datos, el intercambio de información entre las aplicaciones se realiza a través del así denominado dataspace. Un data-space es una abstracción compuesta por el conjunto de datos publicados y subscritos, de tal forma que la generación de información consistirá en publicar (escribir) en el data-space, mientras que el consumo de información (subscripción) se realizará leyendo del data-space. La información transferida en un modelo centrado en datos puede ser clasificada en tres grupos: señales, flujos y estados [42]. Las señales representad datos que cambian continuamente (por ejemplo, los valores medidos por un sensor de temperatura). Los flujos hacen referencia a los datos cuyos valores anteriores son relevantes. Finalmente, los estados engloban un conjunto de atributos de un sistema u objeto que son significativos independientemente de sus valores previos. Dicho estado no tiene por qué cambiar necesariamente en períodos fijos de tiempo, siendo relevante únicamente que los consumidores de información dispongan de los valores más actualizados de los datos. De este modo, si se pierde la actualización de un dato, no siempre será admisible esperar a que su valor cambie de nuevo. El modelo opuesto es el denominado centrado en objetos. Dicho modelo se centra en la idea de interfaz entre aplicaciones. Una interfaz es un conjunto de métodos de tipos conocidos (número y tipos de argumentos de entrada a los métodos). En este modelo la comunicación se basa en la invocación de métodos por parte de los clientes sobre las interfaces que son servidas por los servidores. DCPS con Requerimientos de Tiempo Real DCPS, y concretamente la implementación RTI DDS es adecuada para desarrollar aplicaciones de tiempo real. A continuación se presentan algunos de los requerimientos habituales de las aplicaciones de tiempo real: Eficiencia: Los sistemas de tiempo real requieren que la entrega de la información esté acotada en el tiempo. Esto implica introducir retardos mínimos en la transferencia de datos. El modelo de publicación-subscripción permite reducir la latencia introducida con respecto a la necesaria en el modelo cliente-servidor, ya que elimina la necesidad de enviar un mensaje de solicitud por parte de los clientes: tan pronto como los datos están disponibles, estos son suministrados a los subscriptores. Para ello, el modelo DCPS aplica una aproximación basada en listeners para el acceso a la información [42]. Un listener es un objeto que implementa una interfaz específica y que en este caso permite al middleware DDS informar asíncronamente de los cambios que se producen en los datos intercambiados. Pese a que esta aproximación es simple y eficaz, tiene el inconveniente de que el acceso a los datos se realiza en el contexto de una hebra en el middleware, lo que puede ser complejo cuando existen varias hebras externas interactuando con el mismo [46], [47], [48], [49], [50]. 20

53 Capítulo 1. Introducción a DDS Determinismo: Las aplicaciones de tiempo real a menudo requieren que el retardo y periodo de entrega de los datos sea determinista. Al añadir búferes al flujo de datos con el fin de asegurar conexiones seguras, los nuevos datos pueden permanecer sin ser entregados durante una cantidad de tiempo impredecible, esperando confirmación. Dado que el modelo publicación-subscripción no requiere conexiones fiables, implementaciones como RTI DDS pueden proporcionar un compromiso configurable entre entrega determinista y fiabilidad de la misma, mediante la adopción de un modelo best effort o fiable dependiendo de las necesidades de la aplicación. Ancho de banda flexible: Los sistemas de tiempo real típicos incluyen tanto nodos de tiempo real como nodos que no lo son. Los requerimientos de ancho de banda para dichos nodos varían enormemente. Por ejemplo, una aplicación podría enviar muestras de datos más rápido de lo que una aplicación que no es de tiempo real podría procesar y, sin embargo, podría ser necesario recibir los datos tan rápido como se producen en otra aplicación de tiempo real. DCPS permite a los subscriptores de unos determinados datos configurar individualmente cómo de rápido deben ser entregados a cada subscriptor. Este punto se tratará con mayor profundidad cuando se describan las políticas de calidad de servicio en el capítulo 2. Tareas multihebra: Las comunicaciones de tiempo real han de trabajar sin ralentizar las hebras que envían las muestras de datos. En el lado del receptor, algunos flujos de datos deben tener mayor prioridad que otros. RTI DDS permite configurar a nivel de usuario la prioridad de las distintas hebras. Los usuarios pueden configurar RTI DDS para que las distintas hebras sean creadas con diversas prioridades para procesar los datos de diversos flujos. Operación tolerante a fallos: Las aplicaciones de tiempo real a menudo trabajan en entornos sometidos a fallos. A menudo, dichos sistemas son críticos o pueden acarrear pérdidas económicas si ven reducida su disponibilidad. Las aplicaciones que trabajan en dichos sistemas han de ser, por tanto, tolerantes a fallos mediante redundancia hardware y software. Muchas veces es necesario no sólo que existan sistemas redundantes, sino que estos respondan en el mismo momento en que el fallo aparece. El modelo de publicaciónsubscripción es capaz de soportar conectividad muchos a muchos con publicadores y subscriptores de información redundantes. Esta característica es ideal para construir aplicaciones tolerantes a fallos y con elevada disponibilidad. Como se verá más adelante, aunque esta característica no es directamente aplicable a los streams de vídeo y audio presentes en una multiconferencia, sí puede ser útil para implementar los servicios de directorio del sistema. DCPS, y por tanto RTI DDS, fue diseñado e implementado específicamente para responder a las necesidades de los distintos escenarios mediante la configuración de una serie de políticas de calidad de servicio definidas en el estándar DCPS. 21

54 Plataforma de Trabajo Colaborativo sobre Middleware DDS Terminología y conceptos adicionales Tipos de datos En las comunicaciones centradas en datos, las aplicaciones que participan en la comunicación han de compartir una visión común de los tipos de datos que están siendo transmitidos. Los lenguajes de programación tienen muchos tipos primitivos que pueden ser utilizados y compartidos por los usuarios de dichos lenguajes (enteros, punto flotante, caracteres, booleanos, etc.). Sin embargo, en cualquier sistema no trivial aparecen tipos específicos construidos más allá de las primitivas del lenguaje mediante estructuras más complejas, lo que complica su transmisión entre diferentes lenguajes. Con objeto de solventar este problema, las aplicaciones que usan DCPS disponen de información sobre la estructura de los datos, lo que se consigue mediante el estándar de descripción de datos OMG IDL [51], [52], [53]. Entidades DCPS Para establecer comunicaciones publicación-subscripción en DCPS las aplicaciones deben usar la API disponible para crear entidades. En esta sección se introducen las entidades DCPS que el usuario debe crear para enviar y recibir datos. En la figura 1.3 se presenta una visión general de dichas entidades. 1 1 Tópico Publicador Subscriptor 1 1 * * * DataWriter DataReader * Publicación Subscripción Figura 1.3 Entidades DCPS [42] El conocimiento de los tipos de datos es un requerimiento para las diferentes aplicaciones que se comunican con DCPS. Las aplicaciones deben compartir un medio para identificar, además, qué datos han de ser compartidos. Con este fin aparece el concepto de tópico: un tópico es un canal lógico para el intercambio de información entre publicadores y subscriptores (ver figura 1.4). Aunque un tópico sólo puede tener un tipo de dato, varios tópicos pueden corresponder a un mismo tipo. Los tópicos permiten interconectar los DataWriters y DataReaders: Un DataWriter es un objeto de una determinada aplicación que notifica al data-space que hay nuevos valores para un determinado tópico, mientras que un DataReader es un objeto que indica al data-space que desea recibir valores de un tópico. Tanto los DataWriters como los DataReaders podrán estar asociados a un único tópico. No obstante, un tópico podrá tener varios DataReaders y DataWriters asociados. 22

55 Capítulo 1. Introducción a DDS Tópico = Noticias Tópico = Noticias Publicador Subscriptor Envío Servicio de Entrega Recepción 17 Mayo: Titular Muestra Figura 1.4 Comunicación a través de tópicos Un publicador es el objeto DCPS encargado de enviar los datos, para lo que ha de gestionar DataWriters. Un DataWriter puede pertenecer a un único publicador, aunque un publicador sí puede disponer de varios DataWriters. Por otra parte, los subscriptores son los responsables de recibir los datos a través de la gestión de los DataReaders. Al igual que ocurre en el caso de los publicadores, aunque un subscriptor puede gestionar varios DataReaders, un DataReader sólo puede estar asociado a un subscriptor. Muestras, instancias y claves El valor de los datos asociados a un tópico puede cambiar con el tiempo: una muestra es cada uno de los diferentes valores que toma el tópico en el tiempo. Además, un tópico puede estar compuesto por varios campos: con el fin de agrupar dichos campos aparece el concepto de instancia, que se define como un conjunto de campos identificados de forma unívoca mediante una clave. El estándar permite la existencia de tópicos sin clave: en estos casos se considera que el tópico está compuesto por una única instancia. Cuando una aplicación se subscribe a un tópico, recibirá muestras que actualizarán el valor de las instancias de dicho tópico. Por otro lado, los conceptos de instancia y clave aportan una gran flexibilidad al sistema, permitiendo que un publicador pueda actualizar una, todas o varias instancias de un tópico o que un subscriptor pueda recibir datos de un grupo de instancias sin poseer un conocimiento previo de qué flujos de datos existen actualmente. Dominios y DomainParticipants Con el fin de poder aislar varias aplicaciones que se comunican mediante DCPS en una red común, es necesario introducir un nuevo concepto: el dominio. Un dominio representa un conjunto de entidades DDS totalmente aisladas. Cuando varias aplicaciones pertenecientes a diferentes dominios se ejecutan en un mismo host, permanecen totalmente aisladas entre sí, por lo que los DataWriters y DataReaders de diferentes dominios nunca pueden intercambiar datos. Por tanto, es necesario que las aplicaciones que han de cambiar datos pertenezcan a un mismo dominio. Para ello, la DCPS API permite crear y configurar los denominados 23

56 Plataforma de Trabajo Colaborativo sobre Middleware DDS DomainParticipant. Un DomainParticipant es la asociación existente entre un publicador o subscriptor y el dominio al que pertenece (que se identifica mediante un valor entero denominado índice de dominio). Si fuera necesario que una aplicación participe en varios dominios de forma simultánea, será necesario crear tantos DomainParticipants como dominios se desee. Es importante aclarar que los Publicadores/DataWriters y Subscriptores/DataReaders pueden estar asociados a un único DomainParticipant, por lo que habrá que crear nuevas entidades para cada DomainParticipant que se utilice. El concepto de dominio permite garantizar, por tanto, que los datos generados por un usuario de un dominio no serán entregados a otro situado en un dominio diferente de forma accidental. Además, los dominios pueden ser utilizados para escalar y construir sistemas complejos compuestos por subsistemas multinodo Calidad de Servicio (QoS) El modelo DCPS descrito aquí extiende el modelo publicación-subscripción para responder a las necesidades de aplicaciones de tiempo real con datos críticos. Para ello, proporciona una serie de mecanismos estandarizados conocidos como políticas de calidad de servicio, que permiten configurar cómo se produce la comunicación, para así limitar los recursos utilizados por el middleware con objeto de detectar incompatibilidades en el sistema y configurar rutinas de gestión de errores. Además, las políticas de QoS aligeran a la aplicación librándola de ciertas tareas que pueden ir desde el filtrado de información hasta el almacenamiento temporal de datos, reduciendo por tanto su complejidad. El presente proyecto dedica el capítulo 2 al estudio de las políticas de calidad de servicio ofrecidas por DDS, así como su aplicación para aplicaciones de multiconferencia Descubrimiento de Aplicaciones El modelo DCPS proporciona comunicaciones muchos-a-muchos anónimas y transparentes. Cada vez que una aplicación envía una muestra de un tópico, el middleware distribuye la muestra a todas las aplicaciones subscritas a dicho tópico. La aplicación que publica no necesita conocer cuántas aplicaciones reciben el tópico, ni dónde se localizan las aplicaciones. De forma similar, las aplicaciones subscritas no conocen el origen de los datos publicados. De hecho, los publicadores y subscriptores pueden aparecer y desaparecer, encargándose el middleware de gestionar dichos cambios. Para conseguir que el sistema funcione correctamente, DDS debe gestionar una lista con las aplicaciones que se han subscrito a un tópico, los nodos donde se encuentran y algunos parámetros adicionales de QoS. Además, DDS debe mantener una lista de las aplicaciones y publicadores existentes para cada uno de los tópicos a los que se ha subscrito una aplicación. Al proceso por el cual se propaga la información acerca de la existencia de publicadores y subscriptores y las políticas de QoS asociadas a los mismos se lo conoce como descubrimiento. El estándar DCPS no describe cómo se debe producir dicho descubrimiento. Para este fin la implementación RTI DDS utiliza el estándar RTPS (Publicación Subscripción de Tiempo Real) que además de proporcionar los mecanismos necesarios para el descubrimiento facilita procedimientos 24

57 Capítulo 1. Introducción a DDS para la construcción de los paquetes de datos que se intercambiarán entre los publicadores y subscriptores [54]. Cuando se crea un DomainParticipant, RTI DDS envía paquetes de anuncio al dataspace. Si una aplicación descubre otra que pertenece a su dominio, intercambian información sobre los publicadores, subscriptores y sobre sus políticas QoS asociadas. Este proceso es totalmente configurable mediante diversos métodos que RTI DDS pone a disposición del usuario Conclusiones En este capítulo se ha explicado en qué consiste el middleware de red, así como el modelo de publicación-subscripción. Asimismo, se han estudiado los fundamentos del estándar OMG DDS y la implementación comercial RTI DDS. Finalmente, se han descrito los principales aspectos de la capa DCPS de DDS. En el siguiente capítulo se profundizará en las políticas de calidad de servicio recogidas por el estándar DDS, destacando aquellas que son especialmente adecuadas para el intercambio de audio y vídeo. 25

58 Plataforma de Trabajo Colaborativo sobre Middleware DDS 26

59 Capítulo 2. Políticas QoS en DDS Este capítulo se centra en la identificación de las políticas de calidad de servicio necesarias para el intercambio de audio y vídeo a través de la red. Se trata de un apartado fundamental para conseguir satisfacer las demandas de las aplicaciones de transmisión de vídeo y audio. 2.1 Control de las comunicaciones mediante políticas de QoS Las políticas de QoS controlan gran cantidad de aspectos relacionados con la forma en la que se distribuyen los datos entre las aplicaciones. La QoS conjunta de un sistema DCPS está determinada por las políticas de QoS configuradas para cada entidad DCPS. De este modo, hay políticas para los tópicos, DataWriters, publicadores, DataReaders, subscriptores y DomainParticipants. En el lado del publicador, las políticas QoS de cada tópico, DataWriter y publicador controlan cómo y cuándo se envían los datos al middleware. De forma similar, las QoS de los tópicos, DataReader y subscriptores controlan el comportamiento en el lado del subscriptor. Los usuarios pueden emplear las políticas de QoS para configurar cómo se produce el intercambio de datos, pudiendo configurar de forma transparente a la aplicación ciertas tareas que pueden ir desde el filtrado de información hasta el almacenamiento temporal de datos. Algunas de las políticas de QoS establecen un contrato entre las publicaciones y subscripciones. En estos casos, únicamente se establecerá la comunicación si las políticas de QoS configuradas en el DataWriter y DataReader son compatibles. La evaluación de la compatibilidad de políticas de QoS se realiza de forma transparente a la aplicación, mediante a un mecanismo de DCPS denominado RxO (Request versus Offered). Cuando un DataReader se une a un data-space, especifica un determinado valor requerido para las políticas QoS que utilizan RxO. Por otro lado, cuando un DataWriter se une a un data-space indica un determinado valor ofrecido para las políticas QoS con RxO. Finalmente, RTI DDS emparejará las entidades que son compatibles entre sí en términos de RxO, permitiendo que se descubran entre sí. En el caso de que un DataWriter no pueda satisfacer las políticas de QoS solicitadas por un DataReader, no se produce el descubrimiento entre ellos y ambos son notificados de la incidencia. 27

60 Plataforma de Trabajo Colaborativo sobre Middleware DDS 2.2 Políticas QoS adecuadas para Audio/Vídeo [1], [55] La implementación RTI DDS cuenta con más de cuarenta políticas de calidad de servicio. En la tabla 2.1 se presentan las políticas de calidad de servicio ofrecidas por RTI DDS que son adecuadas para la transmisión de audio y vídeo en sistemas de multiconferencia. Se incluye en la misma el nombre de la política, una breve descripción, las entidades que disponen de dicha política, si utiliza RxO, así como información sobre si se puede modificar tras su creación. Además, el campo extensión DDS indica si se trata de políticas no recogidas por el estándar OMG DDS [1]. Política QoS Descripción Entidades DEADLINE DESTINATION_ORD ER DISCOVERY DISCOVERY_CONFI G DOMAIN_PARTICIP ANT_RESOURCE_LI MITS DURABILITY HISTORY LATENCYBUDGET LIFESPAN LIVELINESS Tiempo permitido entre las actualizaciones de una instancia. Controla cómo se presentan las muestras de diferentes DataWriters de una misma instancia al correspondiente DataReader. Configura cómo las aplicaciones RTI DDS se descubren entre sí. Configura el proceso de descubrimiento: qué temporizadores se usan, cuáles son los límites de recursos, etc. Límite de recursos para el DomainParticipant. Controla si las muestras antiguas se guardan y envían a los nuevos DataReaders que se unan a la red. Si se almacenan y, en caso afirmativo, cuántas muestras de una instancia se almacenan en los DataWriters o DataReaders. Sugiere cuánto retardo es aceptable en la transmisión de datos. Actualmente, RTI DDS no hace uso de esta información.. El tiempo durante el que una muestra enviada por un DataWriter debe ser considerada válida. Configura parámetros que sirven para determinar si un DataWriter sigue activo. T, DW, DR T, DW, DR Modifi -cable Sí Hasta que se active RxO Sí Sí Ext. DDS DP No No Sí DP No No Sí DP No No Sí T, DW, DR T, DW, DR T, DW, DR Hasta que se active Hasta que se active Sí No No Sí T, DW Sí No T, DW, DR Hasta que se active Sí Sí 28

61 Capítulo 2. Políticas de QoS en DDS Política QoS Descripción Entidades OWNERSHIP OWNERSHIP_STREN GHT PARTITION PRESENTATION PUBLISH_MODE READER_DATA_LIF ECYCLE RELIABILITY TIME_BASED_FILT ER TRANSPORT_PRIOR ITY TRANSPORT_MULTI CAST TRASNPORT_UNICA ST Controla si es posible que varios DataWriters modifiquen la misma instancia de un Tópico. Necesario para discernir qué DataWriters pueden escribir una instancia de un Tópico. Para crear particiones lógicas que dividen el dominio DDS. Controla el orden en el que se presentarán las diferentes muestras. Determina el modo de publicación de los DataWriters, asíncrono o síncrono. Controla durante cuánto tiempo un DataReader almacena muestras de instancias cuyos writers ya no están activos. Especifica si RTI DDS debe enviar datos de forma fiable. Especifica un tiempo mínimo entre la entrega de nuevas muestras de una instancia al DataReader. RTI DDS no entrega muestras que se publiquen más rápido que dicho tiempo. El efecto depende de la implementación de los protocolos de transporte utilizados para enviar datos. Sugiere la prioridad deseada. Especifica un conjunto de direcciones multicast a las que los DataWriters deberían publicar los datos. Especifica un conjunto de direcciones y puertos unicast a las que los DataWriters deberían publicar los datos. T, DW, DR Modifi -cable Hasta que se active RxO Sí DW Sí No Pub, Sub Sí No Pub, Sub Hasta que se active Sí Ext. DDS DW No No Sí DR Sí No T, DW, DR Hasta que se active Sí DR Sí No T, DW Sí No DR No No Sí DW, DR, DP Tabla 2.1 Políticas de QoS adecuadas para transmisión de audio y vídeo No No Sí 29

62 Plataforma de Trabajo Colaborativo sobre Middleware DDS A continuación se profundizará en aquellas políticas QoS que se han considerado de mayor utilidad para el intercambio de audio y vídeo Política DEADLINE Desde la perspectiva de un DataWriter, esta política fija el máximo periodo que puede transcurrir entre la publicación de dos muestras consecutivas. En el caso del DataReader, establece el período máximo en el que una aplicación espera recibir nuevos valores para un tópico. En el caso de tópicos con claves, la política DEADLINE se aplica separadamente a cada instancia. Una aplicación deberá llamar al método write() (método presente en cada DataWriter y que se encarga de publicar una nueva muestra) para cada instancia conocida del tópico en el tiempo especificado por la política DEADLINE en el DataWriter o recibir un nuevo valor de cada instancia conocida en el caso del DataReader. El contador se reinicializa con cada llamada a write() o con la recepción de una nueva muestra para dicha instancia. La política DEADLINE únicamente tiene un parámetro, tal y como se muestra en la tabla 2.2. Por defecto el valor de dicho parámetro es INFINITE, es decir, nunca expira. Tipo de Dato Parámetro Descripción DDS_Duration_t period DataWriters: tiempo máximo entre la actualización del valor de una instancia. DataReaders: tiempo máximo entre la recepción de nuevos valores para una instancia. Expresado en nanosegundos. Tabla 2.2 Política DEADLINE Cuando expira el tiempo fijado por la política DEADLINE, RTI DDS lleva a cabo las siguientes acciones: En los DataWriters: Se modifica la estructura DDS_OFFERED_DEADLINE_STATUS, la cual recoge información sobre la incidencia y se produce una llamada a un método on_offered_deadline_missed() del listener asociado al DataWriter. En los DataReaders: Se modifica la estructura DDS_REQUESTED_DEADLINE_MISSED_STATUS, que recoge información de la incidencia y se produce una llamada al método on_requested_deadline_missed() del listener asociado al DataReader. En el caso de los DataReaders, si se configura de forma inapropiada esta política y se activa TIME_BASED_FILTER (discutida posteriormente) pueden aparecer comportamientos inesperados, de forma que el DataReader perciba violaciones de la política aunque el DataWriter actualice las instancias adecuadamente. Por ello se recomienda que se configure de acuerdo a la siguiente regla: reader deadline period >= reader minimum_separation + writer deadline period 30

63 Capítulo 2. Políticas de QoS en DDS Aunque es posible configurar esta política en los tópicos, su valor se utilizará únicamente para inicializar los DataReaders y DataWriters. Por último, indicar que esta política puede ser utilizada en combinación con OWNERSHIP para determinar qué DataWriter está autorizado a actualizar una instancia. En el apartado del presente capítulo se profundizará en este aspecto. Propiedades Aunque esta política puede ser cambiada en cualquier momento, es necesario que los periodos fijados a ambos lados de la comunicación sean compatibles, es decir, que el periodo configurado en el DataWriter sea menor o igual que el fijado en el DataReader. Si los periodos son incompatibles, se modifican los valores de las estructuras ON_OFFERED_INCOMPATIBLE_QOS y ON_REQUESTED_INCOMPATIBLE_QOS y se llaman a los correspondientes listeners de los DataReaders y DataWriters implicados. Utilidad para transmisión de audio y vídeo Esta política es de gran utilidad para el control de sesiones interactivas de audio y vídeo, al constituir un indicador del estado de congestión de la red o de los publicadores/subscriptores que envían/procesan dichos flujos multimedia. De este modo, con una adecuada configuración del valor de máximo retardo entre dos actualizaciones de una instancia (en el sistema propuesto cada instancia corresponde a un flujo multimedia) se pueden detectar problemas en la transmisión y actuar en consecuencia. Esto es posible ya que, como se ha visto, al producirse la expiración del contador de DEADLINE, RTI DDS produce una llamada a un método cuya implementación puede ser modificada en el DataWriter o en el DataReader según corresponda. El procedimiento seguido cuando se producen violaciones de la política DEADLINE será desarrollado en los capítulos 3 y 4 del presente proyecto Política LIFESPAN El propósito de esta política es evitar la entrega de datos que, debido a retardo en su entrega, ya no tienen validez. De este modo, cada muestra de datos escrita por un DataWriter tiene asociado un tiempo de expiración, a partir del cual no debe ser entregada a ninguna aplicación. Una vez que la muestra expira, los datos serán eliminados de las caché de los DataReaders, así como de las cachés de los servicios de persistencia de datos de DDS. El tiempo de expiración de cada muestra se calcula sumando el valor de la política LIFESPAN y el instante de tiempo en que se emitió el paquete, indicado por la marca de tiempo del paquete. Para evitar inconsistencias, se recomienda que todos los DataWriters asociados a la misma instancia tengan configurado el mismo valor para esta política QoS. En la tabla 2.3 se muestra el parámetro que esta política permite configurar. Tipo de Dato Parámetro Descripción DDS_Duration_t duration Máximo periodo de validez del paquete. 31

64 Plataforma de Trabajo Colaborativo sobre Middleware DDS Tabla 2.3 Política LIFESPAN Aunque es posible configurar esta política en los tópicos, su valor se utilizará únicamente para inicializar los DataReaders y DataWriters. Propiedades Esta política puede ser modificada tras su activación. Dado que no se aplica a los DaraReaders, no hay restricciones en cuanto a compatibilidad entre publicadores y subscriptores. Utilidad para transmisión de audio y vídeo Esta política permite desestimar aquellos paquetes que tienen un retardo excesivo, por lo que es especialmente útil aplicaciones de tipo interactivo, donde los paquetes que tienen un retardo superior a cierto límite dejan de ser válidos y han de ser eliminados de los búferes Política LIVELINESS Esta política permite especificar cómo RTI DDS comprueba si un DataWriter sigue activo. Además, puede ser utilizada en combinación con otras políticas como OWNERSHIP para determinar quién puede actualizar una instancia (esta aplicación será discutida en el apartado 2.2.4). En la tabla 2.4 se incluyen los parámetros que se pueden configurar en esta política. Como vemos, mediante el parámetro kind de esta política se puede especificar el mecanismo que se utilizará para comprobar la permanencia de un DataWriter. Por otro lado, el parámetro lease_duration especifica el máximo periodo en el que los paquetes de notificación de no-inactividad han de ser enviados a los DataReaders correspondientes. Tipo de Dato Parámetro Descripción DDS_Liveliness QosPolicyKind kind DDS_AUTOMATIC_LIVELINESS_QOS: RTI DDS notificará de forma automática la permanencia de cada DataWriter dentro del periodo especificado en el parámetro lease_duration. DDS_MANUAL_BY_PARTICIPANT_ LIVELINESS_QOS: Se asume que el DataWriter sigue activo si cualquier entidad perteneciente al mismo DomainParticipant lo notifica. DDS_MANUAL_BY_TOPIC_ LIVELINESS_QOS: Es tarea de la aplicación notificar de forma explícita que el DataWriter permanece activo. DDS_Duration_t lease_duration Es el tiempo máximo en el que se debe enviar una notificación garantizando la continuidad de un DataWriter. 32

65 Capítulo 2. Políticas de QoS en DDS Tabla 2.4 Política LIVELINESS Por tanto, en el caso de los DataReaders especifica el máximo periodo en el que se esperan datos de un DataWriter, considerando que éste ha abandonado el sistema pasado dicho tiempo. Los mecanismos disponibles son: DDS_AUTOMATIC_LIVELINESS_QOS: El DomainParticipant es el responsable de enviar paquetes para indicar que un DataWriter sigue activo dentro del periodo establecido en lease_duration. Este mecanismo detecta la finalización de una aplicación que publicaba datos. Sin embargo, no cubre los casos en los que la aplicación permanece activa pero en un estado erróneo (lo que puede llevar a que el DomainParticipant continúe notificando la presencia del DataWriter pero no se produzcan llamadas al método write() del DataWriter). Este método aunque menos preciso suele ser el más adecuado. DDS_MANUAL_BY_PARTICIANT_LIVELINESS_QOS: Cuando la aplicación de usuario ha notificado que al menos uno de los DataWriters pertenecientes al mismo DomainParticipant (o el propio DomainParticipant) continúa activo, todos los DataWriters pertenecientes a dicho DomainParticipant son considerados activos. Esta configuración es un compromiso entre control y sencillez de uso. DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS: Un DataWriter es considerado activo únicamente si la aplicación llama de forma explícita a los métodos encargados de notificar su permanencia en el sistema. Esta configuración es la que más control aporta a la aplicación, pero es más compleja de gestionar. Al configurar esta política con las configuraciones de tipo manual la aplicación de usuario se hace responsable de notificar la permanencia de los DataWriters, ya sea de forma explícita mediante el método assert_liveliness() en el DataWriter, o bien de forma implícita mediante el método write(). Cuando RTI DDS percibe que ha expirado el tiempo de notificación de un DataWriter, una hebra interna modifica la estructura DDS_LIVELINESS_LOST_STATUS y llama al método on_liveliness_lost() del listener asociado a dicho DataWriter si existe. En el caso de los DataReaders, cuando RTI DDS determina que un DataWriter asociado no continúa activo se modifica la estructura DDS_LIVELINESS_CHANGED_STATUS de los DataReaders implicados y se llama al método on_liveliness_changed() de los listeners vinculados a los mismos. Aunque es posible configurar esta política en los tópicos, su valor se utilizará únicamente para inicializar los DataReaders y DataWriters. 33

66 Plataforma de Trabajo Colaborativo sobre Middleware DDS Propiedades Esta política no puede ser modificada una vez ha sido activada. Además, los DataWriters y DataReaders deben tener configuraciones compatibles para esta política. Para ser compatibles han de cumplir dos condiciones: 1. El parámetro lease_duration del DataWriter debe ser menor o igual que el del DataReader. 2. Los DataWriters y DataReaders deben usar una de las configuraciones compatibles que se muestran en la tabla 2.5. En el caso de encontrarse incompatibilidad, se modificarán los valores de las estructuras ON_OFFERED_INCOMPATIBLE_QOS y ON_REQUESTED_INCOMPATIBLE_QOS y se llamará a los correspondientes listeners de los DataReaders y DataWriters implicados. DataReader DataWriter MANUAL_BY_ TOPIC MANUAL_BY_ PARTICIPANT AUTOMATIC MANUAL_BY_ TOPIC Compatible Compatible Compatible MANUAL_BY_ PARTICIPANT Incompatible Compatible Compatible AUTOMATIC Incompatible Incompatible Compatible Tabla 2.5 Combinaciones Permitidas para la Política LIVELINESS Consideraciones adicionales Una hebra interna de RTI DDS se encarga de comprobar periódicamente el estado de esta política para todos los DataWriters. Por tanto, cuanto menor sea el valor del periodo lease_duration mayor será la carga de la CPU del sistema, pues dicha hebra se despertará con mayor frecuencia. Asimismo, la carga de la red aumentará debido al tráfico adicional que generan los mensajes de notificación (esto es especialmente notorio con el mecanismo AUTOMATIC). Por tanto, es necesario tener precaución al configurar esta política. Utilidad para Transmisión de Audio y Vídeo Esta política permite gestionar de forma transparente a la aplicación la salida de usuarios de la sala de conferencia de nuestro sistema. De este modo, cuando un DataWriter deja de estar activo RTI DDS notifica a la aplicación, con lo que esta interpretará que el participante de la sala de conferencia vinculado a dicho DataWriter ha abandonado la sala Política OWNERSHIP Política que determina si un DataReader recibirá los cambios que múltiples DataWriters realicen sobre una instancia de un tópico. Para tópicos sin clave se considera una única instancia por tópico. Esta política incluye un único dato miembro, que se muestra en la tabla

67 Capítulo 2. Políticas de QoS en DDS Tipo de Dato Parámetro Descripción DDS_Ownership QosPolicyKind kind DDS_SHARED_OWNERSHIP_QOS o DDS_EXCLUSIVE_OWNERSHIP_QOS Tabla 2.6 Política OWNERSHIP El tipo de OWNERSHIP puede ser fijado a uno de los siguientes valores: SHARED: Este es el valor por defecto de la política y no aplica ningún tipo de restricción al flujo de datos entre DataWriters y DataReaders. Por tanto, los DataReaders recibirán las modificaciones efectuadas por todos los DataWriters. EXCLUSIVE: Cuando se aplica cada instancia podrá ser actualizada por un único DataWriter, que es considerado el dueño de la misma. Esto implica que las actualizaciones efectuadas por el resto de DataWriters serán simplemente ignoradas (sin que se generen errores ni ningún tipo de notificación). Aunque es posible configurar esta política en los tópicos, su valor se utilizará únicamente para inicializar los DataReaders y DataWriters. Cómo se selecciona qué DataWriter es el dueño de la instancia Cuando el tipo de OWNERSHIP es de tipo EXCLUSIVE, el dueño de una instancia será el DataWriter activo (en términos de la política LIVELINESS) que no haya violado la política DEADLINE del DataReader y que tenga un valor mayor para la política OWNERSHIP_STRENGTH (discutida en el apartado 2.2.5). Como ya se indicó, si un tópico tiene clave esta política se aplicará por separado a cada instancia de dicho tópico. Por tanto, un DataReader podrá recibir datos de un DataWriter con una OWNERSHIP_STRENGTH menor que la de otro DataWriter perteneciente al mismo data-space siempre y cuando este último no actualice valores para dicha instancia. Si se diera el caso de que existieran varios DataWriters con la misma OWNERSHIP_STRENGTH actualizando una instancia, únicamente aquel con el menor GUID (Globally Unique Identifier) de dicho tópico será considerado el dueño de la instancia. El dueño de una instancia cambiará en los siguientes casos: Cuando un DataWriter con una mayor OWNERSHIP_STRENGTH publica valores para dicha instancia. La OWNERSHIP_STRENGTH del DataWriter cambia dinámicamente a un valor menor que el de otro DataWriter existente. El DataWriter dueño deja de estar activo (según lo desarrollado en el punto 2.2.3). El DataWriter dueño viola la política DEADLINE (según lo desarrollado en el punto 2.2.1). 35

68 Plataforma de Trabajo Colaborativo sobre Middleware DDS Es importante aclarar que los cambios de dueño de una instancia no se coordinan de forma sincronizada entre los distintos DataReaders, por lo que es posible que diferentes aplicaciones no determinen que la política OWNERSHIP ha cambiado exactamente al mismo tiempo. Propiedades Esta política no puede ser modificada una vez que la entidad ha sido activada. Además, debe tener la misma configuración en el lado del publicador y del subscriptor. Si un DataWriter y un DataReader del mismo tópico tienen distintas configuraciones se procederá a cambiar las estructuras ON_OFFERED_INCOMPATIBLE_QOS y ON_REQUESTED_INCOMPATIBLE_QOS de los mismos y a llamar a los métodos correspondientes de sus listeners asociados. Utilidad para transmisión de audio y vídeo Esta política suele tener aplicaciones para el despliegue de sistemas redundantes con un mínimo esfuerzo. Pese a que el sistema que nos ocupa (sistema de multiconferencia) no suele requerir este tipo de características, la política OWNERSHIP puede ser utilizada para implementar un servicio de voz moderada en el sistema. De este modo, el servicio de moderación del canal de voz utiliza la política OWNERSHIP para gestionar que sólo uno de los participantes de la sala de conferencias (el que tenga la palabra en ese momento según su valor para la política OWNERSHIP_STRENGTH) pueda actualizar el tópico en el que se publica la señal de voz Política OWNERSHIP_STRENGTH Esta política se utiliza para dar una puntuación a cada DataWriter, puntuación con la que se puede decidir qué DataWriter es el dueño de una instancia cuando la política OWNERSHIP está configurada como EXCLUSIVE. Esta política incluye un único dato miembro, que se muestra en la tabla 2.7. Tipo de Dato Parámetro Descripción DDS_long value Es un valor entero que determina la puntuación de un DataWriter en términos de OWNERSHIP Tabla 2.7 Política OWNERSHIP_STRENGTH Propiedades Esta política puede cambiarse en cualquier momento. No se aplica a los DataReaders, por lo que no hay ningún tipo de requerimiento para que se produzca comunicación entre los DataWriters y DataReaders. Utilidad para transmisión de audio y vídeo Como se indicó en el apartado , esta política puede ser utilizada para decidir qué participante de la sala de conferencia tiene derecho a utilizar el canal de voz. Para ello, el moderador de la sala deberá poder indicar a cada participante qué valor de OWNERSHIP_STRENGTH tiene en cada momento. 36

69 Capítulo 2. Políticas de QoS en DDS Política PRESENTATION La política PRESENTATION está especificada para evitar la entrega desordenada de paquetes. Esta política permite controlar cómo un subscriptor ordena las muestras recibidas en el DataReader. PRESENTATION tiene tres parámetros: el booleano coherent_access, el booleano orderer_access y el tipo de ordenación access_scope. En la tabla 2.8 se mostrará esta estructura. Tipo de Dato Parámetro Descripción DDS_Presentation_ QosPolicyAccess ScopeKind access_scope Controla la granularidad utilizada cuando coherent_access y/o ordered_access están fijados a TRUE. Si ambos son FALSE, esta característica no se aplica. DDS_INSTANCE_PRESENTATION_ QOS: las muestras se ordenan por instancia. DDS_TOPIC_PRESENTATION_QOS: las muestras se ordenan por tópico DDS_Boolean coherent_access Controla si RTI DDS preserva los cambios hechos por el publicador mediante las operaciones begin_coherent_changes() y end_coherent_changes(). DDS_BOOLEAN_FALSE: La coherencia no se preserva. DDS_BOOLEAN_TRUE: Los cambios efectuados por el DataWriter serán recibidos por el DataReader de forma coherente, basado en el valor de access_scope. DDS_Boolean ordered_access Controla si RTI DDS preserva el orden de los cambios. Tabla 2.8 Política PRESENTATION DDS_BOOLEAN_FALSE: El orden de las muestras sólo se preserva por instancia. DDS_BOOLEAN_TRUE: Se preserva el orden de las muestras según el valor de access_scope. 37

70 Plataforma de Trabajo Colaborativo sobre Middleware DDS Acceso coherente Un conjunto de muestras coherente consiste en una serie de muestras que deben ser propagadas en un determinado orden hasta el subscriptor. Por tanto, el subscriptor únicamente podrá leer las muestras cuando tenga todos los datos. La coherencia permite a una aplicación cambiar el valor de varias instancias de datos asegurando que todos esos cambios se entregarán como un único set a los DataReaders. Para enviar un set de muestras coherentes la aplicación utilizará los métodos begin_coherent_changes() y end_coherent_changes(). Si se activa el acceso coherente a los datos, access_scope controlará el efecto de los cambios coherentes: Si access_scope está configurado como INSTANCE, los métodos relacionados con el acceso coherente no tendrán ningún efecto, ya que los cambios en diferentes instancias serán considerados independientes. Si access_scope es del tipo TOPIC, los cambios coherentes se aplicarán a todas las instancias que un determinado DataWriter actualice. Acceso ordenado Cuando un tópico no tiene clave (y por tanto cuenta con una única instancia) las muestras de un DataWriter son almacenadas en la cola del DataReader en el orden que han sido enviadas. Sin embargo, cuando un tópico tiene clave un DataWriter puede crear, modificar o eliminar múltiples instancias. Cada uno de dichos eventos será enviado y almacenado en la cola del DataReader. Por defecto, las muestras que actualizan una determinada instancia son almacenadas en el orden que son enviadas por el DataWriter. Sin embargo, dado que las instancias de un tópico son almacenadas en una única cola en los DataReaders, es posible que sea necesario controlar que las muestras de diferentes instancias sean almacenadas en el mismo orden en que fueron enviadas por el DataWriter, lo cual no ocurre por defecto. Cuando se activa el acceso ordenado a las muestras, las actualizaciones de las diferentes instancias serán recibidas por el subscriptor en el mismo orden en que fueron enviadas por el DataWriter. Es importante indicar que esta política únicamente controla el orden de envío de muestras para un DataWriter, mientras que no tiene efecto para las muestras actualizadas por diferentes DataWriters. Si se desea que las muestras actualizadas por diferentes DataWriters lleguen en orden, será necesario hacer uso de la política DESTINATION_ORDER. Si se activa el acceso ordenado a los datos, access_scope controlará el efecto: Si access_scope es del tipo INSTANCE, el orden relativo de las muestras enviadas por los DataWriters es preservado únicamente por instancia. Si dos muestras de la misma instancia son enviadas por el DataWriter, estas llegarán a la cola del DataReader en el mismo orden del envío. 38

71 Capítulo 2. Políticas de QoS en DDS Si access_scope está configurado como TOPIC, el orden en que un DataWriter efectúa cambios sobre las instancias se conservará en los DataReaders. Por último, aclarar que el orden en el que la aplicación de usuario accede a los datos no tiene por qué ser el mismo que el orden existente en la cola del DataReader, dependiendo esto último del código de la aplicación. En la tabla 2.9 se muestra un ejemplo del efecto de la configuración de acceso ordenado: PRESENTATION QoS ordered_access = FALSE access_scope = <cualquiera> ordered_access = TRUE access_scope = INSTANCE Secuencia obtenida Orden de envío: {A1, B1, C1, A2, B2, C2} Orden de recepción: {A1, A2, B1, B2, C1, C2} {A1, A2, B1, B2, C1, C2} {A1, A2, B1, B2, C1, C2} ordered_access = TRUE access_scope = TOPIC {A1, B1, C1, A2, B2, C2} Tabla 2.9 Efecto de la configuración acceso ordenado sobre la QoS PRESENTATION Propiedades Esta política no puede ser modificada una vez se ha activado el publicador o el subscriptor. Esta política debe ser compatible entre el DataWriter y el DataReader. Las combinaciones admitidas se muestran en las tablas 2.10 y 2.11: Subscriptor {ordered_access / access_scope} False / Instance False / Topic True / Instance True / Topic False/Instance Compatible Incompatible Incompatible Incompatible Publicador False/Topic Compatible Compatible Incompatible Incompatible True/Instance Compatible Incompatible Compatible Incompatible True/Topic Compatible Compatible Compatible Compatible Tabla 2.10 Combinaciones Permitidas para el acceso ordenado 39

72 Plataforma de Trabajo Colaborativo sobre Middleware DDS {coherent_access / access_scope} False / Instance False / Topic Subscriptor True / Instance True / Topic False/Instance Compatible Incompatible Incompatible Incompatible Publicador False/Topic Compatible Compatible Incompatible Incompatible True/Instance Compatible Incompatible Compatible Incompatible True/Topic Compatible Compatible Compatible Compatible Tabla 2.11 Combinaciones Permitidas para el acceso coherente Utilidad para transmisión de audio y vídeo Cuando se trabaja con aplicaciones interactivas, es muy importante que los datos lleguen al receptor en el mismo orden en que fueron emitidos por el emisor. Por ello, esta política es fundamental para la implementación de un sistema de conferencia implementado sobre DDS. Concretamente, se optará por configurar la política PRESENTATION con acceso ordenado a las muestras por instancia Política TIME_BASED_FILTER Esta política permite especificar un tiempo mínimo entre la llegada de dos muestras consecutivas a un DataReader, pese a que existan DataWriters actualizando valores a una tasa mayor. Incluye un único dato miembro, tal y como se aprecia en la tabla Tipo de Dato Parámetro Descripción DDS_Duration_t minimum_separation Es la separación temporal mínima existente entre muestras de la misma instancia. Debe ser menor o igual que el periodo de DEADLINE. Tabla 2.12 Política OWNERSHIP_STRENGTH En la figura 2.1 se justifica por qué el parámetro minimum_separation debe ser menor o igual que el periodo de DEADLINE. 40

73 Capítulo 2. Políticas de QoS en DDS Figura 2.1 Relación entre minimum_separation y DEADLINE Las muestras son filtradas en el DataReader mediante la política TIME_BASED_FILTER. Una vez los datos son recibidos, RTI DDS aceptará pero desestimará cualquier muestra que llegue antes de que haya transcurrido el tiempo fijado por minimum_separation. Si no llega ninguna muestra antes de que transcurra el tiempo fijado por la política DEADLINE, se produce una llamada a los listeners correspondientes. Por tanto, si DEADLINE fuera menor que TIME_BASED_FILTER, continuamente se producirán violaciones de la política DEADLINE ya que no llegarán datos con la suficiente frecuencia (por ser desestimados). De hecho, y como se comentó en el apartado del presente capítulo, es recomendable que el tiempo de DEADLINE del DataReader sea mayor o igual que la suma del DEADLINE del DataWriter y el parámetro minimum_separation fijado en el DataReader. La política TIME_BASED_FILTER permite a los DataReaders obtener un subconjunto de las muestras que están siendo publicadas por los DataWriters. Si la aplicación de usuario no necesita las muestras recibidas durante ciertos periodos de tiempo, RTI DDS no tendrá por qué entregar datos en ese tiempo. Sin embargo, el hecho de que los datos sean enviados a través de la red por los DataWriters cuando no son necesarios dependerá de varios factores, incluyendo si la entrega es fiable y si los datos son enviados vía multicast a los diferentes DataReaders. Concretamente, para la configuración unicast con entrega best effort, si no existe clave para el tópico y el DataWriter tiene una lease_duration infinita, no se entregarán al DataReader más paquetes que los requeridos por la política TIME_BASED_FILTER. En el resto de configuraciones todos los paquetes serán entregados al DataReader, que los descartará. Propiedades Esta política puede ser cambiada en cualquier momento. Únicamente afecta a los DataReaders, por lo que no existe ningún tipo de restricción en cuanto a compatibilidad. Utilidad para transmisión de audio y vídeo Esta política puede ser útil para responder a situaciones de sobrecarga en los DataReaders. De este modo, se puede implementar un mecanismo adaptativo que reduzca la cantidad de muestras que un DataReader procesará por unidad de tiempo cuando tenga escasez de recursos. Además, en las condiciones adecuadas esta política puede producir una reducción de la ocupación de la red, al reducir el número de muestras que se transmiten. Concretamente, se puede aplicar a las diversas señales de vídeo del sistema de multiconferencia, permitiendo ajustar la tasa de imágenes por segundo entregada a la aplicación cuando se detecta 41

74 Plataforma de Trabajo Colaborativo sobre Middleware DDS congestión. Además, si se cumplen las condiciones adecuadas TIME_BASED_FILTER puede utilizarse para regular el número de paquetes enviados por segundo a los DataReaders. 2.3 Conclusiones En este capítulo se ha introducido el concepto de política de calidad de servicio. Se han explicado brevemente su funcionalidad, relatando sus características principales y proporcionando información sobre los parámetros afectados. Especial hincapié se ha hecho en identificar la utilidad de cada una de las políticas para el problema de la transmisión de audio y vídeo. Como se observará en capítulos siguientes la provisión del conjunto extenso de políticas hace que el desarrollo de la aplicación sea más ligero, toda vez que permite ajustar el comportamiento del sistema mediante la asignación de valores a los parámetros de dichas políticas de calidad de servicio. 42

75 Capítulo 3. Modelado de Requisitos Previo al diseño e implementación del sistema a desarrollar, para garantizar que se satisfacen todos los requerimientos, es necesario realizar un modelado de requisitos. Con este fin, en este capítulo se establecen los requerimientos del sistema. Diferenciamos dos tipos de requisitos: Funcionales: Describen la interacción entre el sistema y su entorno. Identifican los servicios proporcionados y caracterizan la reacción esperada del sistema ante determinados estímulos. No funcionales: Describen cualidades o restricciones del sistema que no se relacionan en forma directa con el comportamiento funcional del mismo. Para cumplir los factores dato indicados en el apartado del capítulo introductorio, el diseño del sistema adoptará una aproximación modular, con el fin de facilitar la extensibilidad y reusabilidad del mismo. Concretamente, se han concebido los siguientes subsistemas: client.main: Interfaz a través de la cual el usuario final puede acceder a los servicios de la plataforma. Además, es el punto de unión del resto de subsistemas diseñados, permitiendo la comunicación entre los distintos módulos definidos. client.audiopacket: Su finalidad es gestionar la captura y reproducción de audio. communicationdds.videoframe: Se encarga de intercambiar paquetes de vídeo con otros participantes. communicationdds.audiopacket: Este módulo permite el intercambio de paquetes de audio con otros participantes. communicationdds.signaling: Se encarga de la transmisión y recepción de mensajes de señalización. communicationdds.messenger: Subsistema para el intercambio de mensajes de texto entre los participantes. 43

76 Plataforma de Trabajo Colaborativo sobre Middleware DDS communicationipcamera: Subsistema mediante el que el sistema puede comunicarse con una cámara IP. A continuación se describirán los requerimientos para cada uno de los subsistemas desarrollados. 3.1 Requisitos funcionales client.main En esta sección se describirán los requisitos funcionales correspondientes al subsistema client.main, que constituye el nexo de unión los distintos módulos que forman la plataforma desarrollada. Definición de actores: Usuario: El rol de este actor será controlar el sistema, iniciándolo o cerrándolo mediante la interfaz de usuario del sistema. communicationdds.videoframe: Actor que entrega frames de vídeo al sistema o notificaciones cuando hay problemas/eventos en la recepción. Además, actúa como actor secundario al ser iniciado o finalizado por client. communicationdds.audiopacket: Actor a través del cual se reciben y envían paquetes de audio. Notificará al sistema de las incidencias que ocurran. communicationdds.signaling: A través de este módulo se intercambian mensajes de señalización. communicationdds.messenger: Este subsistema permite enviar y recibir mensajes de texto. DDS: Sistema que permite el descubrimiento de salas. JSPEEX: Módulo que se encarga de la codificación y decodificación del audio mediante el códec SPEEX. communicationipcamera: Actor a través del cual se establece la comunicación con la cámara. client.audiopacket: Subsistema que se encarga de la captura y reproducción de audio. Identificación de casos de uso por actores: Usuario Iniciar sistema: El sistema se inicia, quedando listo para recibir órdenes del usuario. Buscar salas: El usuario activa el modo buscar salas. El sistema mostrará una lista con las salas disponibles y el tipo de sala. 44

77 Capítulo 3. Modelado de Requisitos Configurar sala: El usuario selecciona si la sala será pública o privada y los usuarios permitidos en caso de ser de tipo privada. Crear sala: El usuario crea una sala con los parámetros configurados en configurar sala. Tras crear la sala, se aplica el caso de uso unirse a sala. Unirse a sala: El usuario se une a una sala, activándose la subscripción y publicación a los tópicos de señalización y mensajería. Publicar mensaje: El usuario escribe un mensaje de texto, para su publicación en la sala. Modificar publicaciones multimedia: El usuario inicia o detiene la publicación de audio y/o vídeo. Modificar subscripciones multimedia: El usuario inicia o detiene la subscripción a audio y/o vídeo. Cerrar sistema: El sistema finaliza los subsistemas activos y se cierra. communicationdds.videoframe Mostrar frame: Se muestra por la interfaz de usuario el nuevo frame de vídeo recibido. Mostrar cambio LIVELINESS video: Se muestra a través de la interfaz que se ha producido un cambio en los publicadores de vídeo activos. Notificar congestión vídeo: Cuando hay situación de congestión, se toman medidas para aliviarla. communicationdds.audiopacket Mostrar cambio LIVELINESS audio: Se muestra en la interfaz que ha habido un cambio en los publicadores de audio activos. communicationdds.signaling Mostrar solicitud de OWNERSHIP: Se indica a través de la interfaz una solicitud del canal de audio. Cambiar audio OWNER: Se muestra a través de la interfaz quién es el dueño del canal de audio actualmente y se notifica al módulo client.audiopacket. Mostrar cambio LIVELINESS señalización: Se notifica a través de la interfaz que un participante ha abandonado el dominio. communicationdds.messenger Mostrar nuevo mensaje: Se muestra un mensaje recibido a través de la subscripción al tópico de mensajería. Descripción de casos de uso: En las siguientes tablas se presenta la descripción de los casos de uso. 45

78 Plataforma de Trabajo Colaborativo sobre Middleware DDS Nombre Resumen Iniciar sistema El sistema se inicia, quedando listo para recibir órdenes del usuario Dependencias Actores Precondiciones Postcondiciones Curso Normal Usuario (primario) El sistema está apagado El sistema está iniciado y con la interfaz de descubrimiento/creación de salas activa. 1. El usuario inicia el sistema 2. Se inicia la interfaz de usuario de descubrimiento/creación de salas. Nombre Resumen Buscar salas El usuario activa el modo buscar salas. El sistema mostrará una lista con las salas disponibles y el tipo de sala. Dependencias Actores Precondiciones Postcondiciones Curso Normal Usuario (primario), DDS (secundario) El sistema está iniciado El sistema tiene la búsqueda de salas activa. 1. El usuario solicita la búsqueda de salas. 2. El sistema inicia la subscripción al builtin topic DCPSPublication, para recibir información de las publicaciones activas. 3. El sistema mantendrá el modo búsqueda de salas, mostrando mediante la interfaz las salas que se descubran. Nombre Resumen Dependencias Actores Configurar sala El usuario selecciona si la sala será pública o privada y los usuarios permitidos en caso de ser de tipo privada Es extendido por crear sala. Usuario (primario) 46

79 Capítulo 3. Modelado de Requisitos Precondiciones Postcondiciones Curso Normal El sistema está iniciado La configuración de la sala ha cambiado 1. El usuario introduce o elimina usuarios de la lista de admitidos en la sala. 2. El sistema comprueba que la información suministrada por el usuario está dentro de los rangos permitidos. 3. El sistema actualiza la configuración. Nombre Resumen Dependencias Actores Precondiciones Crear sala El usuario crea una sala con los parámetros de configuración almacenados. Tras crear la sala, se aplica el caso de uso unirse a sala. Incluye el caso de uso Unirse a sala. Usuario (primario) El sistema está iniciado Postcondiciones Curso Normal 1. El usuario solicita la creación de la sala. 2. Se lleva a cabo el caso de uso unirse a sala con los parámetros de configuración actuales. Nombre Resumen Dependencias Unirse a sala El usuario se une a una sala, activándose la subscripción y publicación a los tópicos de señalización y mensajería. Está incluido en Crear sala. Actores Usuario (primario), communicationdds.signaling (secundario), communicationdds.messenger (secundario) Precondiciones Postcondiciones Curso Normal El sistema está iniciado El sistema tiene la subscripción y publicación de señalización y mensajes activa. Además, se muestra la interfaz de usuario para la sala. 1. El usuario solicita unirse a una de las salas descubiertas o se ha realizado el caso de uso crear sala. 2. Se inician las publicaciones y subscripciones de los sistemas communicationdds.signaling y communicationdds.messenger. 47

80 Plataforma de Trabajo Colaborativo sobre Middleware DDS 3. Se muestra la interfaz de sala de conversación al usuario. Nombre Resumen Publicar mensaje El usuario escribe un mensaje de texto, para su publicación en la sala. Dependencias Actores Usuario (primario), communicationdds.messenger (secundario) Precondiciones Postcondiciones Curso Normal El sistema está iniciado y asociado a una sala. Se ha publicado un mensaje en la sala. 1. El usuario solicita escribe un mensaje y solicita su envío. 2. El sistema entrega el mensaje a communicationdds.messenger para su publicación. Nombre Resumen Dependencias Modificar publicaciones multimedia El usuario inicia o detiene la publicación de audio y/o vídeo. Está incluido en Cerrar Sistema. Actores Usuario (primario), communicationipcamera (secundario), client.audiopacket (secundario) Precondiciones Postcondiciones Curso Normal El sistema está iniciado y asociado a una sala. Se han cambiado las publicaciones activas. 1. El usuario solicita el inicio/finalización de la publicación de audio o vídeo. 2. Dependiendo de la publicación que se iniciará/finalizará, se inician/terminan los subsistemas correspondientes: a. Publicación de vídeo: communicationipcamera b. Publicación de audio: client.audiopacket Nombre Resumen Dependencias Modificar subscripciones multimedia El usuario inicia o detiene la subscripción a audio y/o vídeo Está incluido en Cerrar sistema. 48

81 Capítulo 3. Modelado de Requisitos Actores Usuario (primario), communicationdds.videoframe (secundario), communicationdds.audiopacket (secundario) Precondiciones Postcondiciones Curso Normal El sistema está iniciado y asociado a una sala. Se han cambiado las subscripciones activas. 1. El usuario solicita el inicio/finalización de la subscripción a audio o vídeo. 2. Dependiendo de la subscripción que se iniciará/finalizará, se inician/terminan los subsistemas correspondientes: a. Publicación de vídeo: communicationdds.videoframe b. Publicación de audio: communicationdds.audiopacket Nombre Resumen Cerrar sistema El sistema finaliza los subsistemas activos y se cierra. Dependencias Actores Usuario (primario), communicationdds.videoframe (secundario), communicationdds.audiopacket (secundario), communicationipcamera (secundario), communicationdds.signaling (secundario), communicationdds.messenger (secundario), JSPEEX (secundario) Precondiciones Postcondiciones Curso Normal El sistema está iniciado El sistema termina su ejecución 1. El usuario inicia el cierre del sistema 2. Se finaliza el subsistema JSPEEX. 3. Se eliminan las subscripciones existentes en los subsistemas communicationdds.messenger, communicationdds.signaling. 4. Se llevan a cabo los casos de uso Modificar subscripciones multimedia y Modificar publicaciones multimedia para terminar las publicaciones y subscripciones de audio y vídeo. 5. Se cierran las entidades de communicationipcamera. 6. Se finalizan las publicaciones de communicationdds.videoframe, communicationdds.audiopacket, 49

82 Plataforma de Trabajo Colaborativo sobre Middleware DDS communicationdds.messenger, communicationdds.signaling. 7. Se cierran las entidades de communicationipcamera. 8. Se cierra la interfaz de usuario Nombre Resumen Mostrar frame Se muestra por la interfaz de usuario el nuevo frame de vídeo recibido Dependencias Actores Precondiciones Postcondiciones Curso Normal communicationdds.videoframe (primario) El sistema está iniciado, en una sala de conversación y subscrito a vídeo. Se ha actualizado la interfaz de usuario. 1. communicationdds.videoframe entrega un frame de vídeo al sistema, asociado a un usuario. 2. El frame de vídeo es mostrado a través de la interfaz de usuario. Nombre Resumen Mostrar cambio LIVELINESS video Se muestra a través de la interfaz que se ha producido un cambio en los publicadores de vídeo activos Dependencias Actores Precondiciones Postcondiciones Curso Normal communicationdds.videoframe (primario) El sistema está iniciado, en una sala de conversación y subscrito a vídeo. Se ha actualizado la interfaz de usuario. 1. communicationdds.videoframe indica un cambio en el estado de un usuario. 2. El sistema actualiza la interfaz de usuario para hacer visible el cambio. Nombre Resumen Notificar congestión Vídeo Cuando hay situación de congestión, se toman medidas para aliviarla 50

83 Capítulo 3. Modelado de Requisitos Dependencias Actores communicationdds.videoframe (primario), communicationdds.signaling (secundario) Precondiciones El sistema está iniciado, en una sala de conversación y subscrito a vídeo. Postcondiciones Curso Normal 1. communicationdds.videoframe informa de que existe situación de congestión. 2. Dependiendo del tipo de difusión configurada en el sistema: a. Multicast: Si el sistema no está subscrito a la publicación de vídeo de menor calidad, el sistema procede a eliminar la subscripción existente para communicationdds.videoframe, y cambia a otra de menor calidad. b. Unicast: El sistema notifica al módulo de señalización que hay problemas con el audio, para que notifique a los otros miembros de la sala. Nombre Resumen Mostrar cambio LIVELINESS audio Se muestra en la interfaz que ha habido un cambio en los publicadores de audio activos. Dependencias Actores Precondiciones Postcondiciones Curso Normal communicationdds.audiopacket (primario) El sistema está iniciado, en una sala de conversación y subscrito a vídeo. Se ha actualizado la interfaz de usuario 1. communicationdds.audiopacket indica un cambio en el estado de un usuario. 2. El sistema actualiza la interfaz de usuario para hacer visible el cambio. Nombre Resumen Mostrar solicitud de OWNERSHIP Se indica a través de la interfaz una solicitud del canal de audio. 51

84 Plataforma de Trabajo Colaborativo sobre Middleware DDS Dependencias Actores Precondiciones Postcondiciones communicationdds.signaling (primario) El sistema está iniciado y asociado a una sala de conversación. Se ha actualizado la interfaz de usuario. Curso Normal 1. communicationdds.signaling informa de la solicitud del canal. 2. La solicitud es mostrada en la interfaz de usuario. Nombre Resumen Cambiar audio OWNER Se muestra a través de la interfaz quién es el dueño del canal de audio actualmente y se notifica al módulo de audio. Dependencias Actores communicationdds.signaling (primario), communicationdds.audiopacket (secundario) Precondiciones Postcondiciones Curso Normal El sistema está iniciado y asociado a una sala de conversación. La interfaz de usuario está actualizada y se ha enviado notificación de nuevo dueño del canal de audio al módulo communicationdds.audiopacket 1. communicationdds.signaling notifica el cambio en el dueño del canal de audio. 2. Si está activo, se notifica al módulo communicationdds.audiopacket. Nombre Resumen Mostrar cambio LIVELINESS señalización Se notifica a través de la interfaz que un participante ha abandonado el dominio. Dependencias Actores Precondiciones communicationdds.signaling (primario) El sistema está iniciado y asociado a una sala de conversación. Postcondiciones 52

85 Capítulo 3. Modelado de Requisitos Curso Normal 1. communicationdds.signaling informa de cambio en el estado de un participante. 2. Se actualiza la interfaz de usuario. Nombre Resumen Mostrar nuevo mensaje Se muestra un mensaje recibido a través de la subscripción al tópico de mensajería. Dependencias Actores Precondiciones communicationdds.messenger (primario) El sistema está iniciado y asociado a una sala. Postcondiciones Curso Normal 1. communicationdds.messenger entrega un mensaje. 2. Se actualiza la interfaz de usuario con el nuevo mensaje. Diagrama de Casos de Uso: En la figura 3.1 se muestra el diagrama de casos de uso para el subsistema client.main. 53

86 Plataforma de Trabajo Colaborativo sobre Middleware DDS ud client.main client.main Iniciar Sistema Buscar Salas Publicar Mensaje DDS Configurar Sala Mostrar Nuev o Mensaje Crear Sala «include» communicationdds. messenger Usuario Unirse a Sala Cerrar Sistema «include» «include» Mostrar Cambio LIVELINESS Señalización communicationipcamera Modificar Publicaciones Multimedia Modificar Subscripciones Multimedia Mostrar Solicitud OWNERSHIP communicationdds. signaling communicationdds. audiopacket Notificar Congestión Vídeo Cambiar Audio Owner Mostrar Frame Mostrar Cambio LIVELINESS Audio Mostrar Cambio Liveliness Video communicationdds. v ideoframe client.audiopacket Figura 3.1 Diagrama de casos de uso para el subsistema client.main 54

87 Capítulo 3. Modelado de Requisitos client.audiopacket El subsistema client.audiopacket permite el acceso al dispositivo de audio para la captura y reproducción de señal sonora. Conforme se obtengan paquetes de audio, este sistema los remitirá a communicationdds.audiopacket para su publicación. Asimismo, se encargará de reproducir los paquetes recibidos a través de communicationdds.audiopacket. Definición de actores: Dispositivo de audio: Actor primario que entrega paquetes de audio al subsistema. Es secundario cuando recibe paquetes para su reproducción. client.main: Actor que inicializará la captura y/o reproducción de audio. communicationdds.audiopacket: Actor a través del cual se reciben y envían paquetes de audio. JSPEEX: Módulo que se encarga de la codificación y decodificación del audio mediante el códec SPEEX. Identificación de casos de uso por actores: client.main Iniciar captura: Se asocia al sistema un publicador a través del que se enviarán paquetes de audio. Iniciar reproducción: Se asocia al sistema un subscriptor, del que se tomarán paquetes para su reproducción. Finalizar captura: Se finaliza la captura de audio. Finalizar reproducción: Finaliza la reproducción de paquetes de audio. Cambiar audio OWNERSHIP: Se ajusta el valor de la política OWNERSHIP_STRENGTH según se tenga el control del canal de audio o no. Dispositivo de audio Publicar paquete de audio: Se envía para su publicación un paquete de audio. communicationdds.audiopacket Reproducir paquete de audio: Se envía para su reproducción un paquete de audio a la tarjeta de sonido tras decodificarlo. Descripción de casos de uso: En las siguientes tablas se presenta la descripción de los casos de uso. Nombre Resumen Iniciar captura Se asocia al sistema un publicador a través del que se enviarán 55

88 Plataforma de Trabajo Colaborativo sobre Middleware DDS Dependencias paquetes de audio. Actores Precondiciones Postcondiciones Curso Normal client.main (primario), communicationdds.audiopacket (secundario) La publicación de audio no está activa. La publicación de audio está activa. 1. client.main inicia la captura de audio, asociando un communicationdds.audiopacket al sistema. Nombre Resumen Finalizar captura Se finaliza la captura de audio. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario) La publicación de audio está activa. La publicación de audio no está activa. 1. client.main finaliza la captura de audio. Nombre Resumen Iniciar reproducción Se asocia al sistema un subscriptor a través del que se enviarán paquetes de audio. Dependencias Actores client.main (primario), communicationdds.audiopacket (secundario) Precondiciones Postcondiciones Curso Normal La subscripción de audio no está activa. La subscripción de audio está activa. 1. client.main inicia la reproducción de audio, asociando un communicationdds.audiopacket al sistema. 56

89 Capítulo 3. Modelado de Requisitos Nombre Resumen Finalizar reproducción Finaliza la reproducción de paquetes de audio. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario) La subscripción de audio está activa. La subscripción de audio no está activa. 1. client.main finaliza la reproducción de paquetes de audio. Nombre Resumen Cambiar audio OWNERSHIP Se ajusta el valor de la política OWNERSHIP_STRENGTH según se tenga el control del canal de audio o no Dependencias Actores client.main (primario), communicationdds.audiopacket (secundario) Precondiciones Postcondiciones Curso Normal La publicación de audio está activa. El valor de OWNERSHIP_STRENGTH ha sido modificado 1. client.main indica que se posee o no el canal. a. Si se tiene el control del canal, se cambia el valor de OWNERSHIP_STRENGTH a 100 b. Si no se tiene el control del canal, se cambia el valor de OWNERSHIP_STRENGTH a 0 Nombre Resumen Publicar paquete de audio Se envía para su publicación un paquete de audio. Dependencias Actores Precondiciones Dispositivo de audio (primario), communicationdds.audiopacket (secundario) El sistema está iniciado y la publicación de audio activa. 57

90 Plataforma de Trabajo Colaborativo sobre Middleware DDS Postcondiciones Curso Normal 1. El dispositivo de audio entrega un paquete de audio al sistema 2. El paquete es entregado a communicationdds.audiopacket para su publicación. Nombre Resumen Reproducir paquete de audio Se envía para su reproducción un paquete de audio a la tarjeta de sonido. Dependencias Actores Precondiciones communicationdds.audiopacket (primario), dispositivo de audio (secundario) El sistema está iniciado y la subscripción de audio activa. Postcondiciones Curso Normal 1. communicationdds.audiopacket entrega un paquete de audio al sistema 2. El paquete de audio es decodificado y reproducido en el dispositivo de audio. Diagrama de Casos de Uso: En la figura 3.2 se muestra el diagrama de casos de uso para el subsistema client.audiopacket. 58

91 Capítulo 3. Modelado de Requisitos ud client.audiopacket client.audiopacket Iniciar captura client.main Finalizar captura Publicar paquete de audio Dispositivo de sonido Iniciar reproducción Reproducir paquete de audio Finalizar reproducción communicationdds. audiopacket Cambiar audio OWNERSHIP Figura 3.2 Diagrama de casos de uso para el subsistema client.audiopacket communicationdds.videoframe A continuación se estudiarán los requerimientos del subsistema communicationdds. videoframe, que será el encargado de gestionar la publicación y subscripción al tópico de vídeo. Definición de actores: client.main: Será el encargado de iniciar/detener la subscripción DDS. Además, podrá ser actor secundario cuando el sistema reciba frames de vídeo de las entidades remotas a través de DDS. communicationipcamera: Será el encargado de iniciar la publicación de datos. Interactuará con el sistema, enviando los frames de vídeo que han de ser enviados a través de DDS. Podrá ser actor secundario cuando el sistema determina que ha de cambiarse la compresión o la tasa de envío. DDS: Actor primario que entrega los paquetes de datos recibidos. A su vez es un actor secundario al que se envían los datos publicados. Temporizador: Actor primario que activa una hebra del sistema encargada de ajustar la calidad de la transmisión para ajustarse al estado de la red y la aplicación. 59

92 Plataforma de Trabajo Colaborativo sobre Middleware DDS Identificación de casos de uso por actores: client.main Iniciar subscripción: El cliente inicia la subscripción a vídeo sobre DDS en un tópico, momento a partir del cual podrán recibirse los frames de vídeo que sean publicados en dicho tópico. Eliminar subscripción: El cliente finaliza la subscripción, por lo que dejan de recibirse datos de vídeo. communicationipcamera DDS Iniciar publicación: El sistema communicationipcamera inicia la publicación a un tópico, momento a partir del cual se pueden enviar frames de vídeo por la red. Eliminar publicación: El sistema communicationipcamera finaliza la publicación existente. Publicar datos: El sistema communicationipcamera envía datos, que serán publicados sobre DDS. Recibir datos: DDS entrega datos al sistema, que son enviados al sistema client.main. Notificar expiración de DW DEADLINE: Cuando se produce una expiración en la política DEADLINE en el DataWriter, se activa un flag que indica el estado DEADLINE incumplido en el DataWriter. Notificar expiración de DR DEADLINE: Cuando se produce una expiración en la política DEADLINE en el DataReader, se activa un flag que indica el estado DEADLINE incumplido en el DataReader. Notificar cambio en LIVELINESS: Cuando se produce un cambio en los DataWriters, el sistema notifica a client.main para que actualice la lista de participantes de videoconferencia activos. Temporizador Ejecutar comprobación en DW: Según el valor de los flags de estado, ajusta la cantidad de información que se publica. Ejecutar comprobación en DR: Según el valor de los flags de estado, ajusta la cantidad de información que se recibe. Descripción de casos de uso: En las siguientes tablas se presenta la descripción de los casos de uso. 60

93 Capítulo 3. Modelado de Requisitos Nombre Resumen Iniciar subscripción El cliente inicia la subscripción a vídeo sobre DDS en un tópico, momento a partir del cual podrán recibirse los frames de vídeo que sean publicados en dicho tópico. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) No hay subscripción previa. El sistema queda subscrito al tópico indicado. 1. client.main solicita la subscripción a vídeo para el DomainParticipant actual, especificando una calidad de vídeo deseada. 2. El sistema crea el subscriptor. 3. El sistema comprueba si existe un tópico para la calidad de vídeo requerida en el DomainParticipant: a. Si no existe, se crea el tópico. b. Si existe, se utiliza el tópico existente. 4. El sistema inicializa las políticas QoS. 5. El sistema crea un DataReader asociado al tópico y su listener correspondiente. 6. El sistema inicia una hebra para la modificación dinámica de las políticas DEADLINE y TIME_BASED_FILTER. Nombre Resumen Eliminar subscripción El cliente finaliza la subscripción, por lo que dejan de recibirse datos de vídeo. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) El sistema está subscrito a un tópico. El sistema no está subscrito a ningún tópico. 1. client.main solicita la finalización de la subscripción. 2. El sistema finaliza la hebra encargada de la modificación dinámica de las políticas DEADLINE y TIME_BASED_FILTER. 3. El sistema finaliza el DataReader y su respectivo 61

94 Plataforma de Trabajo Colaborativo sobre Middleware DDS listener. 4. El sistema elimina el subscriptor del DomainParticipant. Nombre Resumen Iniciar publicación El sistema communicationipcamera inicia la publicación a un tópico, momento a partir del cual se pueden enviar frames de vídeo por la red. Dependencias Actores Precondiciones Postcondiciones Curso Normal communicationipcamera (primario ), DDS (secundario) El sistema no ha iniciado la publicación. El sistema queda asociado a un tópico en el que publicar datos. 1. communicationipcamera solicita iniciar la publicación sobre un tópico para el DomainParticipant actual. 2. El sistema crea el publicador 3. El sistema comprueba si existe un tópico para la calidad de vídeo requerida en el DomainParticipant: a. Si no existe, se crea el tópico. b. Si existe, se utiliza el tópico existente. 4. El sistema crea un DataWriter asociado a dicho tópico y su listener correspondiente. 5. El sistema inicia una hebra para la modificación dinámica del nivel de compresión y tasa de envío del stream de vídeo. Nombre Resumen Eliminar publicación El sistema communicationipcamera finaliza la publicación existente Dependencias Actores Precondiciones Postcondiciones Curso Normal communicationipcamera (primario), DDS (secundario) El sistema está asociado a un tópico para publicar datos El sistema no está vinculado a ningún tópico. 1. communicationipcamera solicita la terminación de la publicación. 62

95 Capítulo 3. Modelado de Requisitos 2. El sistema finaliza la hebra encargada de la modificación dinámica del nivel de compresión y tasa de envío del stream de vídeo. 3. El sistema finaliza el DataWriter y su respectivo listener. 4. El sistema elimina el publicador del DomainParticipant. Nombre Resumen Publicar datos El sistema communicationipcamera envía datos, que serán publicados sobre DDS. Dependencias Actores Precondiciones Postcondiciones Curso Normal communicationipcamera (primario), DDS (secundario) El sistema está asociado a un tópico para publicar datos Los datos han sido publicados sobre DDS. 1. communicationipcamera envía datos para publicar. 2. El sistema publica los datos a través de DDS. Nombre Resumen Recibir datos DDS entrega datos al sistema, que son enviados al sistema client.main. Dependencias Actores Precondiciones Postcondiciones Curso Normal DDS (primario), client.main (secundario) El sistema está subscrito a un tópico Los datos han sido entregados a client.main. 1. DDS entrega datos al sistema. 2. El sistema remite los datos a client.main. Nombre Resumen Notificar expiración de DW DEADLINE Cuando se produce una expiración en la política DEADLINE en el DataWriter, se activa un flag que indica el estado DEADLINE 63

96 Plataforma de Trabajo Colaborativo sobre Middleware DDS Dependencias incumplido en el DataWriter. Actores Precondiciones Postcondiciones Curso Normal DDS (primario) El sistema está asociado a un tópico para publicar datos El flag deadlineexpired asociado al DW queda activado. 1. DDS informa que la política DEADLINE ha sido incumplida para el DataWriter. 2. El sistema cambia el valor del flag deadlineexpired asociado al DataWriter a verdadero. Nombre Resumen Notificar expiración de DR DEADLINE Cuando se produce una expiración en la política DEADLINE en el DataReader, se activa un flag que indica el estado DEADLINE incumplido en el DataReader. Dependencias Actores Precondiciones Postcondiciones Curso Normal DDS (primario) El sistema está subscrito a un tópico El flag deadlineexpired asociado al DR queda activado. 1. DDS informa que la política DEADLINE ha sido incumplida para el DataReader. 2. El sistema cambia el valor del flag deadlineexpired asociado al DataReader a verdadero. Nombre Resumen Notificar cambio en LIVELINESS Cuando se produce un cambio en los DataWriters, el sistema notifica a client.main para que actualice la lista de participantes de videoconferencia activos. Dependencias Actores Precondiciones DDS (primario), client.main (secundario) El sistema está subscrito a un tópico 64

97 Capítulo 3. Modelado de Requisitos Postcondiciones Curso Normal 1. DDS informa que ha habido cambios en la política LIVELINESS. 2. El sistema comprueba el tipo de cambio: a. Si hay un nuevo DW, se notifica que hay un nuevo participante a client.main. b. Si uno de los DW deja de estar activo, se notifica a client.main de que dicho participante ha dejado de estar activo. Nombre Resumen Ejecutar comprobación en DW Según el valor de los flags de estado, ajusta la cantidad de información que se publica por unidad de tiempo. Dependencias Actores Temporizador (primario), communicationipcamera (secundario) Precondiciones El sistema está asociado a un tópico para publicar datos Postcondiciones Curso Normal 1. El temporizador activa la hebra de control de carga de sistema para el DW. 2. El hebra comprueba el estado del flag deadlineexpired: a. Si es verdadero, se notifica a communicationipcamera que es necesario reducir la cantidad de datos enviados por segundo para reducir la congestión de la aplicación. b. Si es falso, se notifica a communicationipcamera que no hay problemas y que se puede incrementar la cantidad de información enviada por segundo si es necesario. Nombre Resumen Ejecutar comprobación en DR Según el valor de los flags de estado, ajusta la cantidad de información que se recibe por unidad de tiempo. Dependencias Actores Temporizador (primario), client.main (secundario) 65

98 Plataforma de Trabajo Colaborativo sobre Middleware DDS Precondiciones El sistema está subscrito a un tópico Postcondiciones Curso Normal 1. El temporizador activa la hebra de control de carga de sistema para el DR. 2. La hebra comprueba el estado del flag deadlineexpired: a. Si es verdadero, se notifica a client.main que es necesario reducir la calidad del stream recibido (para aliviar una posible congestión de la red) y se incrementa el valor de las políticas DEADLINE y TIME_BASED_FILTER al doble (sin superar un valor máximo), con objeto de aliviar una posible congestión de la aplicación. b. Si es falso, se procede a reducir en un 20% el valor de las políticas DEADLINE y TIME_BASED_FILTER siempre y cuando no se reduzcan por debajo de un determinado valor mínimo. Si se llega a dicho valor mínimo, se notifica a client.main que se ha recuperado la normalidad. Diagrama de Casos de Uso: En la figura 3.3 se muestra el diagrama de casos de uso para el subsistema communicationdds.videoframe. 66

99 Capítulo 3. Modelado de Requisitos cd communicationdds.v ideoframe communicationdds.videoframe Notificar Expiración DW DEADLINE Notificar Expiración DR DEADLINE Iniciar Subscripción Eliminar Subscripción client.main Recibir Datos Ej ecutar Comprobación en DR Notificar Cambio en LIVELINESS Iniciar Publicación DDS Temporizador Ejecutar Comprobación en DW Eliminar Publicación Publicar Datos communicationipcamera Figura 3.3 Diagrama de casos de uso para el subsistema communicationdds.videoframe communicationdds.audiopacket En esta sección se discuten los requisitos para el subsistema communicationdds. audiopacket, cuyo fin es gestionar la publicación y subscripción al tópico de audio. Definición de actores: client.main: Será el encargado de iniciar/detener la publicación/subscripción DDS. client.audiopacket: Actor primario que publica paquetes de audio sobre DDS. Podrá ser actor secundario cuando el sistema reciba paquetes de audio de las entidades remotas a través de DDS. 67

100 Plataforma de Trabajo Colaborativo sobre Middleware DDS DDS: Actor primario que entrega los nuevos paquetes de audio recibidos. A su vez es un actor secundario al que se envían los datos publicados. Identificación de casos de uso por actores: client.main Iniciar subscripción: client.main inicia la subscripción a audio sobre DDS en un tópico, momento a partir del cual podrán recibirse los paquetes de audio que sean publicados en dicho tópico. Eliminar subscripción: client.main finaliza la subscripción, por lo que dejan de recibirse paquetes de audio. Iniciar publicación: El sistema client.main inicia la publicación a un tópico, momento a partir del cual los paquetes de audio pueden ser enviados. Eliminar publicación: El sistema client.main finaliza la publicación existente. client.audiopacket Publicar datos: El sistema client.audiopacket envía datos, que serán publicados sobre DDS. Cambiar OWNERSHIP: client.audiopacket cambia el valor de la política OWNERSHIP, que permite ganar/perder el control sobre el canal de audio compartido con el resto de clientes conectados al tópico. DDS Recibir datos: DDS entrega datos al sistema, que son enviados al sistema client.audiopacket. Notificar cambio en LIVELINESS: Cuando se produce un cambio en los DataWriters, el sistema notifica a client.main. Descripción de casos de uso: En las siguientes tablas se presenta la descripción de los casos de uso. Nombre Resumen Iniciar subscripción client.main inicia la subscripción a audio sobre DDS en un tópico, momento a partir del cual podrán recibirse los paquetes de audio que sean publicados en dicho tópico. Dependencias Actores Precondiciones client.audiopacket (primario), DDS (secundario) No hay subscripción previa. 68

101 Capítulo 3. Modelado de Requisitos Postcondiciones Curso Normal El sistema queda subscrito al tópico indicado. 1. client.main solicita la subscripción a audio para el DomainParticipant actual. 2. El sistema crea el subscriptor. 3. El sistema comprueba si existe un tópico de audio en el DomainParticipant: a. Si no existe, se crea el tópico. b. Si existe, se utiliza el tópico existente. 4. El sistema inicializa las políticas QoS. 5. El sistema crea un DataReader asociado a dicho tópico y su listener correspondiente. Nombre Resumen Eliminar subscripción client.main finaliza la subscripción, por lo que dejan de recibirse paquetes de audio. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) El sistema está subscrito a un tópico. El sistema no está subscrito a ningún tópico. 1. client.main solicita la finalización de la subscripción. 2. El sistema finaliza el DataReader y su respectivo listener. 3. El sistema elimina el subscriptor del DomainParticipant. Nombre Resumen Iniciar publicación El sistema client.main inicia la publicación a un tópico, momento a partir del cual los paquetes de audio pueden ser enviados. Dependencias Actores Precondiciones Postcondiciones client.main (primario), DDS (secundario) El sistema no ha iniciado la publicación. El sistema queda asociado a un tópico en el que publicar datos. 69

102 Plataforma de Trabajo Colaborativo sobre Middleware DDS Curso Normal 1. client.main solicita iniciar la publicación sobre un tópico para el DomainParticipant actual. 2. El sistema crea el publicador. 3. El sistema comprueba si existe un tópico de audio en el DomainParticipant: a. Si no existe, se crea el tópico. b. Si existe, se utiliza el tópico existente. 4. El sistema crea un DataWriter asociado a dicho tópico y su listener correspondiente. Nombre Resumen Eliminar publicación El sistema client.main finaliza la publicación existente Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) El sistema está asociado a un tópico para publicar datos El sistema no está vinculado a ningún tópico. 1. client.main solicita la terminación de la publicación. 2. El sistema finaliza el DataWriter y su respectivo listener. 3. El sistema elimina el publicador del DomainParticipant. Nombre Resumen Publicar datos El sistema client.audiopacket envía datos, que serán publicados sobre DDS. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.audiopacket (primario), DDS (secundario) El sistema está asociado a un tópico para publicar datos Los datos han sido publicados sobre DDS. 1. client.audiopacket envía datos para publicar. 2. El sistema publica los datos a través de DDS. 70

103 Capítulo 3. Modelado de Requisitos Nombre Cambiar OWNERSHIP Resumen client.audiopacket cambia el valor de la política OWNERSHIP, que permite ganar/perder el control sobre el canal de audio compartido con el resto de clientes conectados al tópico. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.audiopacket (primario), DDS (secundario) El sistema está asociado a un tópico para publicar datos El valor de la política OWNERSHIP ha cambiado 1. client.audiopacket cambia el valor de la política OWNERSHIP Nombre Resumen Recibir datos DDS entrega datos al sistema, que son enviados al sistema client.audiopacket. Dependencias Actores Precondiciones Postcondiciones Curso Normal DDS (primario), client.audiopacket (secundario) El sistema está subscrito a un tópico Los datos han sido entregados a client.audiopacket. 1. DDS entrega datos al sistema. 2. El sistema remite los datos a client.audiopacket. Nombre Resumen Notificar cambio en LIVELINESS Cuando se produce un cambio en los DataWriters, el sistema notifica a client.main Dependencias Actores Precondiciones DDS (primario), client.main (secundario) El sistema está subscrito a un tópico Postcondiciones 71

104 Plataforma de Trabajo Colaborativo sobre Middleware DDS Curso Normal 1. DDS informa que ha habido cambios en la política LIVELINESS. 2. El sistema comprueba el tipo de cambio: a. Si hay un nuevo DW, se notifica que hay un nuevo participante a client.main. b. Si uno de los DW deja de estar activo, se notifica a client.audiopacket de que dicho participante ha dejado de estar activo. Diagrama de Casos de Uso: En la figura 3.4 se muestra el diagrama de casos de uso para el subsistema communicationdds.audiopacket. ud communicationdds.audiopacket communicationdds.audiopacket Iniciar Subscripción Notificar Expiración DR DEADLINE Eliminar Subscripción Iniciar Publicación client.main Eliminar Publicación Notificar Cambio en LIVELINESS DDS Publicar Datos Recibir Datos client.audiopacket Cambiar OWNERSHIP Notificar Expiración DW DEADLINE Figura 3.4 Diagrama de casos de uso para el subsistema communicationdds.audiopacket 72

105 Capítulo 3. Modelado de Requisitos communicationdds.signaling El subsistema communicationdds.signaling será el encargado de intercambiar mensajes de señalización con el resto de sistemas remotos. En esta sección se identifican los casos de uso correspondientes a este subsistema. Definición de actores: client.main: Será el encargado de iniciar/detener la publicación/subscripción DDS y publicar mensajes de señalización. DDS: Actor primario que entrega los nuevos paquetes de señalización recibidos. A su vez es un actor secundario al que se envían los mensajes de señalización. Identificación de casos de uso por actores: client.main Iniciar subscripción: client.main inicia la subscripción al tópico de señalización. Una vez iniciada la subscripción, se podrán recibir mensajes de señalización. Eliminar subscripción: client.main finaliza la subscripción, por lo que dejan de recibirse paquetes de señalización. Iniciar publicación: El sistema client.main inicia la publicación a un tópico, momento a partir del cual los paquetes de señalización pueden ser enviados. Eliminar publicación: El sistema client.main finaliza la publicación existente. Publicar Información de señalización: client.main entrega información de señalización al sistema para su envío a través de DDS. DDS Recibir datos: DDS entrega datos al sistema. La información es entregada a client.main. Notificar cambio en LIVELINESS: Cuando se produce un cambio en los DataWriters, el sistema notifica a client.main. Descripción de casos de uso: En las siguientes tablas se presenta la descripción de los casos de uso. Nombre Resumen Iniciar subscripción client.main inicia la subscripción al tópico de señalización. Una vez iniciada la subscripción, se podrán recibir mensajes de señalización Dependencias Actores client.main (primario), DDS (secundario) 73

106 Plataforma de Trabajo Colaborativo sobre Middleware DDS Precondiciones Postcondiciones Curso Normal No hay subscripción previa. El sistema queda subscrito al tópico indicado. 1. client.main solicita la subscripción al tópico de señalización para el DomainParticipant actual. 2. El sistema crea el subscriptor. 3. El sistema comprueba si existe un tópico de señalización en el DomainParticipant: a. Si no existe, se crea el tópico. b. Si existe, se utiliza el tópico existente. 4. El sistema inicializa las políticas QoS. 5. El sistema crea un DataReader asociado a dicho tópico y su listener correspondiente. Nombre Resumen Eliminar subscripción client.main finaliza la subscripción, por lo que dejan de recibirse paquetes de señalización. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) El sistema está subscrito a un tópico. El sistema no está subscrito a ningún tópico. 1. client.main solicita la finalización de la subscripción. 2. El sistema finaliza el DataReader y su respectivo listener. 3. El sistema elimina el subscriptor del DomainParticipant. Nombre Resumen Iniciar publicación El sistema client.main inicia la publicación a un tópico, momento a partir del cual los paquetes de señalización pueden ser enviados. Dependencias Actores client.main (primario), DDS (secundario) 74

107 Capítulo 3. Modelado de Requisitos Precondiciones Postcondiciones Curso Normal El sistema no ha iniciado la publicación. El sistema queda asociado a un tópico en el que publicar datos. 1. client.main solicita iniciar la publicación sobre un tópico para el DomainParticipant actual. 2. El sistema crea el publicador. 3. El sistema comprueba si existe un tópico de señalización en el DomainParticipant: c. Si no existe, se crea el tópico. d. Si existe, se utiliza el tópico existente. 4. El sistema crea un DataWriter asociado a dicho tópico y su listener correspondiente. Nombre Resumen Eliminar publicación El sistema client.main finaliza la publicación existente. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) El sistema está asociado a un tópico para publicar datos El sistema no está vinculado a ningún tópico. 1. client.main solicita la terminación de la publicación. 2. El sistema finaliza el DataWriter y su respectivo listener. 3. El sistema elimina el publicador del DomainParticipant. Nombre Resumen Publicar Información de Señalización client.main entrega información de señalización al sistema para su envío a través de DDS. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) El sistema está asociado a un tópico para publicar datos Los datos han sido publicados sobre DDS. 1. client.main entrega información de señalización para su 75

108 Plataforma de Trabajo Colaborativo sobre Middleware DDS envío. 2. El sistema publica los datos a través de DDS. Nombre Resumen Recibir datos DDS entrega datos al sistema. La información es entregada a client.main Dependencias Actores Precondiciones Postcondiciones Curso Normal DDS (primario), client.main (secundario) El sistema está subscrito a un tópico Los datos han sido entregados a client.main 1. DDS entrega datos al sistema. 2. La información de señalización es entregada a client.main Nombre Resumen Notificar cambio en LIVELINESS Cuando se produce un cambio en los DataWriters, el sistema notifica a client.main. Dependencias Actores Precondiciones DDS (primario), client.main (secundario) El sistema está subscrito a un tópico Postcondiciones Curso Normal 1. DDS informa que ha habido cambios en la política LIVELINESS. 2. El sistema comprueba el tipo de cambio: a. Si hay un nuevo DW, se notifica que hay un nuevo participante a client.main. b. Si uno de los DW deja de estar activo, se notifica a client.main de que dicho participante ha dejado de estar activo. Diagrama de Casos de Uso: En la figura 3.5 se muestra el diagrama de casos de uso para el subsistema communicationdds.signaling. 76

109 Capítulo 3. Modelado de Requisitos ud communicationdds.signaling communicationdds.signaling Iniciar Publicación Iniciar Subscripción Eliminar Publicación Eliminar Subscripción client.main DDS Publicar Información de Señalización Recibir Datos Notificar Cambio en LIVELINESS Figura 3.5 Diagrama de casos de uso para el subsistema communicationdds.signaling communicationdds.messenger En esta sección se describen los requerimientos correspondientes al subsistema communicationdds.messenger, destinado a intercambiar mensajes de texto con otros sistemas remotos. Definición de actores: client.main: Será el encargado de iniciar/detener la publicación/subscripción DDS y publicar mensajes de texto. 77

110 Plataforma de Trabajo Colaborativo sobre Middleware DDS DDS: Actor primario que entrega los nuevos paquetes de señalización recibidos. A su vez es un actor secundario al que se envían los mensajes. Identificación de casos de uso por actores: client.main DDS Iniciar subscripción: client.main inicia la subscripción al tópico de mensajería. Una vez iniciada la subscripción, se podrán recibir mensajes. Eliminar subscripción: client.main finaliza la subscripción, por lo que dejan de recibirse mensajes. Iniciar publicación: El sistema client.main inicia la publicación a un tópico, momento a partir del cual los se pueden enviar mensajes. Eliminar publicación: El sistema client.main finaliza la publicación existente. Publicar mensaje: El sistema client.main entrega un mensaje para su publicación en el tópico de mensajería. Recibir mensaje: DDS entrega un mensaje al sistema. Notificar cambio en LIVELINESS: Cuando se produce un cambio en los DataWriters, el sistema notifica a client.main. Descripción de casos de uso: En las siguientes tablas se presenta la descripción de los casos de uso. Nombre Resumen Iniciar subscripción client.main inicia la subscripción al tópico de mensajería. Una vez iniciada la subscripción, se podrán recibir mensajes. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) No hay subscripción previa. El sistema queda subscrito al tópico indicado. 1. client.main solicita la subscripción al tópico de mensajería para el DomainParticipant actual. 2. El sistema crea el subscriptor. 3. El sistema comprueba si existe un tópico de mensajería en el DomainParticipant: a. Si no existe, se crea el tópico. 78

111 Capítulo 3. Modelado de Requisitos b. Si existe, se utiliza el tópico existente. 4. El sistema inicializa las políticas QoS. 5. El sistema crea un DataReader asociado a dicho tópico y su listener correspondiente. Nombre Resumen Eliminar subscripción client.main finaliza la subscripción, por lo que dejan de recibirse mensajes. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) El sistema está subscrito a un tópico. El sistema no está subscrito a ningún tópico. 1. client.main solicita la finalización de la subscripción. 2. El sistema finaliza el DataReader y su respectivo listener. 3. El sistema elimina el subscriptor del DomainParticipant. Nombre Resumen Iniciar publicación El sistema client.main inicia la publicación a un tópico, momento a partir del cual los se pueden enviar mensajes Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario, DDS (secundario) El sistema no ha iniciado la publicación. El sistema queda asociado a un tópico en el que publicar datos. 1. client.main solicita iniciar la publicación sobre un tópico para el DomainParticipant actual. 2. El sistema crea el publicador. 3. El sistema comprueba si existe un tópico de señalización en el DomainParticipant: a. Si no existe, se crea el tópico. b. Si existe, se utiliza el tópico existente. 4. El sistema crea un DataWriter asociado a dicho tópico y 79

112 Plataforma de Trabajo Colaborativo sobre Middleware DDS su listener correspondiente. Nombre Resumen Eliminar publicación El sistema client.main finaliza la publicación existente Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) El sistema está asociado a un tópico para publicar datos El sistema no está vinculado a ningún tópico. 1. client.main solicita la terminación de la publicación. 2. El sistema finaliza el DataWriter y su respectivo listener. 3. El sistema elimina el publicador del DomainParticipant. Nombre Resumen Publicar mensaje El sistema client.main entrega un mensaje para su publicación en el tópico de mensajería. Dependencias Actores Precondiciones Postcondiciones Curso Normal client.main (primario), DDS (secundario) El sistema está asociado a un tópico para publicar mensajes El mensaje ha sido publicado en DDS. 1. client.main solicita la publicación de un mensaje. 2. El sistema publica el mensaje a través de DDS. Nombre Resumen Recibir mensaje DDS entrega un mensaje al sistema Dependencias Actores Precondiciones DDS (primario), client.main (secundario) El sistema está subscrito a un tópico 80

113 Capítulo 3. Modelado de Requisitos Postcondiciones Curso Normal Los datos han sido entregados al subsistema adecuado 1. DDS entrega un mensaje al sistema. 2. El sistema entrega el mensaje al sistema client.main Nombre Resumen Notificar cambio en LIVELINESS Cuando se produce un cambio en los DataWriters, el sistema notifica a client.main. Dependencias Actores Precondiciones DDS (primario), client.main (secundario) El sistema está subscrito a un tópico Postcondiciones Curso Normal 1. DDS informa que ha habido cambios en la política LIVELINESS. 2. El sistema comprueba el tipo de cambio: a. Si hay un nuevo DW, se notifica que hay un nuevo participante a client.main. b. Si uno de los DW deja de estar activo, se notifica a client.main de que dicho participante ha dejado de estar activo. Diagrama de Casos de Uso: En la figura 3.6 se muestra el diagrama de casos de uso para el subsistema CommunicationDDS.messenger. 81

114 Plataforma de Trabajo Colaborativo sobre Middleware DDS ud communicationdds.messenger communicationdds.messenger Iniciar Publicación Eliminar Publicación Iniciar Subscripción client.main Eliminar Subscripción DDS Publicar Mensaje Recibir Mensaje Notificar Cambio en LIVELINESS Figura 3.6 Diagrama de casos de uso para el subsistema communicationdds.messenger communicationipcamera El subsistema communicationipcamera actúa como puente entre DDS y HTTP, permitiendo obtener una señal de vídeo desde una cámara IP para su publicación sobre middleware DDS. En esta sección se estudian los requisitos correspondientes a este subsistema. Definición de actores: client.main: Será el encargado de iniciar/detener la comunicación con la cámara. Además, fijará los valores de configuración del sistema. communicationdds.videoframe: Actor que notificará al sistema cuando haya problemas en el envío de datos sobre DDS. Por otro lado, actuará como actor secundario a través del que se publicarán datos en DDS. 82

115 Capítulo 3. Modelado de Requisitos Cámara IP: Actor que envía frames de vídeo al sistema. Será actor secundario en la inicialización y cuando se modifiquen sus parámetros. Identificación de casos de uso por actores: client.main Conectar sistema: Inicia la conexión del sistema a la cámara y el inicio de la publicación. Desconectar sistema: Finaliza la conexión del sistema a la cámara, tras lo que finaliza la publicación de datos. Cargar configuración: Carga una configuración predeterminada para conectar a la cámara IP de un archivo XML Cambiar calidad: Solicita un cambio en la calidad del vídeo transmitido para ajustar la cantidad de información enviada a las condiciones del sistema. communicationdds.videoframe Cambiar calidad: Solicita un cambio en la calidad del vídeo transmitido para ajustar la cantidad de información enviada a las condiciones del sistema. Cámara IP Publicar frame: Envía un frame que ha de ser publicado en DDS Descripción de casos de uso: En las siguientes tablas se presenta la descripción de los casos de uso. Nombre Resumen Dependencias Actores Precondiciones Postcondiciones Curso Normal Conectar sistema Inicia la conexión del sistema a la cámara y el inicio de la publicación. Incluye el caso de uso Cargar configuración. Está incluido en Cambiar calidad. client.main (primario), Cámara IP (secundario) El sistema está desconectado El sistema está conectado 1. client.main solicita la conexión a la cámara IP con una calidad determinada. 2. Se inicia el caso de uso Cargar configuración: a. Si no hay problemas se intenta establecer conexión HTTP con la cámara. i. Si consigue conectar, se inicia la publicación en communicationdds.videoframe. ii. Si no consigue conectar, se devuelve un 83

116 Plataforma de Trabajo Colaborativo sobre Middleware DDS mensaje de error y se vuelve al punto 2. b. Si no se puede cargar la configuración se cancela el caso de uso y se devuelve señal de error. Nombre Resumen Dependencias Actores Precondiciones Postcondiciones Curso Normal Desconectar sistema Finaliza la conexión del sistema a la cámara, tras lo que finaliza la publicación de datos. Está incluido en Cambiar calidad. client.main (primario), Cámara IP (secundario) El sistema está conectado El sistema está desconectado 1. client.main solicita la desconexión de la cámara IP 2. Se finaliza la publicación en communicationdds.videoframe. 3. Se cierra la conexión HTTP con la cámara. Nombre Resumen Dependencias Cargar configuración Carga una configuración predeterminada para conectar a la cámara IP de un archivo XML Es un caso de uso abstracto incluido por Conectar sistema Actores Precondiciones Postcondiciones Curso Normal Curso Alternativo 1. El sistema carga la configuración de la cámara desde un archivo XML. 1. Si no se puede acceder al archivo o el formato es incorrecto se cancela el caso de uso y se devuelve una señal de error. Nombre Resumen Cambiar calidad Solicita un cambio en la calidad del vídeo transmitido para ajustar la cantidad de información enviada a las condiciones del sistema. 84

117 Capítulo 3. Modelado de Requisitos Dependencias Actores Precondiciones Incluye los casos de uso Desconectar sistema y Conectar sistema. client.main(primario), communicationdds.videoframe (primario) El sistema está conectado Postcondiciones Curso Normal 1. client.main o communicationdds.videoframe solicita un cambio en el nivel de compresión de la cámara. 2. Se ejecuta el caso de uso Desconectar sistema 3. Se cambian los valores de compresión por defecto a los nuevos valores solicitados. 4. Se ejecuta el caso de uso Conectar sistema. Nombre Resumen Publicar frame Envía un frame que ha de ser publicado en DDS. Dependencias Actores Cámara IP (primario), communicationdds.videoframe (secundario) Precondiciones El sistema está conectado Postcondiciones Los datos han sido entregados a communicationdds.videoframe Curso Normal 1. La cámara IP entrega un frame al sistema 2. El sistema envía el frame a communicationdds.videoframe Diagrama de Casos de Uso: En la figura 3.7 se muestra el diagrama de casos de uso para el subsistema CommunicationDDS.CommunicationIPCamera. 85

118 Plataforma de Trabajo Colaborativo sobre Middleware DDS ud communicationipcamera communicationipcamera Desconectar Sistema «include» Cambiar Calidad Cámara IP client.main «include» Publicar Frame Conectar Sistema «include» Cargar Configuración DDSCommunication. v ideoframe Figura 3.7 Diagrama de casos de uso para el subsistema communicationdds.communicationipcamera 3.2 Requisitos No Funcionales Comunes a todos los subsistemas Implementación El sistema será implementado utilizando Java. Se hará uso de la librería nddsjava.jar, la versión comercial de middleware DDS implementada por RTI. Concretamente, se usará la versión estable NDDS 4.2e. Interfaz El sistema está preparado para comunicarse con sistemas modulares externos independientes. Facilidad de Uso Al usuario final del sistema se le proporcionará la documentación sobre las distintas clases implicadas en formato Javadoc. El sistema será controlado a través de una interfaz de ventanas. Fiabilidad Las señales de error se gestionarán a través del capturador de excepciones de Java. Las publicaciones y subscripciones multimedia pueden ser iniciadas y detenidas en cualquier momento. 86

119 Capítulo 3. Modelado de Requisitos Los problemas derivados de la comunicación entre los participantes serán gestionados por el middleware DDS. Operaciones El sistema requiere la intervención del usuario para entrar en una sala, iniciar o finalizar publicaciones multimedia o el envío de mensajes de texto. Una vez se accede a una sala, el sistema es autosuficiente. Rendimiento El intercambio de información entre los participantes deberá realizarse con el menor retardo posible. Soporte Se utilizará UML en el proceso de desarrollo del software. El sistema debe permitir la inclusión de nuevos elementos modulares. Empaquetamiento El sistema, al estar programado en Java no requerirá instalación. Requerirá contar con una máquina virtual Java 5 o superior y la versión de NDDS 4.2e apropiada para la arquitectura utilizada Específicos de client.audiopacket Implementación Para la captura y reproducción de audio se utilizará Javasound. Se soportará el códec SPEEX mediante la librería JSPEEX. Se soportará la fácil ampliación del número de códec soportados mediante el uso de Interfaces de Java Específicos de communicationipcamera Implementación Como fuente de streaming de vídeo, se utilizará una cámara IP. Concretamente, se utilizará el modelo AXIS 207W. Para el acceso a la cámara, se utilizará la API VAPIX [56]. Interfaz La configuración de la cámara IP será cargada desde archivos en formato XML. Los archivos de configuración permitirán el futuro soporte de otros modelos de cámara. El acceso a la cámara se efectuará mediante conexiones HTTP. Fiabilidad Si no se puede establecer la comunicación con la cámara IP se continuará intentando establecerla mientras la publicación de vídeo siga activa. 87

120 Plataforma de Trabajo Colaborativo sobre Middleware DDS Si se pierde la conexión con la cámara, se intentará recuperar conexión mientras que la publicación de vídeo siga activa. Operaciones El subsistema requiere la intervención del usuario para su inicio, siendo autosuficiente desde ese momento. 3.3 Conclusiones En este capítulo se ha desarrollado el modelado de requisitos del sistema. En primer lugar, se presentaron los módulos en los que se ha dividido la plataforma, indicando brevemente la función de cada uno. Posteriormente, se especificaron los requisitos funcionales de cada subsistema mediante la descripción de casos de uso. Finalmente se han definido los requerimientos no funcionales del sistema. Partiendo de los requisitos descritos, en el próximo capítulo se llevará a cabo el diseño del sistema, fase previa a la implementación del mismo. 88

121 Capítulo 4. Diseño Una vez fijados los requisitos del sistema, en este capítulo se presenta el diseño de la plataforma. Con este fin, se proporcionan el diagrama de paquetes, el de clases y el de flujo. Igualmente se definen las políticas de calidad de servicio incorporadas. 4.1 Diagrama de paquetes En esta primera sección del capítulo se presenta la arquitectura del sistema. Para ello, se incluye el diagrama de paquetes (ver figura 4.1) correspondientes a los subsistemas que componen la plataforma. 89

122 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.1 Diagrama de paquetes En el siguiente apartado se indicarán las políticas de calidad de servicio que han sido incorporadas a la plataforma. 4.2 Políticas de calidad de servicio incorporadas al sistema En esta sección de la memoria se detalla qué políticas de calidad de servicio han sido incorporadas al sistema y cómo han sido utilizadas Políticas DEADLINE y TIME_BASED_FILTER Las políticas DEADLINE y TIME_BASED_FILTER (discutidas en los apartados y de la memoria) han sido aplicadas con el fin de dotar al sistema de un mecanismo para adaptarse a las condiciones de congestión de la red o del propio sistema. De este modo, si se producen problemas en el receptor en la recepción de vídeo, en el sistema propuesto se ha optado por modificar la cantidad de tráfico existente en la red, cambiando el nivel de compresión y tasa de frames del flujo MJPG transmitido a dicho receptor. Además, aplicando la 90

123 Capítulo 4. Diseño política TIME_BASED_FILTER se reduce la carga de la aplicación destino (decrementando el número de paquetes que RTI DDS entrega a la misma). Estas dos estrategias atenúan las posibles causas de la expiración de la política DEADLINE, permitiendo al sistema reducir la situación de congestión. Una vez que se recupere la normalidad (no haya expiración de DEADLINES) se producirá una recuperación progresiva de los niveles de compresión y tasa de frames por segundo iniciales. Para ello, se comprobará periódicamente (cada cinco segundos) si ha expirado DEADLINE y de no ser así se mejorará la calidad de la señal transmitida (esto se consigue mediante la configuración de distintos niveles de calidad en el sistema communicationipcamera). Para reducir la cantidad de datos enviados hacia el receptor con problemas, se han ideado dos estrategias posibles: La primera consiste implementar dos tópicos de vídeo con diferentes calidades. Las ventajas de esta aproximación eran que el propio subscriptor con problemas podía cambiar su subscripción, sin necesidad de implementar ningún tipo de señalización hacia el publicador. Sin embargo, existe el inconveniente de que es necesario mantener dos conexiones a la cámara IP y dos publicaciones de vídeo, lo que implica utilizar un mayor número de recursos. La segunda estrategia consiste en establecer un canal para la señalización, que permita informar de las situaciones problemáticas con objeto de tomar medidas correctivas. Finalmente se adoptó esta solución, ya que la existencia de un canal de señalización permitiría la implementación posterior de nuevos servicios (como se verá en el siguiente apartado de la memoria). Cuando los problemas se dan en el emisor (por un exceso de carga de la aplicación que impide enviar los paquetes a tiempo), se aumentará la compresión y reducirá el número de frames por segundo para todos los flujos enviados, con objeto de recuperar la normalidad. Del mismo modo que en el caso anterior, cuando se supere la situación de congestión el sistema restablecerá la calidad del vídeo emitido Política LIVELINESS Esta política será implementada para todos los subsistemas implementados. De este modo, la aplicación contará con información actualizada de qué recursos se encuentran disponibles en cada momento. Además, dado que al acceder a una sala el sistema iniciará de forma automática la publicación y subscripción al tópico de señalización (ver apartado de la memoria), los cambios en la política LIVELINESS permitirán al usuario conocer qué usuarios han accedido/salido a la sala en la que éste se encuentra Política PRESENTATION Esta política asegura que las muestras publicadas en un tópico son entregadas al subscriptor en el mismo orden en que se enviaron. Aunque en un primer análisis se consideró que podría ser útil para la aplicación (al asegurar entrega ordenada), esta política garantiza el orden de entrega entre diferentes datawriters. En nuestro caso, la prioridad es que los paquetes de un mismo datawriter se entreguen en orden, lo que se corresponde al comportamiento por defecto de DDS, no siendo necesario el uso de esta política. 91

124 Plataforma de Trabajo Colaborativo sobre Middleware DDS Política LIFESPAN Como se indicó en la sección de la memoria, esta política asegura que los paquetes con un retardo excesivo no se entreguen a la aplicación, al carecer de validez. Esta política será implementada tanto para audio como para vídeo, fijando un retardo máximo de entrega de 750 ms Política OWNERSHIP y OWNERSHIP_STRENGTH El sistema ha sido concebido para que cuente con un canal de audio moderado, en el que únicamente el usuario designado por el moderador pueda hacer uso del mismo. Para conseguir esta funcionalidad, se prevé el uso de las políticas OWNERSHIP y OWNERSHIP_STRENGTH descritas en las secciones y de la presente memoria, que asegurarán que únicamente el usuario con un valor de OWNERSHIP_STRENGTH más alto entregue sus paquetes al resto de usuarios. Para la designación de los valores de OWNERSHIP_STRENGTH, el sistema se basará en los mensajes de señalización recibidos por el moderador de la sala (por defecto, será el creador de la misma). De este modo, cuando el moderador conceda la palabra el sistema cambiará OWNERSHIP_STRENGTH a un valor alto (concretamente, 100) y cuando el moderador conceda la palabra a otro usuario el sistema reducirá el valor de la política a Diagramas de clases A continuación de muestran las clases correspondientes a cada uno de los paquetes presentados en la sección anterior. Asimismo, se indican las relaciones existentes entre las distintas clases propuestas Paquete client.main El paquete client.main constituye la parte central del sistema implementado. Sirve de nexo de unión entre el resto de paquetes diseñados y es el encargado de presentar al usuario una interfaz gráfica amigable. Está constituido por dos clases (ver figura 4.2), descritas a continuación: ClientMain. Es el punto de inicio de la aplicación, permite al usuario introducir sus datos, configurar/crear una sala de conferencia o buscar las salas existentes para unirse a alguna. ClientRoom: A través de esta clase, el usuario podrá interactuar con otros usuarios presentes en una determinada sala. Permite intercambiar mensajes de texto, así como datos de audio y vídeo. 92

125 Capítulo 4. Diseño Figura 4.2 Paquete client.main Paquete client.audiopacket El paquete client.audiopacket es el encargado de acceder al dispositivo de audio del sistema, tanto para la captura como para la reproducción de las muestras. Con la intención de que sea extensible, se han diseñado dos interfaces (AudioPlayer y MicrophClient). Estas dos interfaces permiten ampliar con facilidad el conjunto de codecs utilizables en el sistema. En la figura 4.3 se muestran las interfaces desarrolladas, así como las posibles implementaciones de las mismas para utilizar los codecs de µlaw [57] y SPEEX [20]. AudioPlayer. Interfaz con los métodos necesarios para decodificar el stream de audio recibido desde DDS y reproducirlo en el dispositivo de sonido. MicrophClient: Interfaz con los métodos requeridos para la captura de audio y envío sobre DDS. 93

126 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.3 Paquete client.audiopacket Paquete communicationdds.videoframe Este paquete tiene como función el envío y recepción de paquetes de vídeo sobre DDS. Con este fin, se proponen las siguientes clases (ver figura 4.4): VideoFrame: Clase que representa la estructura de datos intercambiada en el dataspace, portadora de la información de interés. VideoFrameSubscriber: Clase que mantendrá la subscripción a un tópico de vídeo y enviará los paquetes recibidos a client.main. Internamente cuenta con la clase VideoFrameQosModifier, encargada de la adaptación de los parámetros de las políticas de calidad de servicio a las condiciones del sistema o/y la red. Además, se ha previsto la clase VideoFrameListener, que implementa un listener DDS, necesario para capturar las interrupciones generadas desde middleware DDS. 94

127 Capítulo 4. Diseño VideoFramePublisher: Clase encargada de gestionar la publicación de paquetes de vídeo sobre DDS. Internamente cuenta con la clase VideoFrameQosModifier, encargada de la adaptación de los parámetros de las políticas de calidad de servicio a las condiciones del sistema o/y la red. Además, se ha previsto la clase VideoFrameListener, que implementa un listener DDS, necesario para capturar las interrupciones generadas desde middleware DDS. VideoFrameDataWriter, VideoFrameDataReader: Clases correspondientes al datawriter y datareader utilizados para recibir y enviar información al dataspace. VideoFrameTypeCode, VideoFrameTypeSupport, VideoFrameSeq, MAX_VIDEO_PACKET: Clases de apoyo para el acceso al middleware DDS y definición de tamaño máximo de paquete. Figura 4.4 Paquete communicationdds.videoframe Paquete communicationdds.audiopacket Este paquete tiene como función el envío y recepción de paquetes de audio sobre DDS. Con este fin, se han diseñado las siguientes clases (ver figura 4.5): AudioPacket: Clase que representa la estructura de datos intercambiada en el dataspace, portadora de la información de interés. AudioPacketSubscriber: Clase que mantendrá la subscripción a un tópico de audio y enviará los paquetes recibidos a client.main para su reproducción. Además, se ha previsto la clase AudioPacketListener, que implementa un listener DDS, necesario para poder capturar las interrupciones generadas desde middleware DDS. 95

128 Plataforma de Trabajo Colaborativo sobre Middleware DDS AudioPacketPublisher: Clase encargada de gestionar la publicación de paquetes de audio sobre DDS. AudioPacketDataWriter, AudioPacketDataReader: Clases correspondientes al datawriter y datareader utilizados para recibir y enviar información al dataspace. AudioPacketTypeCode, AudioPacketTypeSupport, AudioPacketSeq, MAX_AUDIO_PACKET: Clases de apoyo para el acceso al middleware DDS y definición de tamaño máximo de paquete. Figura 4.5 Paquete communicationdds.audiopacket Paquete communicationdds.signaling Este paquete se encarga del intercambio de información de señalización entre los distintos miembros de una sala de conferencia. El diseño realizado, cuyas clases se muestran en la figura 4.6, incorpora el mecanismo para la gestión de congestión comentado en el apartado del presente capítulo y la asignación del canal de audio por parte del moderador: SessionSignaling: Clase que representa la estructura de datos intercambiada en el data-space, portadora de la información de señalización. SessionSignalingSubscriber: Clase que mantendrá la subscripción a un tópico de señalización y según la información recibida realizará una llamada al método adecuado de client.main. Internamente cuenta con la clase SessionSignalWatcher, encargada de ejecutar las llamadas que requieran modificar las políticas de calidad de servicio de DDS (por ejemplo, para cambiar el propietario del canal de audio). Además, se ha 96

129 Capítulo 4. Diseño previsto la clase SessionSignalingListener, que implementa un listener DDS, necesario para poder capturar las interrupciones generadas desde middleware DDS. SessionSignalingPublisher: Clase encargada de gestionar la publicación de paquetes de señalización sobre DDS. SessionSignalingDataWriter, SessionSignalingDataReader: Clases correspondientes al datawriter y datareader utilizados para recibir y enviar información al data-space. SessionSignalingTypeCode, SessionSignalingSupport, SessionSignalingSeq: Clases de apoyo para el acceso al middleware. Figura 4.6 Paquete communicationdds.signaling Paquete communicationdds.messenger Este paquete se encarga del intercambio de mensajes de texto entre los distintos miembros de una sala de conferencia. A continuación de describen las clases que constituyen este paquete, tal y como se muestra en la figura 4.7. ImMessagePublisher: Clase que representa la estructura de datos intercambiada en el data-space, portadora de los mensajes. ImMessageSubscriber: Clase que mantendrá la subscripción a un tópico de mensajería. Se ha previsto la clase ImMessageListener, que implementa un listener DDS, necesario para poder recibir las llamadas desde middleware DDS. ImMessagePublisher: Clase encargada de gestionar la publicación de mensajes sobre DDS. 97

130 Plataforma de Trabajo Colaborativo sobre Middleware DDS ImMessageDataWriter, ImMessageDataReader: Clases correspondientes al datawriter y datareader utilizados para recibir y enviar información al dataspace. ImMessageTypeCode, ImMessageSupport, ImMessageSeq: Clases de apoyo para el acceso al middleware. Figura 4.7 Paquete communicationdds.messenger Paquete communicationipcamera Este paquete permite la comunicación con una cámara IP. Ha sido diseñado para soportar cualquier modelo de cámara IP, mediante la carga de parámetros de configuración de las mismas desde un archivo de configuración XML. Para más información acerca de esta característica, consultar la sección 5.3 del capítulo 5. A continuación se describen las clases que constituyen el paquete (ver figura 4.8). IPCameraVideo: Clase que permite la adquisición de vídeo desde una cámara IP mediante conexiones HTTP. IPCameraAudio: Clase que permite la adquisición de audio desde una cámara IP. IPCameraConfLoader: Esta clase se encarga de cargar configuraciones de cámaras IP desde un archivo XML. IPCameraParam: Esta clase modela los parámetros configurables en una cámara IP. 98

131 Capítulo 4. Diseño Figura 4.8 Paquete communicationipcamera 4.4 Diagramas de secuencia Con objeto de describir las operaciones y funcionamiento del sistema, se ha optado por una descripción formal basada en diagramas de secuencia Subsistema client.main Como se indicó con anterioridad, el sistema client.main constituye la parte central del sistema. Desde la misma el usuario tiene acceso a los distintos servicios de la plataforma. A continuación se describen las operaciones que se han considerado de mayor interés. Iniciar/cerrar sistema En la figura 4.9 se presenta el diagrama de secuencia correspondiente al inicio y cierre del sistema. Figura 4.9 Diagrama de secuencia Iniciar/cerrar sistema 99

132 Plataforma de Trabajo Colaborativo sobre Middleware DDS Buscar salas Una vez el sistema ha sido iniciado, el usuario puede activar la búsqueda de salas, con lo que el sistema mostrará una lista con las salas de conferencia disponibles. En la figura 4.10 se muestra el diagrama de secuencia correspondiente a esta operación. Figura 4.10 Diagrama de secuencia Buscar salas Unirse a sala El usuario puede solicitar unirse a una sala de las descubiertas por el sistema. Al acceder a una sala, se inician de forma automática las publicaciones y subscripciones a tópicos de señalización y mensajería. Además, se mostrará una interfaz gráfica desde la que es posible iniciar publicaciones/subscripciones a audio y vídeo, intercambiar mensajes de texto y solicitar el canal de audio. En la figura 4.11 se muestra el diagrama de secuencia correspondiente a esta operación. 100

133 Capítulo 4. Diseño Figura 4.11 Diagrama de secuencia Unirse a sala Abandonar sala En la figura 4.12 se muestra el diagrama de secuencia correspondiente a la operación abandonar sala. Cuando el usuario abandona una sala, es necesario enviar la señal de terminación a los distintos subsistemas, para una adecuada liberación de recursos, tras lo que se cerrará la interfaz de usuario. 101

134 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.12 Diagrama de secuencia Abandonar sala Notificar problemas en vídeo Cuando se recibe una notificación sobre la existencia de problemas en la recepción de vídeo, el sistema toma medidas, dependiendo del tipo de difusión configurada en el sistema es Multicast o Unicast. En la figura 4.13 se muestra el correspondiente diagrama de secuencia. Figura 4.13 Diagrama de secuencia Notificar problemas vídeo 102

135 Capítulo 4. Diseño Subsistema client.audiopacket El sistema client.audiopacket permite el envío y recepción de señal de audio sobre middleware DDS. Como se indicó en el apartado XX, el canal de audio es moderado, por lo que sólo un participante de la sala tendrá la posibilidad de transmitir al mismo tiempo. Iniciar/finalizar captura El diagrama de secuencia de la figura 4.14 se corresponde a la operación iniciar/finalizar captura. Mientras que la captura de audio se mantenga activa, se publicarán paquetes en el tópico de audio. Figura 4.14 Diagrama de secuencia Iniciar/terminar captura Iniciar/finalizar reproducción Para reproducir la señal de audio publicada en la sala, el sistema deberá subscribirse al tópico adecuado e inicializar la decodificación de la señal. La figura 4.15 muestra el diagrama de secuencia correspondiente a las operaciones iniciar y finalizar reproducción. 103

136 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.15 Diagrama de secuencia Iniciar/terminar reproducción Cambiar audio OWNERSHIP La moderación del canal se consigue por medio de la política OWNERSHIP. El diagrama de secuencia de la figura 4.16 muestra cómo se actualiza el valor de OWNERSHIP_STRENGTH. Figura 4.16 Diagrama de secuencia Cambiar audio OWNERSHIP Publicar/reproducir paquete de audio Las operaciones publicar y reproducir paquete de audio permiten intercambiar paquetes de audio entre los distintos participantes de la sala. En la figura 4.17 se presenta el diagrama de secuencia correspondiente. 104

137 Capítulo 4. Diseño Figura 4.17 Diagrama de secuencia Publicar/reproducir paquete de audio Subsistema communicationdds.videoframe El sistema communicationdds.videoframe gestiona el envío y recepción de vídeo sobre middleware DDS. Además, notifica al sistema cuando se incumple el tiempo máximo de recepción o envío de datos (especificado mediante la política DEADLINE) o hay cambios en la política LIVELINESS (con lo que se detecta cambios en la presencia de otros participantes de la sala) en el intercambio de datos. A continuación se detallan las operaciones más relevantes. Iniciar/terminar subscripción En la figura 4.18 se presenta el diagrama de secuencia para las operaciones iniciar y terminar subscripción. Una vez se inicia la subscripción al tópico de vídeo, se actualizará la interfaz de usuario con las imágenes que se reciban a través de DDS. 105

138 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.18 Diagrama de secuencia Iniciar/terminar subscripción Iniciar/terminar publicación En la figura 4.19 se presenta el diagrama de secuencia para las operaciones iniciar y terminar publicación. Mientras la publicación permanezca activa, será posible enviar el vídeo sobre DDS. 106

139 Capítulo 4. Diseño Figura 4.19 Diagrama de secuencia Iniciar/terminar publicación Publicar/recibir VideoFrame El objetivo principal de todo middleware de red es el intercambio de información entre sistemas. La operación mostrada en la figura 4.20 permite el intercambio de imágenes entre dos sistemas remotos a través de middleware DDS. 107

140 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.20 Diagrama de secuencia Publicar/recibir VideoFrame Notificar expiración de DW DEADLINE Cuando aparecen problemas en el envío de vídeo, la política DEADLINE expira. Cuando se da esta situación, se notifica a VideoFrameQosModifier, para que ajuste las políticas QoS de forma adecuada. En la figura 4.21 se muestra el diagrama de secuencia correspondiente. Para más información sobre el cambio de las políticas QoS, ver diagrama Comprobar estado DW DEADLINE. Figura 4.21 Diagrama de secuencia Notificar expiración de DW DEADLINE Notificar expiración de DR DEADLINE Cuando aparecen problemas la recepción de vídeo, la política DEADLINE expira. Cuando se da esta situación, se notifica a VideoFrameQosModifier, para que ajuste las políticas QoS de forma adecuada y a ClientMain para que tome las medidas oportunas. En la figura 4.22 se muestra el diagrama de secuencia correspondiente. Para más información sobre el cambio de las políticas QoS, ver diagrama Comprobar estado DR DEADLINE. 108

141 Capítulo 4. Diseño Figura 4.22 Diagrama de secuencia Notificar expiración de DR DEADLINE Notificar cambio en LIVELINESS LIVELINESS nos informa de los cambios en la presencia de entidades remotas. Esta información es transmitida a client.main de acuerdo a la figura 4.23 para que actualice la interfaz de usuario. Figura 4.23 Diagrama de secuencia Notificar cambio en LIVELINESS Comprobar estado de DW DEADLINE Mediante esta operación (figura 4.24), se comprueba periódicamente si ha expirado la política DEADLINE para el datawriter. Si es así, se solicita la reducción de la calidad del vídeo transmitido, para aliviar la carga del datawriter. 109

142 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.24 Diagrama de secuencia Comprobar estado de DW DEADLINE Comprobar estado de DR DEADLINE En la figura 4.25 se muestra el diagrama de secuencia por el que el sistema comprueba periódicamente si expiró la política DEADLINE para el datareader. Cuando expira, se reajustan los valores de DEADLINE y TIME_BASED_FILTER, con objeto de aliviar una posible congestión en el datareader. Figura 4.25 Diagrama de secuencia Comprobar estado de DR DEADLINE Subsistema communicationdds.audiopacket El sistema communicationdds.audiopacket gestiona el envío y recepción de audio sobre middleware DDS. Con objeto de gestionar el canal de audio, se ha utilizado la política OWNERSHIP de DDS, que será la encargada de gestionar que únicamente se entreguen a los subscriptores el audio 110

143 Capítulo 4. Diseño procedente del usuario asignado por el moderador. A continuación se detallan las operaciones más relevantes. Iniciar/terminar subscripción En la figura 4.26 se presenta el diagrama de secuencia para las operaciones iniciar y terminar subscripción al tópico de audio. Una vez se inicia la subscripción, se actualizará entregarán los paquetes recibidos a client.audiopacket para su reproducción. Figura 4.26 Diagrama de secuencia Iniciar/terminar subscripción Iniciar/terminar publicación En la figura 4.27 se presenta el diagrama de secuencia para las operaciones iniciar y terminar publicación. Mientras la publicación permanezca activa, será posible enviar paquetes de audio sobre DDS. 111

144 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.27 Diagrama de secuencia Iniciar/terminar publicación Publicar/recibir AudioPacket En la figura 4.28 se presenta la operación mediante la cual dos sistemas remotos pueden intercambiar paquetes de audio. Figura 4.28 Diagrama de secuencia Publicar/recibir Audio Packet 112

145 Capítulo 4. Diseño Cambiar OWNERSHIP La política OWNERSHIP permite gestionar el control del canal. El diagrama de secuencia de la figura 4.29 indica cómo se notifica al publicador de audio qué valor de OWNERSHIP STRENGTH tiene asignado. Figura 4.29 Diagrama de secuencia Cambiar OWNERSHIP Notificar cambio en LIVELINESS LIVELINESS nos informa de los cambios en la presencia de entidades remotas. Esta información es transmitida a client.main de acuerdo a la figura 4.30 para que actualice la interfaz de usuario. Figura 4.30 Diagrama de secuencia Notificar cambio en LIVELINESS Subsistema communicationdds.signaling El sistema communicationdds.signaling es el encargado de intercambiar mensajes de señalización entre los sistemas remotos. Dichos mensajes contienen información sobre el dueño del 113

146 Plataforma de Trabajo Colaborativo sobre Middleware DDS canal de audio o las expiraciones de la política DEADLINE en una entidad remota. A continuación se detallan las operaciones más relevantes. Iniciar/terminar subscripción Antes de poder recibir mensajes de señalización, es necesario subscribirse al tópico adecuado. En la figura 4.31 se muestra el diagrama de secuencia correspondiente a esta operación. Figura 4.31 Diagrama de secuencia Iniciar/terminar Subscripción Iniciar/terminar publicación En la figura 4.32 se presenta el diagrama de secuencia para las operaciones iniciar y terminar publicación, necesarias para poder enviar mensajes de señalización. 114

147 Capítulo 4. Diseño Figura 4.32 Diagrama de secuencia Iniciar/terminar publicación Publicar/recibir SessionSignaling Mediante esta operación es posible intercambiar mensajes de señalización entre distintos sistemas remotos. En la figura 4.33 se muestra el diagrama de secuencia correspondiente. Figura 4.33 Diagrama de secuencia Publicar/recibir SessionSignaling Notificar cambio en LIVELINESS Esta operación (ver figura 4.34) permite conocer qué usuarios se encuentran en la sala de conferencia actual, informando de los cambios que se produzcan. 115

148 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.34 Diagrama de secuencia Notificar cambio en LIVELINESS Subsistema communicationdds.messenger El sistema communicationdds.messenger es el encargado de intercambiar mensajes de texto entre los sistemas remotos. Iniciar/terminar subscripción En la figura 4.35 se muestra el diagrama de secuencia correspondiente a las operaciones iniciar/terminar subscripción. Una vez que el sistema esté subscrito al tópico de mensajería, podrá recibir mensajes de otros usuarios presentes en la sala. 116

149 Capítulo 4. Diseño Figura 4.35 Diagrama de secuencia Iniciar/terminar subscripción Iniciar/terminar publicación Antes de poder enviar mensajes de texto, el sistema ha de iniciar una publicación asociada al tópico de mensajería. En la figura 4.36 se presenta el diagrama de secuencia correspondiente a estas operaciones. 117

150 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.36 Diagrama de secuencia Iniciar/terminar publicación Publicar/recibir ImMessage El diagrama de secuencia presentado en la figura 4.37 permite al sistema intercambiar mensajes de texto con otros sistemas remotos. Figura 4.37 Diagrama de secuencia Publicar/recibir ImMessage 118

151 Capítulo 4. Diseño Notificar cambio en LIVELINESS Al igual que ocurría con los subsistemas de vídeo, audio y señalización, se ha definido una operación por la que se puede conocer los cambios en la presencia de otros usuarios. En la figura 4.38 se muestra el diagrama de secuencia correspondiente. Figura 4.38 Diagrama de secuencia Notificar cambio en LIVELINESS Subsistema communicationipcamera El sistema communicationipcamera es el encargado de comunicarse con una cámara IP para la obtención de vídeo, con el fin de publicarlo sobre DDS. Conectar/desconectar sistema El diagrama de secuencia de la figura 4.39 engloba las operaciones conectar y desconectar sistema, que inician/detienen la conexión con una cámara IP, así como la publicación en un tópico de vídeo los frames obtenidos desde una cámara IP. 119

152 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura 4.39 Diagrama de secuencia Conectar/desconectar sistema Cambiar calidad Cuando aparecen problemas en un datawriter de vídeo local o en un datareader de vídeo remoto, o bien cuando no existen problemas, la calidad de la señal de vídeo se modifica dinámicamente para ajustarse a las condiciones actuales. La operación descrita en la figura 4.40 permite este comportamiento. 120

153 Capítulo 4. Diseño Figura 4.40 Diagrama de secuencia Cambiar calidad Publicar frame de vídeo La operación descrita en la figura 4.41 permite la publicación de frames de vídeo generados por una cámara IP sobre middleware DDS. Figura 4.41 Diagrama de secuencia Publicar frame de vídeo 4.5 Conclusiones En el presente capítulo se ha descrito el diseño del sistema. En primer lugar, se ha especificado la arquitectura del sistema, mediante diagrama de paquetes y de clases y detallando qué políticas de calidad de servicio ha incorporado el sistema. Asimismo, con el fin de una descripción funcional de la 121

154 Plataforma de Trabajo Colaborativo sobre Middleware DDS plataforma, se han incluido los diagramas de secuencia de las operaciones disponibles para cada uno de sus módulos. Tras el diseño de la arquitectura y comportamiento del sistema, se ha llevado a cabo la implementación del mismo. En el siguiente capítulo de la memoria se detallarán algunos detalles de la implementación que han sido considerados de especial interés. 122

155 Capítulo 5. Implementación El presente proyecto no se ha limitado al diseño del sistema, sino que se ha llevado a cabo la implementación del mismo. En este capítulo se describen algunos detalles de la implementación que se consideran especialmente relevantes. En particular, los siguientes apartados tratarán los siguientes aspectos: Descripción IDL de los tipos de datos intercambiados. Comunicación con cámara IP. Integración de codec de audio SPEEX. 5.1 Descripción IDL de los tipos de datos intercambiados Como se indicó en la sección de la memoria, DCPS aplica una aproximación centrada en datos. Por tanto, una parte fundamental de la definición de un sistema sobre middleware DDS es el modelado de los datos que se intercambiarán. RTI DDS dispone de la herramienta rtiddsgen para la generación automatizada de código a partir de un archivo IDL (Interface Description Language) [51]. IDL es un estándar de la OMG utilizado en sistemas de computación distribuida para la descripción de los componentes de las interfaces. IDL permite especificar los datos que se intercambiarán en un lenguaje neutral, pudiendo generar componentes en diversos lenguajes, sin que se pierda la interoperabilidad de los mismos. A continuación se incluyen los modelos IDL diseñados para la comunicación del sistema desarrollado: VideoFrame En el listado 5.1 se presenta el IDL para el envío de stream de vídeo. Además de incluir los bytes correspondientes a una imagen JPEG, permite transportar información sobre el origen y momento en el que se envió el frame. 123

156 Plataforma de Trabajo Colaborativo sobre Middleware DDS Listado 5.1 Modelo IDL VideoFrame AudioPacket Descripción del paquete de audio, contiene información sobre el codec utilizado (ver listado 5.2), el origen del paquete, instante de tiempo en el que se originó y el paquete de audio en sí. Listado 5.2 Modelo IDL AudioPacket SessionSignaling El modelo IDL del listado 5.3 permite el intercambio de mensajes de señalización entre los distintos sistemas de videoconferencia. Incluye información sobre el origen de los datos, sala a la que pertenece el mensaje, identidad del dueño del canal de audio, instante de tiempo de envío, solicitud de canal de audio y flags para la detección de expiración de la política DEADLINE en un sistema remoto 124

157 Capítulo 5. Implementación Listado 5.3 Modelo IDL SessionSignaling ImMessage En el listado 5.4 se presenta el modelo IDL para el envío y recepción de mensajes de texto entre los participantes. Listado 5.4 Modelo IDL ImMessage 5.2 Herramienta rtiddsgen En el apartado anterior se describieron los tipos de datos utilizados por el sistema mediante lenguaje IDL. Como se comentó, RTI DDS dispone de la herramienta rtiddsgen para la generación de interfaces de acceso al middleware. En este apartado se indica cómo se utilizó esta herramienta durante el desarrollo del proyecto. rtiddsgen es un programa ejecutado mediante consola de comandos que permite, mediante un uso adecuado de sus parámetros de entrada, generar código específico en diversos lenguajes (C, C++, 125

158 Plataforma de Trabajo Colaborativo sobre Middleware DDS Java, C++/CLI y C#) y arquitecturas. Como ejemplo, a continuación se indica el comando utilizado para la obtención del código base del subsistema communicationdds.videoframe. rtiddsgen -language java -package communicationdds - ppdisable -example i86win32jdk VideoFrame.idl Los parámetros utilizados son: -language java: Especifica el lenguaje, en este caso Java. -package communicationdds: Especifica el paquete al que pertenecerán las clases generadas. Opción sólo válida para Java. -ppdisable: Deshabilita el uso de preprocesador -example i86win32jdk: Generación de un ejemplo para una arquitectura concreta. Tras ejecutar el programa con los anteriores parámetros, se generaron las clases necesarias para el intercambio de los tipos de datos descritos en el archivo VideoFrame.idl. Dichas clases (junto a las correspondientes a los subsistemas communicationdds.audiopacket, communicationdds.signaling y communicationdds.messenger) constituyeron la base de partida para la implementación de la plataforma desarrollada. 5.3 Comunicación con cámara IP Como se indicó en los apartados y de la presente memoria, el sistema recibe la señal de vídeo desde una cámara IP. El hecho de elegir una cámara de estas características se basó en varias razones: En primer lugar, la instalación de cámaras IP en salas destinadas a videoconferencia se está generalizando. Estas cámaras cuentan con multitud de funcionalidades que las hacen especialmente adecuadas para este fin. Además, al ser autosuficientes, las cámaras IP no dependen de ningún equipo externo para su funcionamiento. Por otro lado, al utilizar una cámara IP, se liberaba al sistema del procesamiento y recodificación de la señal de vídeo. Este hecho, al tratarse de un sistema implementado en Java, implica una importante mejora en su rendimiento. Finalmente, la implementación de un puente entre cámaras IP y middleware DDS podría ser reutilizado en gran variedad de aplicaciones. Por ejemplo, para el desarrollo de un sistema de vigilancia en el que la información de control y el stream de vídeo se intercambie mediante middleware DDS Comunicación con cámara IP AXIS 207W. VAPIX. Para la realización del presente proyecto se ha utilizado una cámara AXIS 207W. Las cámaras de este fabricante disponen de una API común, denominada VAPIX [56], que permite interactuar con las mismas mediante HTTP. De este modo, se pueden configurar de forma remota lo parámetros del stream de vídeo/audio capturado o incluso cambiar la posición del eje de la cámara. 126

159 Capítulo 5. Implementación Las peticiones a la cámara se realizan mediante el método GET de HTTP, siendo el formato de los mensajes el siguiente: GET <servername>/axis-cgi/mjpg/video.cgi [?<parameter>=<value>[&<parameter>=<value>...]] HTTP/1.0 Donde <parameter> se sustituirá por el nombre del parámetro que se quiera cambiar y <value> por el valor de dicho parámetro. En la siguiente tabla se presentan las opciones que se utilizan en el sistema implementado. <parameter>=<value> Valores permitidos Descripción resolution=<string> 1280x1024, 1280x960, 1280x720, 768x576, 4CIF, 704x576, 704x480, VGA, 640x480, 640x360, 2CIFEXP, 2CIF, 704x288, 704x240, 480x360, CIF, 384x288, 352x288, 352x240, 320x240, 240x180, QCIF, 192x144, 176x144, 176x120, 160x120 Especifica la resolución de las imágenes obtenidas. compression=<int> Ajusta el nivel de compresión de la imagen. Un valor de 100 corresponde al máximo nivel de compresión, para el que la calidad de la imagen será la menor posible, reduciéndose su tamaño. fps=<int> 0, n Permite especificar el número de frames por segundo que la cámara envía. Tabla 5.1 Parámetros de configuración de la cámara mediante HTTP Archivo XML de configuración de cámara IP Aunque durante la realización del proyecto se ha trabajado únicamente con la cámara 207W de AXIS, se ha procurado que la aplicación sea flexible, de tal forma que se pueda operar sobre el mayor conjunto de cámaras posible. Con este fin se ha implementado un método que a partir de archivos de configuración en XML, permite cambiar con flexibilidad el modelo de cámara utilizado sin necesidad de modificar el sistema. Con el fin de especificar el formato del archivo de configuración, se ha diseñado un Esquema XML. Esquema XML es un lenguaje que describe la estructura y restricciones de los contenidos de los documentos XML de forma precisa, más allá de las normas sintácticas impuestas por el lenguaje XML [58]. XML Esquema fue desarrollado por el World Wide Web Consortium y alcanzó el nivel de recomendación en mayo de En el listado 5.5 se presenta el documento de Esquema XML al que han de ajustarse los archivos de configuración de la cámara IP. 127

160 Plataforma de Trabajo Colaborativo sobre Middleware DDS Listado 5.5 Esquema XML al que han de ajustarse los archivos de configuración de la cámara IP En el listado 5.6 se muestra un ejemplo de archivo de configuración, con los parámetros de la cámara AXIS utilizada en el proyecto. 128

161 Capítulo 5. Implementación Listado 5.6 Ejemplo de archivo de configuración 5.4 Gestión de audio Uno de los problemas importantes que surgieron durante la implementación del sistema fue la elección del mecanismo de gestión de audio, tanto para la captura como para la reproducción del mismo. De hecho, este es quizás el principal problema con el que se encuentran los desarrolladores de Java que implementan aplicaciones multimedia con requisitos de tiempo real [59]. Concretamente, se estudiaron dos alternativas principales: Utilizar la API JMF (Java Media Framework) [60], una librería externa a la API estándar de Java, que permite un acceso a los dispositivos de captura y reproducción de audio. Las ventajas principales de esta aproximación eran el mayor rendimiento del sistema y la gran variedad de codecs disponibles. Sin embargo, contaba con problemas importantes. En primer lugar, la dificultad existente para cambiar el protocolo de transporte, por defecto RTP (Real- Time Protocol), a RTPS. La API de JMF está totalmente orientada al envío de streaming multimedia sobre RTP, no ofreciendo ningún método para sustituir RTP por otro protocolo. Aunque JMF sí permite personalizar el protocolo contenedor de RTP, el presente proyecto no pretende añadir capas intermedias entre RTP y otros protocolos de transporte, sino sustituir RTP. Por otro lado, JMF es una librería externa a la API estándar de Java, requiriendo su instalación previa o distribución con el propio sistema. Las desventajas descritas, unidas a la necesidad de utilizar una versión específica para alcanzar un rendimiento óptimo, llevaron a descartar esta alternativa. 129

162 Plataforma de Trabajo Colaborativo sobre Middleware DDS La segunda opción estudiada fue gestionar el audio mediante la API Java Sound [61] [62] incluida en la distribución estándar de Java. Java Sound permite el control de los dispositivos de audio a un nivel más bajo que JMF, pudiendo personalizar totalmente el protocolo de transporte utilizado. Esta solución implicaba otras dificultades, como la necesidad de gestionar los búferes, un rendimiento menor que JMF (debido a que JMF dispone de versiones optimizadas para distintas arquitecturas) o los escasos codec disponibles por defecto (no obstante esta limitación es subsanable, ya que cuenta con métodos para añadir nuevos codecs). Finalmente, se consideró la solución más adecuada Integración en el sistema. Codec de audio SPEEX. JSPEEX. Para la integración de la gestión de audio en el sistema, se implementan dos interfaces (ver capítulo 4 del proyecto): client.audiopacket.audioplayer y client.audiopacket. MicrophClient. El hecho de utilizar interfaces facilita la extensibilidad del sistema, siendo posible añadir nuevos codecs de audio de forma sencilla. En una primera aproximación, se implementó el codec µlaw para la transmisión de la señal de audio, al no requerir ningún tipo de librería externa. Más tarde, se eligió el codec SPEEX por considerarlo especialmente adecuado para el proyecto. En el siguiente apartado se describen las principales características del codec elegido, SPEEX. Codec de audio SPEEX Para la codificación y decodificación de la señal de audio se ha elegido el codec SPEEX, al considerarlo especialmente adecuado para el sistema desarrollado. SPEEX es de código libre y es complementario a Vorbis [63], enfocado en el procesado de señales de voz. El objetivo fundamental de SPEEX es conseguir una calidad elevada utilizando un ancho de banda reducido. Para ello, se proporcionan múltiples ratios de compresión, soportando banda ultra-ancha (frecuencia de muestreo de 32 khz), banda ancha (16kHz) y banda estrecha (8kHz). Otro aspecto resaltable de SPEEX es su robustez frente a pérdidas de paquetes, pero no a la corrupción de los mismos. Este comportamiento se debe a que el codec fue desarrollado para su uso en aplicaciones de VoIP, que trabajan con UDP (User Datagram Protocol) como protocolo de transporte. Dicho protocolo no garantiza la entrega de los paquetes, pero sí cuenta un mecanismo para la detección de errores (aunque, por desgracia, muy limitado). Para conseguir este comportamiento, SPEEX utiliza CELP (Code Excited Linear Prediction) [64] como técnica de codificación. Dado que en el presente proyecto se enviarán los paquetes de audio sobre DDS (que sí asegura la integridad de los paquetes), esta característica es especialmente adecuada. En cuanto al encapsulado de SPEEX, puede ser transportado por un contenedor Ogg [65] o bien enviado directamente sobre UDP o RTP (Real Time Protocol) [66]. Para la realización del presente proyecto, los paquetes SPEEX han sido encapsulados dentro del paquete RTPS. Por último, destacar que el codec permite cambiar dinámicamente la calidad del stream de audio enviado, siendo posible adaptar el ancho de banda utilizado a las condiciones de la red. 130

163 Capítulo 5. Implementación Librería JSPEEX Con el fin de integrar SPEEX en el sistema implementado, se estudiaron dos alternativas. A continuación se indican las características principales de ambas posibilidades: Utilizar JNI (Java Native Interface). JNI es un framework de programación que permite la interacción entre un programa Java ejecutado sobre la máquina virtual de Java y código escrito en otro lenguaje. De este modo, se podría hacer uso de la implementación original del codec, escrita en C. Sin embargo, esta alternativa es desaconsejable siempre que exista una alternativa desarrollada en Java, al incrementar notablemente la complejidad del sistema y perder la portabilidad. Librería JSPEEX [11]. Se trata de una librería escrita en Java que implementa la versión del codec SPEEX. Dado que se mantenía la cualidad multiplataforma del sistema, se llegó a la conclusión que esta opción era la más apropiada. Sin embargo, durante la fase de implementación surgieron problemas con la librería JSPEEX, ya que su funcionamiento no era el esperado. Concretamente, la librería lanzaba una excepción del tipo Lost Ogg Sync. Tras estudiar las clases de la librería, se descubrió la causa del error. El problema residía que JSPEEX había sido desarrollado fundamentalmente para la grabación y lectura de archivos de audio. Debido a lo anterior, los paquetes SPEEX eran encapsulados en Ogg y surgían problemas cuando el decodificador no recibía la totalidad de los paquetes generados por el codificador remoto. Para resolver esta situación, se consultó la especificación de SPEEX y, de acuerdo a la misma, se suprimió la cabecera Ogg, al estar soportado el envío de paquetes SPEEX encapsulados directamente sobre un protocolo de transporte. 5.5 Conclusiones En este capítulo se han descrito los detalles correspondientes a la implementación de la plataforma que se han considerado de mayor interés. En primer lugar, se incluyeron los modelos de datos intercambiados por el sistema, indicando cómo se utilizaron para la generación de código. Posteriormente, se detalló cómo se accede a la cámara IP y las características de la API de las cámaras del fabricante AXIS. Finalmente, se han explicado los principales problemas que surgieron para integrar audio en la plataforma y cómo se resolvieron. En los capítulos restantes de la memoria se analizará el sistema desarrollado, así como las conclusiones obtenidas. 131

164 Plataforma de Trabajo Colaborativo sobre Middleware DDS 132

165 Capítulo 6. Estimación de Costes En este capítulo se llevará a cabo un estudio económico del proyecto realizado. Para estimar los costes, se han tenido en consideración los siguientes aspectos: La hora de trabajo de un programador se ha estimado en 20 /hora La hora de trabajo de un analista se ha estimado en 40 /hora. Se ha procurado, siempre que ha sido posible, utilizar herramientas libres y gratuitas, con objeto de reducir los costes. 6.1 Tareas y temporización En la tabla 7.1 se identifican las tareas principales y el número de horas invertidas para las mismas. Descripción de la tarea Horas invertidas Estudio del estado del arte y antecedentes 30 Estudio de la tecnología DDS 90 Análisis y especificación del proyecto 40 Diseño 90 Implementación 90 Pruebas 30 Generación de documentación 100 TOTAL 470 Tabla 6.1 Tareas realizadas y duración estimada 6.2 Costes En este apartado se estiman los costes del proyecto. En primer lugar se analizan los costes requeridos por las infraestructuras necesarias y finalmente se estudian los costes asociados al esfuerzo de desarrollo del sistema mediante el modelo COCOMO (Constructive Cost Model) [67]. 133

166 Plataforma de Trabajo Colaborativo sobre Middleware DDS Infraestructuras En las secciones y de la presente memoria se detallaron los recursos hardware y software necesarios para la realización del proyecto, a continuación se detallan los costes estimados de dichos recursos: Recurso Coste estimado Ordenador PC 1000 Cámara IP (modelo 207W) de la marca AXIS 200 Sistema Operativo (GNU/Linux) 0 Sistema Operativo (Windows XP) 80 Paquete de ofimática Microsoft Office Entorno de desarrollo Eclipse 0 Librería NDDS 4.2e Desconocido Librería JSPEEX 0 Tabla 6.2 Infraestructuras necesarias para el desarrollo del sistema Recurso Coste estimado Ordenador PC 1000 Cámara IP (modelo 207W) de la marca AXIS 200 Sistema Operativo (GNU/Linux) 0 Máquina virtual Java Librería NDDS 4.2e Desconocido Librería JSPEEX 0 Tabla 6.3 Infraestructuras necesarias para la explotación del sistema Aunque en los costes de explotación se ha indicado GNU/Linux como sistema operativo, al haber sido implementado el sistema en Java, se podrá hacer uso de cualquier sistema operativo que permita una máquina virtual Java. En cuanto a la licencia de NDDS 4.2e, el precio es desconocido, aunque para el desarrollo del sistema el coste de la misma fue nulo, ya que la Universidad de Granada y en particular el departamento de teoría de la señal, telemática y comunicaciones están dentro del University Program [68] de Real-Time Innovations, Inc Esfuerzo de desarrollo del sistema Con objeto de estimar el coste del esfuerzo de desarrollo del programa se estimó la posibilidad de utilizar el modelo COCOMO, publicado por primera vez por Barry Boehm en Se trata de un modelo ampliamente utilizado en la estimación de costes de proyectos software. El modelo COCOMO incluye tres submodelos (básico, intermedio y detallado), cada uno de los cuales ofrece un nivel de detalle y aproximación diferente. Para el estudio de los costes asociados al proyecto desarrollado, en un primer lugar se eligió el submodelo básico, al considerar que la complejidad del proyecto no era excesiva. El submodelo básico se divide en tres modos, que representan el tipo de proyecto. A continuación se describen dichos modos: 134

167 Capítulo 6. Estimación de Costes Modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía de unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles de líneas (medio). Modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas. Modo rígido o empotrado: el proyecto tiene unas fuertes restricciones, que pueden estar relacionadas con la funcionalidad o técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla. El problema que presenta el modelo COCOMO es que fue publicado por primera vez en 1981, por lo que refleja las prácticas de desarrollo de software de aquél momento. En la década y media siguiente las técnicas de desarrollo de software cambiaron drásticamente. Estos cambios afectan tanto al gasto de esfuerzo en diseñar y gestionar el proceso de desarrollo de software como a la creación del producto De hecho, aunque el modelo COCOMO puede funcionar relativamente bien si el proyecto se implementa mediante un lenguaje imperativo, los resultados no son adecuados cuando el lenguaje utilizado es orientado a objetos. Estos y otros cambios provocaron que la aplicación del modelo COCOMO original empezara a resultar problemática. La única solución posible al problema fue rediseñar el modelo. De este modo, tras muchos años de esfuerzo combinado entre USC-CSE1, IRUS [69] [70] y otras organizaciones, se creó el modelo COCOMO II [71] El parámetro básico de entrada del modelo COCOMO II es el número de líneas de código del proyecto. En el caso que nos ocupa, el número de líneas de código se presenta en la siguiente tabla: Número de Líneas Código 6000 Comentarios 3000 En blanco 2500 Total Tabla 6.4 Líneas de código del proyecto Es importante indicar que en la tabla anterior se incluyen únicamente el número de líneas nuevas generadas, no tomando en consideración las generadas de forma automática por la librería de RTI ni las modificadas en el proyecto JSPEEX. Para la aplicación del modelo COCOMO II, se ha utilizado una herramienta gratuita disponible en la página web de la Universidad de California [72], utilizando los siguientes parámetros: Parámetro Valor Número de líneas nuevas 6000 Experiencia en la temática del proyecto Alta (H) Flexibilidad de desarrollo Máxima (XH) Arquitectura/Resolución de riesgos Normal (N) 135

168 Plataforma de Trabajo Colaborativo sobre Middleware DDS Cohesión de equipo Máxima (XH) Madurez del proyecto Alta (H) Fiabilidad requerida Normal (N) Tamaño base de datos Bajo (L) Complejidad del producto Normal (N) Reusabilidad Normal (N) Documentación Normal (N) Porcentaje tiempo ejecución Alto (H) Porcentaje tiempo almacenamiento Normal (N) Variabilidad de la plataforma Baja (L) Capacidad del analista Normal (N) Capacidad del programador Normal (N) Continuidad personal Muy alta (VH) Experiencia en el tipo de aplicación Alta (H) Experiencia en la plataforma Alta (H) Experiencia con el lenguaje Alta (H) Uso de herramientas software Alta (H) Comunicaciones entre miembros del equipo Total (XH) Plan de desarrollo requerido Normal (N) Tabla 6.5 Parámetros para calcular costes mediante COCOMO II Con los parámetros anteriores, el modelo COCOMO II determina que el proyecto abordado supone un esfuerzo equivalente de 6,6 personas/mes durante 6,5 meses. Además, el modelo COCOMO II aporta información sobre la distribución de actividades que supone el proyecto. De este modo, se ha obtenido la siguiente tabla, que muestra la asignación de personas/mes para cada actividad: Tarea/Fase Inicial Elaboración Construcción Transición Total Gestión Entorno Requerimientos Diseño Implementación Evaluación Despliegue Tabla 6.6 Distribución de actividades por personas/mes para el modelo COCOMO II Según lo calculado en la tabla 7.1 se han invertido un total de 470 horas en la realización del proyecto (lo que equivale a un total de tres meses de trabajo de una persona). Por tanto, los resultados obtenidos por COCOMO II para este caso no se han correspondido a la realidad. Las razones que justifican la diferencia existente entre los resultados del modelo y los reales son diversas. En primer lugar, el modelo COCOMO II únicamente calcula una estimación del esfuerzo, por lo que los resultados no son nunca exactos. Además, el sistema ha sido implementado mediante lenguaje Java que, como se indicó en la sección del capítulo introductorio, facilita el prototipado rápido de aplicaciones. Por último, como se indicó en el capítulo 1 de la presente memoria el uso de 136

169 Capítulo 6. Estimación de Costes middleware de red reduce el esfuerzo necesario para implementar sistemas distribuidos, lo que sin duda ha reducido el tiempo de desarrollo del sistema. 6.3 Conclusiones En este capítulo se ha efectuado una estimación de los costes del proyecto, incluyendo los gastos asociados a los recursos hardware, software y humanos invertidos. Además, se comparado el esfuerzo invertido con el resultado de la estimación del modelo COCOMO II. En el siguiente capítulo se expondrán las conclusiones extraídas del trabajo realizado y se indicarán las líneas de trabajo futuro que han quedado abiertas. 137

170 Plataforma de Trabajo Colaborativo sobre Middleware DDS 138

171 Capítulo 7. Resultados y trabajo futuro Este capítulo presenta las conclusiones alcanzadas tras la elaboración del proyecto, indicando las líneas de trabajo futuro que han quedado abiertas. 7.1 Principales contribuciones del proyecto Los resultados del desarrollo de este proyecto han sido presentados en Julio de 2008 en el IX Workshop on Distributed Object Computing for Real-time and Embedded Systems celebrado en Washington (DC, USA) bajo el título QoS Policies for Audio/Video Distribution Over DDS Middleware [73]. Este encuentro, organizado por la OMG, constituye un foro para ingenieros de software e investigadores en el campo de los sistemas distribuidos y de tiempo real. El trabajo actual ha conseguido cumplir los objetivos propuestos con las siguientes conclusiones: 1. La utilización de middleware DDS efectivamente acorta los tiempos de desarrollo de aplicaciones que requieren la distribución de datos en tiempo real. Además, DDS facilita la implementación de servicios como el descubrimiento dinámico de salas, la moderación del canal de audio o notificación de presencia gracias a la provisión de un conjunto extenso de políticas de calidad de servicio. 2. La aplicación del modelo de publicación-subscripción para un sistema de videoconferencia no es sólo viable, sino que además es adecuada. Esta aproximación, al no requerir de un servidor centralizado para tareas como el descubrimiento de salas o intercambio de datos, es altamente escalable. 3. Dada la arquitectura modular del sistema desarrollado, el código generado es altamente reutilizable, por lo que se pueden integrar con un mínimo esfuerzo los servicios de mensajería, intercambio de audio o vídeo implementados en nuevas aplicaciones que se desarrollen. 4. La implementación de un puente DDS/HTTP para el acceso a cámaras IP proporciona una interfaz reutilizable en aplicaciones fuera del ámbito de la videoconferencia. Por ejemplo, puede servir para implementar sistemas de videovigilancia que deban gestionar numerosas 139

172 Plataforma de Trabajo Colaborativo sobre Middleware DDS cámaras distribuidas. Además, la descripción de los parámetros de las cámaras mediante XML facilita la reusabilidad del puente. 7.2 Trabajo futuro Aunque el sistema desarrollado es completamente funcional, podría ser mejorado en los siguientes aspectos: Realización de test analíticos de escalabilidad: Aunque la plataforma implementada ha sido testeada y cumple la funcionalidad especificada, sería deseable comprobar hasta qué punto es escalable cuando es utilizada por un número elevado de usuarios y/o de salas de conferencia. Durante la realización del presente proyecto no fue posible realizar dicho estudio, debido a no contar con los recursos necesarios (concretamente, cámaras IP). Mayor soporte de codecs de audio: Actualmente el sistema soporta los codecs µlaw y SPEEX para audio. Un mayor soporte de codecs lo dotaría de una mayor flexibilidad. Mejora del rendimiento alcanzado en audio: Dado que el sistema se ha implementado sobre Javasound, cuenta con ciertas restricciones de retardo inevitables. Para mejorar esta situación sería necesario utilizar JNI (Java Native Interface), método que permite la ejecución de código escrito en un lenguaje distinto de Java y con el que se podría hacer uso de librerías más eficientes. Esta aproximación implica, sin embargo, la pérdida de la portabilidad del sistema (al requerir de librerías específicas para cada plataforma). Establecer un método para la autenticación de los usuarios: Actualmente el sistema ha sido diseñado bajo la premisa de que cada usuario utiliza una identificación única. Antes de poder aplicar el producto en entornos reales sería necesario habilitar mecanismos que permitan la obtención de dicho identificador tras un proceso de autenticación del usuario. Ampliar el soporte de fuentes de vídeo: El sistema ha sido diseñado para trabajar con cámaras IP. No obstante, sería interesante ampliar la funcionalidad del mismo con objeto de soportar cámaras USB, así como ampliar el soporte de codecs de vídeo. 140

173 Bibliografía [1] OBJECT MANAGEMENTT GROUP (2007): Data distribution service for Real-Time Systems. Version 1.2 Disponible en: [2] OBJECT MANAGEMENT GROUP (2008): Object Management Group. Disponible en: [3] CLICK TO MEET (2008): Click to meet platform Disponible en: [4] ISABEL (2008): Isabel Plaza Home. Disponible en: [5] CONNECTA 2000 (2008): Connecta Videoconferencia Peer-to-peer [6] MICROSOFT OFFICE COMMUNICATION SERVER (2008): Página principal de Office Communications server Microsoft Office Online. Disponible en: [7] DATA ORIENTED (2008): Data-Oriented Architecture. Disponible en: [8] AXIS (2008): Axis Communications. Disponible en: [9] REAL-TIME INNOVATIONS (2008): The Real-Time Middleware Experts. Disponible en: [10] ECLIPSE (2008): Eclipse.org home. Disponible en: [11] JSPEEX (2008): Jspeex Java implementation of Speex. Disponible en: [12] ANKENEY, J. (2006): Technology Showcase: Videoconferencing Room Systems. SVC [revista electrónica]. Disponible en: 141

174 Plataforma de Trabajo Colaborativo sobre Middleware DDS [13] AHMED, N.; NATARAJAN, T.; RAO, K.R. (1974): Discrete Cosine Transform. IEEE Trans. Computers, pp [14] COMPRESSION LABS INC (1996): COMPRESSION LABS INC Annual Report. Disponible en: /Section2.asp [15] COX, J. J. (2007): Background and history of Videoconferencing. Content for reprint [revista electrónica]. Disponible en: [16] DORCEY, T. (1995): CU-SeeMe Desktop Video Conferencing Software. Connexions, 9 (3). Disponible en: [17] RADVISION (2006): Click to meet. Disponible en: [18] RADVISION (2008): RADVISION Delivering the visual experience. Disponible en: [19] QUEMADA, J.; DE MIGUEL, T.; PAVON, S; HUECAS, G.; et al (2005): Isabel: an application for real time collaboration with a flexible floor control. ColCom, 19 (21): 9pp. Disponible en: [20] SPEEX (2008): Speex: a free códec for free speech Disponible en: [21] CORBA (2008): Welcome to the OMG s CORBA website. Disponible en: [22] THALES (2008): Thales Group, information systems serving Aerospace, Defence and Security Markets. Disponible en: [23] PARDO-CASTELLOTE, G. (2005): OMG Data distribution service: Real-Time publish/subscribe becomes a standar RTC, 14. Disponible en: [24] PRISMTECH (2008): OpenSplice DDS Data distribution service overview middleware. Disponible en: [25] TWIN OAKS COMPUTING, INC. (2008): High performance communications software. Disponible en: [26] OBJECT COMPUTING, INC. (2008): OCI-Products-OpenDDS-Object Computing, Inc. Disponible en: 142

175 Bibliografía [27] MILSOFT (2008): Milsoft DDS Middleware. Disponible en: [28] OBJECT MANAGEMENTT GROUP (2007): Data Distribution RTF 2 DCPS IDL. Disponible en: [29] PARDO CASTELLOTE, G. (2008): Introduction to middleware systems Seminario realizado en el marco del máster Sistemas Multimedia durante los días 10 y 11 de Enero de 2008 de la Universidad de Granada. [30] KRAKOWIAK, S. (2003): What is middleware. Disponible en: [31] NATO SCIENCE COMMITTEE (1969): Software Engineering Disponible en: [32] PARDO CASTELLOTE, G. (2007): Analysis of the Advanced Message Queuing Protocol (AMQP) and comparison with the Real-Time Publish Subscribe Protocol (DDS-RTPS Interoperability Protocol) Real-time And Embedded Systems Workshop. Disponible en: [33] DCE/RPC (2008): Free DCE License and Download. Disponible en: [34] DCOM (1996): DCOM Technical Overview. Disponible en: [35] HENNING, M.; SPRUIELL, M. (2008): Distributed Programing with Ice. Disponible en: [36] TIBCO (2008): TIBCO. Service Oriented Architecture (SOA) Software, Business Process Management (BPM) Software Leader. Disponible en [37] 29WEST (2008): 29West. Home. Disponible en [38] JMS (2008): Java Message Service (JMS). Disponible en [39] MQ SERIES (2008): Welcome to MQSeries.net Serving IBM WebSphere MQ Professionals Worldwide. Disponible en [40] GIGASPACES (2008): GigaSpaces extreme Application Platform (XAP). GigaSpaces. Disponible en: [41] RTI DDS (2008): RTI Data Distribution Service. Disponible en: [42] PARDO-CASTELLOTE, G. (2003): OMG Data-Distribution Service: architectural overview. Disponible en: 143

176 Plataforma de Trabajo Colaborativo sobre Middleware DDS hitectural_overview.pdf [43] WATINE, V. (2004): Data Distribution Service DLRL Real-time and Embedded Systems Workshop. Disponible en: [44] OBJECT MANAGEMENTT GROUP (2007): Data Distribution RTF 2 DLRL IDL. Disponible en: [45] SIERLA, S.; PELTOLA, J.; KOSKINEN, K. (2003): Evaluation of a Real-Time Distribution Service. Disponible en: [46] SCHNEIDER, S. (2006): Data-centric pervasive information is the wave of the future Rf design. Disponible en: [47] CORSARO, A.; QUERZONI, l..; SCIPIONI, S.; TUCCI, S.; et al (2006): Quality of Service in Publish/Subscribe Middleware. Disponible en: [48] SCHNEIDER, S. (2008): Meeting Real-Time requirements in networked systems. Disponible en: [49] HUANG, C.; HOBSON P. R.; TAYLOR, G. A.; KYBERD, P. (2007): A Study of Publish/Subscribe Systems for Real-Time Grid Monitoring PDPS, 26(30): pp [50] BULUT, H.; FOX, G.; PALLICKARA, S.; UYAR, A.; et al. (2002): Integration of NaradaBrokering and Audio/Video Conferencing as a Web Service. Disponible en: [51] OMG IDL (2008): OMG IDL. Disponible en: [52] OMG IDL ESTÁNDAR ISO (2008): ISO International Organization for Standardization. Disponible en: [53] OMG IDL (2002): OMG IDL Syntax and Semantics. Disponible en: [54] PARDO-CASTELLOTE, G. (2004): Data Distribution Service (DDS) and the RTPS protocol. Disponible en: [55] RTI (2008): RTI Data User s Manual. Disponible en: [56] API VAPIX (2008): Axis Communications Network Camera Developer pages. Disponible en: 144

177 Bibliografía [57] ITU-T (1993): General aspects of digital transmission systems. Disponible en: E&type=items [58] XML Schema Working Group (2008): W3C XML Schema. Disponible en: [59] WEN, H. (2008): Java solutions profile: Java web conferencing. Disponible en: javawebconferencing_profile.html?page=1 [60] JMF (2008): Java SE Desktop Technologies Java Media Framework API (JMF). Disponible en: [61] JAVA SOUND (2008): Java Sound API. Disponible en: [62] BOMERS, F.; PFISTERER, M. (2004): The Java Sound Internet Phone Java One. Disponible en: [63] VORBIS (2008): Vorbis.com. Disponible en: [64] CELP (2008): CELP 3.2ª & LPC-10. Disponible en: [65] Contenedor ogg [66] SPEEX MANUAL (2008): Formats and standards. Disponible en: [67] NASA (2008): COCOMO Software Cost Model. Disponible en: [68] REAL TIME INNOVATIONS (2008): RTI The Real-Time Middleware Company University Progam. Disponible en: [69] USC-CSE1 (2008): CSSE Website. Disponible en: [70] IRUS (2008): Irvine Research Unit in Software (IRUS). Disponible en: [71] COCOMO II (2008): CSSE Website. Disponible en: [72] USC (2008): USC Expert COCOMO II. Disponible en: 145

178 Plataforma de Trabajo Colaborativo sobre Middleware DDS [73] OMG (2008): Workshop on Distributed Object Computing for Real-time and Embedded systems. Disponible en: 146

179 Anexo A. Manual de usuario A.1 Instalación Aunque la aplicación aquí presentada no requiere de instalación, para su correcto funcionamiento es necesario resolver algunas dependencias. A.1.1 Dependencias En primer lugar, esta aplicación requiere que el servicio de distribución de datos NDDS 4.2e esté instalado en el sistema. Además, se recomienda añadir la librería jspeexnoogg.jar (incluida en el paquete) para poder intercambiar audio sobre SPEEX. Aunque esta librería está basada en JSPEEX, presenta ciertas modificaciones sin las cuales la aplicación no funcionará correctamente, por lo que se recomienda que en caso de tener JSPEEX ya instalado, se sustituya por la versión aquí incluida. Por último, se requiere la máquina virtual de Java para la ejecución del programa. A.2 Ejecución Una vez NDDS 4.2e se encuentre instalado en el sistema, y la librería jspeexnoogg.jar añadida a CLASSPATH, se podrá iniciar el sistema mediante la siguiente orden (ejecutada desde la carpeta de instalación de la aplicación): java client.main.clientmain A.3 Descripción de la interfaz de usuario La interfaz de usuario de la aplicación cuenta con dos ventanas principales: Ventana de creación/descubrimiento de salas Ventana de sala En este apartado se describirán los principales elementos de ambas ventanas. 147

180 Plataforma de Trabajo Colaborativo sobre Middleware DDS A.3.1 Ventana de creación/descubrimiento de salas En la figura A.1 muestra la ventana de creación/descubrimiento de salas. Dicha ventana se divide en dos secciones, una destinada a crear salas (públicas o privadas) y la otra a la búsqueda de salas ya creadas. Figura A.1 Ventana creación/descubrimiento de salas La primera sección (ver figura A.1), está dividida en los siguientes bloques: Nombre de sala: Permite configurar el nombre de la sala que se creará Usuarios permitidos: Gracias a este bloque, es posible definir qué usuarios tendrán acceso a la sala creada. Si no se define ningún usuario, la sala será pública. Botón crear sala: Una vez pulsado, se aplicará la configuración elegida y se creará la sala. Datos de usuario: Permiten definir un alias. En ID se deberá introducir la identificación de usuario. La identificación es un número único que identifica a un usuario en el sistema. Si dicho número es usado por más de un usuario a la vez, el sistema podría no comportarse de forma esperada. En la figura A.2 se presentan la interfaz de la segunda sección, buscar salas. 148

181 Anexo A. Manual de Usuario Figura A.2 Sección buscar salas En esta sección de la interfaz el usuario puede buscar las salas que se encuentran ya creadas. Cuenta con un panel en el que se visualizarán las salas descubiertas y con un botón para buscar salas. A.3.2 Ventana de sala La segunda ventana que constituye la interfaz de usuario es la conocida como ventana de sala. Esta ventana permite al usuario intercambiar vídeo, audio o mensajes de texto con otros usuarios que se conecten a la misma sala. La interfaz se puede observar en la figura A.3. Los elementos que constituyen esta parte de la interfaz son: Panel principal de chat: Situado a la izquierda, a través de él se podrán visualizar los mensajes de texto enviados por otros usuarios de la sala, así como los mensajes de información del sistema. Panel de introducción de texto: Localizado en la parte inferior del panel principal de chat, será utilizado para enviar mensajes. Panel de usuarios: Situado a la derecha de la ventana, muestra información sobre los usuarios conectados a la sala y su estado. De este modo, se muestra información sobre los recursos que están publicando y si tiene el control del canal de audio o desean utilizarlo. 149

182 Plataforma de Trabajo Colaborativo sobre Middleware DDS Controles de publicación/subscripción: Los botones situados en la parte inferior izquierda de la ventana permiten al usuario iniciar o detener la publicación o subscripción de audio y/o vídeo. Finalmente, los controles de la parte inferior derecha permiten solicitar el canal de audio y/o conceder la palabra. Figura A.3 Ventana de sala A.4 Ejemplos de funcionamiento Para acabar este manual de usuario, se presentan algunos ejemplos de funcionamiento del sistema. A.4.1 Ejemplos: intercambio de vídeo en sala pública 150

183 Anexo A. Manual de Usuario En primer lugar, creamos una sala pública (no añadimos usuarios a la lista). Para saber si efectivamente la sala será pública, basta con comprobar que el icono mostrado en la pestaña crear sala, representa una bola del mundo. Figura A.4 Creación de sala pública Una vez se crea una sala pública, si otro usuario busca las salas, descubrirá la sala recién creada: Figura A.5 Localización de sala pública Para acceder a una sala creada, basta con clickar en el icono correspondiente (en este caso, una bola del mundo, pues la sala es de tipo publico). Una vez entramos en la sala, podemos publicar vídeo. 151

184 Plataforma de Trabajo Colaborativo sobre Middleware DDS Figura A.6 Inicio de publicación de vídeo O subscribirnos al mismo, con lo que se despliega el panel de visualización de vídeo. Figura A.7 Inicio de subscripción a vídeo 152

185 Anexo A. Manual de Usuario En la figura A.7, se puede observar que la calidad de la señal de vídeo es muy baja. Posiblemente esto se deba una sobrecarga de la red o del sistema. Si la situación mejora, el sistema incrementará la calidad de la señal de forma automática (ver figura A.8). Figura A.8 Subscripción a vídeo A.4.2 Ejemplos: intercambio de audio en sala privada En primer lugar, creamos una sala privada, añadiendo la identificación de los usuarios que deseamos tengan acceso a la sala. Figura A.9 Creación de sala privada 153

186 Plataforma de Trabajo Colaborativo sobre Middleware DDS Al acceder a la sala, observamos que se muestran los usuarios permitidos. Figura A.10 Usuarios con permiso de acceso a la sala Si a continuación el usuario identificado como 101 inicia la búsqueda de salas, obtiene la lista mostrada en la figura A.11. Figura A.11 Descubrimiento de salas privadas Como vemos, ha descubierto la sala pública que creamos en el anterior apartado, pero también la sala privada. Si el usuario no estuviera en la lista de usuarios con acceso a la sala, simplemente no la descubrirá. Ahora, centrémonos en la gestión de audio. Cuando un usuario crea una sala, se convierte en el moderador de la misma. De este modo, puede moderar el canal de audio, decidiendo quién tiene la palabra en cada momento. 154

187 Anexo A. Manual de Usuario Figura A.12 Diferentes estados para los usuarios de la sala En las figuras A.12 y A.13 se ilustran los posibles estados de los usuarios cuando intercambian audio: Icono azul: El usuario es el dueño del canal de audio Icono amarillo: El usuario desea hablar. El moderador podrá cederle la palabra seleccionando su nombre y pulsando el botón de asignación del canal. Icono verde: Usuario conectado, pero no tiene la palabra ni ha solicitado el canal. Figura A.13 Información de estado de usuario 155