estudios de ingenierÍa de telecomunicaciÓn

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

ESTUDIOS DE INGENIERÍA DE TELECOMUNICACIÓN



REALIZADO POR:


DIRIGIDO POR:

Juan Manuel López Soler

DEPARTAMENTO:

Teoría de la Señal, Telemática y Comunicaciones

Granada, Octubre de 2008




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-to-much 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.

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.

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.


José María López Vega DNI: 75.151.836 A

Juan Manuel López Soler DNI: 29.078.207 C

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 10000 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.

A mis padres, a Adela.

Porque este proyecto es más vuestro que mío.

I

Índice general

CAPÍTULO 0. INTRODUCCIÓN .......................................................... 1

0.1 DEFINICIÓN DEL PROBLEMA ................................................................................................. 1

0.2 OBJETIVOS .................................................................................................................................... 2

0.3 RECURSOS ..................................................................................................................................... 2

0.3.1 HUMANOS ................................................................................................................................................................ 2 0.3.2 HARDWARE.............................................................................................................................................................. 2 0.3.3 SOFTWARE ............................................................................................................................................................... 3

0.4 FASES DE DESARROLLO ............................................................................................................ 3

0.5 RESTRICCIONES ......................................................................................................................... 4

0.5.1 FACTORES DATO ..................................................................................................................................................... 4 0.5.2 FACTORES ESTRATÉGICOS .................................................................................................................................... 4

0.6 ANTECEDENTES Y ESTADO DEL ARTE ................................................................................ 5

0.6.1 ANTECEDENTES EN PLATAFORMAS VIDEOCONFERENCIA............................................................................. 5 0.6.2 ESTADO DEL ARTE EN PLATAFORMAS DE VIDEOCONFERENCIA .................................................................. 6 0.6.3 ANTECEDENTES EN MIDDLEWARE DDS.......................................................................................................... 9 0.6.4 ESTADO DEL ARTE EN DISTRIBUCIÓN DE DATOS CON DDS ...................................................................... 10

0.7 APROXIMACIÓN A LA SOLUCIÓN PROPUESTA .................................................................. 10

0.7.1 CONCEPTOS BÁSICOS .......................................................................................................................................... 10 0.7.2 ARQUITECTURA PROPUESTA ............................................................................................................................. 11

Descubrimiento de las salas........................................................................................................................................... 12 Moderación del canal de audio. Figura del moderador ................................................................................................... 13

0.8 PRINCIPALES APORTACIONES DEL PROYECTO Y CONCLUSIONES............................ 13

0.8.1 SUBAPARTADO ...................................................................................................................................................... 13

0.9 ESTRUCTURA DE LA MEMORIA ............................................................................................ 13

CAPÍTULO 1. INTRODUCCIÓN A DDS ............................................ 15

Plataforma de Trabajo Colaborativo sobre Middleware DDS

II

1.1 NOCIONES BÁSICAS .................................................................................................................. 15

1.1.1 ¿QUÉ ES EL MIDDLEWARE? ................................................................................................................................ 15 1.1.2 MODELOS DE COMUNICACIÓN ......................................................................................................................... 16 1.1.3 ¿QUÉ ES DDS? ..................................................................................................................................................... 18 1.1.4 ¿QUÉ ES RTI DDS? ............................................................................................................................................. 18

Características de RTI Data Distribution Service ......................................................................................................... 19

1.2 COMUNICACIONES PUBLICACIÓN-SUBSCRIPCIÓN CENTRADAS EN DATOS ........... 19

1.2.1 ¿QUÉ ES DCPS? ................................................................................................................................................... 19 DCPS con Requerimientos de Tiempo Real .................................................................................................................. 20

1.2.2 TERMINOLOGÍA Y CONCEPTOS ADICIONALES ............................................................................................... 22 Tipos de datos ............................................................................................................................................................... 22 Entidades DCPS ......................................................................................................................................................... 22 Muestras, instancias y claves ......................................................................................................................................... 23 Dominios y DomainParticipants ................................................................................................................................... 23

1.2.3 CALIDAD DE SERVICIO (QOS) ........................................................................................................................... 24 1.2.4 DESCUBRIMIENTO DE APLICACIONES ............................................................................................................. 24

1.3 CONCLUSIONES ........................................................................................................................ 25

CAPÍTULO 2. POLÍTICAS QOS EN DDS .......................................... 27

2.1 CONTROL DE LAS COMUNICACIONES MEDIANTE POLÍTICAS DE QOS .................... 27

2.2 POLÍTICAS QOS ADECUADAS PARA AUDIO/VÍDEO [55] .................................................. 28

2.2.1 POLÍTICA DEADLINE ...................................................................................................................................... 30 Propiedades ................................................................................................................................................................... 31 Utilidad para transmisión de audio y vídeo ................................................................................................................... 31

2.2.2 POLÍTICA LIFESPAN ......................................................................................................................................... 31 Propiedades ................................................................................................................................................................... 32 Utilidad para transmisión de audio y vídeo ................................................................................................................... 32

2.2.3 POLÍTICA LIVELINESS..................................................................................................................................... 32 Propiedades ................................................................................................................................................................... 34 Consideraciones adicionales ........................................................................................................................................... 34 Utilidad para Transmisión de Audio y Vídeo .............................................................................................................. 34

2.2.4 POLÍTICA OWNERSHIP ................................................................................................................................... 34 Cómo se selecciona qué DataWriter es el “dueño” de la instancia ................................................................................. 35 Propiedades ................................................................................................................................................................... 36 Utilidad para transmisión de audio y vídeo ................................................................................................................... 36

2.2.5 POLÍTICA OWNERSHIP_STRENGTH ........................................................................................................ 36 Propiedades ................................................................................................................................................................... 36 Utilidad para transmisión de audio y vídeo ................................................................................................................... 36

2.2.6 POLÍTICA PRESENTATION ........................................................................................................................... 37 Acceso coherente ............................................................................................................................................................ 38 Acceso ordenado ............................................................................................................................................................ 38 Propiedades ................................................................................................................................................................... 39 Utilidad para transmisión de audio y vídeo ................................................................................................................... 40

2.2.7 POLÍTICA TIME_BASED_FILTER ................................................................................................................ 40 Propiedades ................................................................................................................................................................... 41

Índice general

III

Utilidad para transmisión de audio y vídeo ................................................................................................................... 41

2.3 CONCLUSIONES ........................................................................................................................ 42

CAPÍTULO 3. MODELADO DE REQUISITOS ................................. 43

3.1 REQUISITOS FUNCIONALES .................................................................................................. 44

3.1.1 CLIENT.MAIN ........................................................................................................................................................ 44 Definición de actores: .................................................................................................................................................... 44 Identificación de casos de uso por actores: ....................................................................................................................... 44 Descripción de casos de uso:........................................................................................................................................... 45 Diagrama de Casos de Uso: ......................................................................................................................................... 53

3.1.2 CLIENT.AUDIOPACKET ....................................................................................................................................... 55 Definición de actores: .................................................................................................................................................... 55 Identificación de casos de uso por actores: ....................................................................................................................... 55 Descripción de casos de uso:........................................................................................................................................... 55 Diagrama de Casos de Uso: ......................................................................................................................................... 58

3.1.3 COMMUNICATIONDDS.VIDEOFRAME ............................................................................................................. 59 Definición de actores: .................................................................................................................................................... 59 Identificación de casos de uso por actores: ....................................................................................................................... 60 Descripción de casos de uso:........................................................................................................................................... 60 Diagrama de Casos de Uso: ......................................................................................................................................... 66

3.1.4 COMMUNICATIONDDS.AUDIOPACKET .......................................................................................................... 67 Definición de actores: .................................................................................................................................................... 67 Identificación de casos de uso por actores: ....................................................................................................................... 68 Descripción de casos de uso:........................................................................................................................................... 68 Diagrama de Casos de Uso: ......................................................................................................................................... 72

3.1.5 COMMUNICATIONDDS.SIGNALING ................................................................................................................. 73 Definición de actores: .................................................................................................................................................... 73 Identificación de casos de uso por actores: ....................................................................................................................... 73 Descripción de casos de uso:........................................................................................................................................... 73 Diagrama de Casos de Uso: ......................................................................................................................................... 76

3.1.6 COMMUNICATIONDDS.MESSENGER................................................................................................................ 77 Definición de actores: .................................................................................................................................................... 77 Identificación de casos de uso por actores: ....................................................................................................................... 78 Descripción de casos de uso:........................................................................................................................................... 78 Diagrama de Casos de Uso: ......................................................................................................................................... 81

3.1.7 COMMUNICATIONIPCAMERA ............................................................................................................................ 82 Definición de actores: .................................................................................................................................................... 82 Identificación de casos de uso por actores: ....................................................................................................................... 83 Descripción de casos de uso:........................................................................................................................................... 83 Diagrama de Casos de Uso: ......................................................................................................................................... 85

3.2 REQUISITOS NO FUNCIONALES ........................................................................................... 86

3.2.1 COMUNES A TODOS LOS SUBSISTEMAS ............................................................................................................ 86 Implementación ............................................................................................................................................................. 86 Interfaz ........................................................................................................................................................................ 86 Facilidad de Uso .......................................................................................................................................................... 86 Fiabilidad .................................................................................................................................................................... 86


IV

Operaciones ................................................................................................................................................................... 87 Rendimiento .................................................................................................................................................................. 87 Soporte .......................................................................................................................................................................... 87 Empaquetamiento ......................................................................................................................................................... 87

3.2.2 ESPECÍFICOS DE CLIENT.AUDIOPACKET ......................................................................................................... 87 Implementación ............................................................................................................................................................. 87

3.2.3 ESPECÍFICOS DE COMMUNICATIONIPCAMERA .............................................................................................. 87 Implementación ............................................................................................................................................................. 87 Interfaz ......................................................................................................................................................................... 87 Fiabilidad ..................................................................................................................................................................... 87 Operaciones ................................................................................................................................................................... 88

3.3 CONCLUSIONES ........................................................................................................................ 88

CAPÍTULO 4. DISEÑO ......................................................................... 89

4.1 DIAGRAMA DE PAQUETES ...................................................................................................... 89

4.2 POLÍTICAS DE CALIDAD DE SERVICIO INCORPORADAS AL SISTEMA ......................... 90

4.2.1 POLÍTICAS DEADLINE Y TIME_BASED_FILTER .................................................................................. 90 4.2.2 POLÍTICA LIVELINESS..................................................................................................................................... 91 4.2.3 POLÍTICA PRESENTATION ........................................................................................................................... 91 4.2.4 POLÍTICA LIFESPAN ......................................................................................................................................... 92 4.2.5 POLÍTICA OWNERSHIP Y OWNERSHIP_STRENGTH ......................................................................... 92

4.3 DIAGRAMAS DE CLASES .......................................................................................................... 92

4.3.1 PAQUETE CLIENT.MAIN ...................................................................................................................................... 92 4.3.2 PAQUETE CLIENT.AUDIOPACKET..................................................................................................................... 93 4.3.3 PAQUETE COMMUNICATIONDDS.VIDEOFRAME .......................................................................................... 94 4.3.4 PAQUETE COMMUNICATIONDDS.AUDIOPACKET ........................................................................................ 95 4.3.5 PAQUETE COMMUNICATIONDDS.SIGNALING ............................................................................................... 96 4.3.6 PAQUETE COMMUNICATIONDDS.MESSENGER ............................................................................................. 97 4.3.7 PAQUETE COMMUNICATIONIPCAMERA.......................................................................................................... 98

4.4 DIAGRAMAS DE SECUENCIA .................................................................................................. 99

4.4.1 SUBSISTEMA CLIENT.MAIN ................................................................................................................................. 99 Iniciar/cerrar sistema .................................................................................................................................................... 99 Buscar salas ................................................................................................................................................................ 100 Unirse a sala .............................................................................................................................................................. 100 Abandonar sala .......................................................................................................................................................... 101 Notificar problemas en vídeo ....................................................................................................................................... 102

4.4.2 SUBSISTEMA CLIENT.AUDIOPACKET .............................................................................................................. 103 Iniciar/finalizar captura ............................................................................................................................................. 103 Iniciar/finalizar reproducción ..................................................................................................................................... 103 Cambiar audio OWNERSHIP ................................................................................................................................ 104 Publicar/reproducir paquete de audio .......................................................................................................................... 104

4.4.3 SUBSISTEMA COMMUNICATIONDDS.VIDEOFRAME .................................................................................... 105 Iniciar/terminar subscripción ...................................................................................................................................... 105 Iniciar/terminar publicación ....................................................................................................................................... 106 Publicar/recibir VideoFrame ..................................................................................................................................... 107

Índice general

V

Notificar expiración de DW DEADLINE ............................................................................................................. 108 Notificar expiración de DR DEADLINE .............................................................................................................. 108 Notificar cambio en LIVELINESS ........................................................................................................................ 109 Comprobar estado de DW DEADLINE ............................................................................................................... 109 Comprobar estado de DR DEADLINE ................................................................................................................. 110

4.4.4 SUBSISTEMA COMMUNICATIONDDS.AUDIOPACKET ................................................................................. 110 Iniciar/terminar subscripción ...................................................................................................................................... 111 Iniciar/terminar publicación ....................................................................................................................................... 111 Publicar/recibir AudioPacket .................................................................................................................................... 112 Cambiar OWNERSHIP ......................................................................................................................................... 113 Notificar cambio en LIVELINESS ........................................................................................................................ 113

4.4.5 SUBSISTEMA COMMUNICATIONDDS.SIGNALING ........................................................................................ 113 Iniciar/terminar subscripción ...................................................................................................................................... 114 Iniciar/terminar publicación ....................................................................................................................................... 114 Publicar/recibir SessionSignaling ................................................................................................................................ 115 Notificar cambio en LIVELINESS ........................................................................................................................ 115

4.4.6 SUBSISTEMA COMMUNICATIONDDS.MESSENGER ...................................................................................... 116 Iniciar/terminar subscripción ...................................................................................................................................... 116 Iniciar/terminar publicación ....................................................................................................................................... 117 Publicar/recibir ImMessage ........................................................................................................................................ 118 Notificar cambio en LIVELINESS ........................................................................................................................ 119

4.4.7 SUBSISTEMA COMMUNICATIONIPCAMERA ................................................................................................... 119 Conectar/desconectar sistema ...................................................................................................................................... 119 Cambiar calidad ......................................................................................................................................................... 120 Publicar frame de vídeo ............................................................................................................................................... 121

4.5 CONCLUSIONES ....................................................................................................................... 121

CAPÍTULO 5. IMPLEMENTACIÓN ................................................ 123

5.1 DESCRIPCIÓN IDL DE LOS TIPOS DE DATOS INTERCAMBIADOS .............................. 123

5.1.1 VIDEOFRAME ..................................................................................................................................................... 123 5.1.2 AUDIOPACKET................................................................................................................................................... 124 5.1.3 SESSIONSIGNALING .......................................................................................................................................... 124 5.1.4 IMMESSAGE ........................................................................................................................................................ 125

5.2 HERRAMIENTA RTIDDSGEN ............................................................................................... 125

5.3 COMUNICACIÓN CON CÁMARA IP ..................................................................................... 126

5.3.1 COMUNICACIÓN CON CÁMARA IP AXIS 207W. VAPIX®. ....................................................................... 126 5.3.2 ARCHIVO XML DE CONFIGURACIÓN DE CÁMARA IP ................................................................................ 127

5.4 GESTIÓN DE AUDIO ............................................................................................................... 129

5.4.1 INTEGRACIÓN EN EL SISTEMA. CODEC DE AUDIO SPEEX. JSPEEX. .................................................... 130 Codec de audio SPEEX ............................................................................................................................................ 130 Librería JSPEEX..................................................................................................................................................... 131

5.5 CONCLUSIONES ....................................................................................................................... 131

CAPÍTULO 6. ESTIMACIÓN DE COSTES ...................................... 133


VI

6.1 TAREAS Y TEMPORIZACIÓN ................................................................................................. 133

6.2 COSTES ....................................................................................................................................... 133

6.2.1 INFRAESTRUCTURAS .......................................................................................................................................... 134 6.2.2 ESFUERZO DE DESARROLLO DEL SISTEMA ................................................................................................... 134

6.3 CONCLUSIONES ....................................................................................................................... 137

CAPÍTULO 7. RESULTADOS Y TRABAJO FUTURO .................... 139

7.1 PRINCIPALES CONTRIBUCIONES DEL PROYECTO ........................................................ 139

7.2 TRABAJO FUTURO ................................................................................................................... 140

BIBLIOGRAFÍA ................................................................................... 141

ANEXO A .............................................................................................. 147

VII

Í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 CONNECTA2000 ........................................................................................... 8 FIGURA 0.6 INTEROPERABILIDAD OFFICE COMMUNICATION SERVER Y PBX ......................................................... 9 FIGURA 0.7 ARQUITECTURA PROPUESTA ...................................................................................................................... 12

CAPÍTULO 1. INTRODUCCIÓN A DDS

FIGURA 1.1 SITUACIÓN DE LA CAPA MIDDLEWARE SOBRE LA PILA DE PROTOCOLOS DE RED ........................... 16 FIGURA 1.2 MODELOS DE COMUNICACIÓN .................................................................................................................. 17 FIGURA 1.3 ENTIDADES DCPS [42]................................................................................................................................ 22 FIGURA 1.4 COMUNICACIÓN A TRAVÉS DE TÓPICOS................................................................................................... 23

CAPÍTULO 2. POLÍTICAS QOS EN DDS

FIGURA 2.1 RELACIÓN ENTRE MINIMUM_SEPARATION Y DEADLINE ................................................................. 41

CAPÍTULO 3. MODELADO DE REQUISITOS

FIGURA 3.1 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA CLIENT.MAIN .................................................... 54 FIGURA 3.2 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA CLIENT.AUDIOPACKET ................................... 59 FIGURA 3.3 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA COMMUNICATIONDDS.VIDEOFRAME ......... 67 FIGURA 3.4 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA COMMUNICATIONDDS.AUDIOPACKET ...... 72 FIGURA 3.5 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA COMMUNICATIONDDS.SIGNALING ............. 77 FIGURA 3.6 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA COMMUNICATIONDDS.MESSENGER ............ 82 FIGURA 3.7 DIAGRAMA DE CASOS DE USO PARA EL SUBSISTEMA

COMMUNICATIONDDS.COMMUNICATIONIPCAMERA ..................................................................................... 86


VIII

CAPÍTULO 4. DISEÑO

FIGURA 4.1 DIAGRAMA DE PAQUETES ........................................................................................................................... 90 FIGURA 4.2 PAQUETE CLIENT.MAIN ............................................................................................................................... 93 FIGURA 4.3 PAQUETE CLIENT.AUDIOPACKET .............................................................................................................. 94 FIGURA 4.4 PAQUETE COMMUNICATIONDDS.VIDEOFRAME ................................................................................... 95 FIGURA 4.5 PAQUETE COMMUNICATIONDDS.AUDIOPACKET ................................................................................. 96 FIGURA 4.6 PAQUETE COMMUNICATIONDDS.SIGNALING ........................................................................................ 97 FIGURA 4.7 PAQUETE COMMUNICATIONDDS.MESSENGER ...................................................................................... 98 FIGURA 4.8 PAQUETE COMMUNICATIONIPCAMERA ................................................................................................... 99 FIGURA 4.9 DIAGRAMA DE SECUENCIA “INICIAR/CERRAR SISTEMA” ..................................................................... 99 FIGURA 4.10 DIAGRAMA DE SECUENCIA “BUSCAR SALAS” ...................................................................................... 100 FIGURA 4.11 DIAGRAMA DE SECUENCIA “UNIRSE A SALA” ..................................................................................... 101 FIGURA 4.12 DIAGRAMA DE SECUENCIA “ABANDONAR SALA” .............................................................................. 102 FIGURA 4.13 DIAGRAMA DE SECUENCIA “NOTIFICAR PROBLEMAS VÍDEO” ........................................................ 102 FIGURA 4.14 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR CAPTURA” ........................................................... 103 FIGURA 4.15 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR REPRODUCCIÓN” .............................................. 104 FIGURA 4.16 DIAGRAMA DE SECUENCIA “CAMBIAR AUDIO OWNERSHIP” ...................................................... 104 FIGURA 4.17 DIAGRAMA DE SECUENCIA “PUBLICAR/REPRODUCIR PAQUETE DE AUDIO” ............................... 105 FIGURA 4.18 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR SUBSCRIPCIÓN”.................................................. 106 FIGURA 4.19 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR PUBLICACIÓN” ................................................... 107 FIGURA 4.20 DIAGRAMA DE SECUENCIA “PUBLICAR/RECIBIR VIDEOFRAME” ................................................... 108 FIGURA 4.21 DIAGRAMA DE SECUENCIA “NOTIFICAR EXPIRACIÓN DE DW DEADLINE” ............................ 108 FIGURA 4.22 DIAGRAMA DE SECUENCIA “NOTIFICAR EXPIRACIÓN DE DR DEADLINE” ............................. 109 FIGURA 4.23 DIAGRAMA DE SECUENCIA “NOTIFICAR CAMBIO EN LIVELINESS” ........................................... 109 FIGURA 4.24 DIAGRAMA DE SECUENCIA “COMPROBAR ESTADO DE DW DEADLINE” ................................. 110 FIGURA 4.25 DIAGRAMA DE SECUENCIA “COMPROBAR ESTADO DE DR DEADLINE” .................................. 110 FIGURA 4.26 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR SUBSCRIPCIÓN”.................................................. 111 FIGURA 4.27 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR PUBLICACIÓN” ................................................... 112 FIGURA 4.28 DIAGRAMA DE SECUENCIA “PUBLICAR/RECIBIR AUDIO PACKET” ................................................ 112 FIGURA 4.29 DIAGRAMA DE SECUENCIA “CAMBIAR OWNERSHIP” ................................................................... 113 FIGURA 4.30 DIAGRAMA DE SECUENCIA “NOTIFICAR CAMBIO EN LIVELINESS” ........................................... 113 FIGURA 4.31 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR SUBSCRIPCIÓN” ................................................. 114 FIGURA 4.32 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR PUBLICACIÓN” ................................................... 115 FIGURA 4.33 DIAGRAMA DE SECUENCIA “PUBLICAR/RECIBIR SESSIONSIGNALING” ........................................ 115 FIGURA 4.34 DIAGRAMA DE SECUENCIA “NOTIFICAR CAMBIO EN LIVELINESS” ........................................... 116 FIGURA 4.35 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR SUBSCRIPCIÓN”.................................................. 117 FIGURA 4.36 DIAGRAMA DE SECUENCIA “INICIAR/TERMINAR PUBLICACIÓN” ................................................... 118 FIGURA 4.37 DIAGRAMA DE SECUENCIA “PUBLICAR/RECIBIR IMMESSAGE” ...................................................... 118 FIGURA 4.38 DIAGRAMA DE SECUENCIA “NOTIFICAR CAMBIO EN LIVELINESS” ........................................... 119 FIGURA 4.39 DIAGRAMA DE SECUENCIA “CONECTAR/DESCONECTAR SISTEMA” .............................................. 120 FIGURA 4.40 DIAGRAMA DE SECUENCIA “CAMBIAR CALIDAD” .............................................................................. 121 FIGURA 4.41 DIAGRAMA DE SECUENCIA “PUBLICAR FRAME DE VÍDEO” ............................................................. 121

ANEXO A. MANUAL DE USUARIO

FIGURA A.1 VENTANA CREACIÓN/DESCUBRIMIENTO DE SALAS ............................................................................... 148 FIGURA A.2 SECCIÓN “BUSCAR SALAS” ............................................................................................................................ 149 FIGURA A.3 VENTANA DE SALA ........................................................................................................................................ 150

Índice de figuras

IX

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


X

XI

Í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 ....................................................... 29

TABLA 2.2 POLÍTICA DEADLINE........................................................................................................................ 30

TABLA 2.3 POLÍTICA LIFESPAN ......................................................................................................................... 32

TABLA 2.4 POLÍTICA LIVELINESS ...................................................................................................................... 33

TABLA 2.5 COMBINACIONES PERMITIDAS PARA LA POLÍTICA LIVELINESS .................................................................. 34

TABLA 2.6 POLÍTICA OWNERSHIP .................................................................................................................... 35

TABLA 2.7 POLÍTICA OWNERSHIP_STRENGTH ................................................................................................ 36

TABLA 2.8 POLÍTICA PRESENTATION ............................................................................................................... 37

TABLA 2.9 EFECTO DE LA CONFIGURACIÓN ACCESO ORDENADO SOBRE LA QOS PRESENTATION .................................. 39

TABLA 2.10 COMBINACIONES PERMITIDAS PARA EL ACCESO ORDENADO .................................................................... 39

TABLA 2.11 COMBINACIONES PERMITIDAS PARA EL ACCESO COHERENTE .................................................................... 40

TABLA 2.12 POLÍTICA OWNERSHIP_STRENGTH .............................................................................................. 40

CAPÍTULO 5. IMPLEMENTACIÓN

TABLA 5.1 PARÁMETROS DE CONFIGURACIÓN DE LA CÁMARA MEDIANTE HTTP. ........................................................ 127

CAPÍTULO 6. ESTIMACIÓN DE COSTES

TABLA 6.1 TAREAS REALIZADAS Y DURACIÓN ESTIMADA ........................................................................................... 133

TABLA 6.2 INFRAESTRUCTURAS NECESARIAS PARA EL DESARROLLO DEL SISTEMA............................................................ 134

TABLA 6.3 INFRAESTRUCTURAS NECESARIAS PARA LA EXPLOTACIÓN DEL SISTEMA .......................................................... 134

TABLA 6.4 LÍNEAS DE CÓDIGO DEL PROYECTO......................................................................................................... 135

TABLA 6.5 PARÁMETROS PARA CALCULAR COSTES MEDIANTE COCOMO II ................................................................. 136

TABLA 6.6 DISTRIBUCIÓN DE ACTIVIDADES POR PERSONAS/MES PARA EL MODELO COCOMO II ...................................... 136


XII

XIII

Índice de listados

CAPÍTULO 5. IMPLEMENTACIÓN

LISTADO 5.1 MODELO IDL VIDEOFRAME ........................................................................................................... 124

LISTADO 5.2 MODELO IDL AUDIOPACKET ......................................................................................................... 124

LISTADO 5.3 MODELO IDL SESSIONSIGNALING ................................................................................................... 125

LISTADO 5.4 MODELO IDL IMMESSAGE ............................................................................................................ 125

LISTADO 5.5 ESQUEMA XML AL QUE HAN DE AJUSTARSE LOS ARCHIVOS DE CONFIGURACIÓN DE LA CÁMARA IP ............... 128

LISTADO 5.6 EJEMPLO DE ARCHIVO DE CONFIGURACIÓN........................................................................................ 129


XIV

XV

Glosario

API Application Programming Interface

CELP Code Excited Linear Prediction

COCOMO Constructive Cost Model

codec coder-decoder

CORBA Common Object Request Broker Architecture

DCOM Distributed Component Object Model

DCPS Data-Centric Publish-Subscribe

DCT Discrete Cosine Transform

DDS Data Distribution Service

DLRL Data Local Reconstruction Layer

DP Domain Participant

DR Datawriter

DW Datareader

GNU GNU is Not Unix

GUID Globally Unique Identifier

IEEE Institute of Electrical and Electronics Engineers

INC Incorporation

ISO International Organization of Standarization


XVI

ITU International Telecommunication Union

JMF Java Media Framework

JMS Java Message Service

JNI Java Native Interface

JPEG Joint Photographic Experts Group

H High

HTTP Hypertext Transfer Protocol

HVQ Hierarchical Vector Quantization

L Low

MCU Multipoint Control Unit

MPEG Moving Picture Experts Group

N Normal

NASA National Aeronautics and Space Administration

NATO North Atlantic Treaty Organization

OMG Object Management Group

OTAN Organización del Tratado Atlántico Norte

PS Publicación/subscripción

PBX Private Branch Exchange

PC Personal Computer

QCIF Quarter Common Intermediate Format

QoS Quality of Service

RMI Remote Method Invocation

RPC Remote Procedure Call

RT Real Time

RTI Real-Time Innovations

RTP Real-Time Transport Protocol

SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions

Índice de figuras

XVII

SIP Session Initiation Protocol

SOA Service Oriented Architecture

T Topic

UDP User Datagram Protocol

USB Universal Serial Bus

USC University of Southern California

VGA Video Graphics Array

VH very High

XH Extra High

XML Extensible Markup Language

XSD XML Schema Definition


XVIII

1

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.


2

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.

0.3.1 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.

0.3.2 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]


3

• Router

• Switch

0.3.3 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.


4

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.

0.5.1 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.

0.5.2 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.


5

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.

0.6.1 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).


6

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 1995.

El boom había comenzado, a partir de este momento numerosas compañías iniciaron el desarrollo de software y equipos de videoconferencia.

0.6.2 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.


7

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.


8

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


9

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

0.6.3 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 cliente-servidor, 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].


10

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.

0.6.4 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.

0.7.1 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.


11

• 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.

0.7.2 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.


12

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 1.2.4 del capítulo 1.


13

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.


14

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.

15

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.

1.1.1 ¿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 1.1.4 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


16

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.

1.1.2 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.


17

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.

data-space

a) Punto a punto: Teléfono, TCP.

c) Mensajería publicación / subscripción: Distribución de datos muchos a muchos.

b) Cliente servidor: Sistema de archivos, base de Datos, RPC, CORBA. Información centralizada uno a muchos.

Figura 1.2 Modelos de comunicación


18

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

1.1.3 ¿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 1.2.1 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.

1.1.4 ¿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


19

embebidos y/o empresariales. Para ello, RTI DDS usa el modelo de comunicaciones publicación-subscripció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ón-subscripció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.

1.2.1 ¿Qué es DCPS? DCPS es la parte del estándar OMG DDS que lleva a cabo las comunicaciones publicación-subscripció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.


20

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 data-

space . 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].


21

• 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ón-subscripció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.


22

1.2.2 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.

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.

Tópico

DataWriter

Publicador

Publicación DataReader

Subscriptor

Subscripción

*

1 1

*

1 1

* *


23

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

Publicador Subscriptor

Envío Recepción Servicio de Entrega

17 Mayo: Titular

Muestra

Tópico = “Noticias” Tópico = “Noticias”


24

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.

1.2.3 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.

1.2.4 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


25

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 data-

space . 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..

1.3 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.


26

27

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.


28

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 Modifi-cable

RxO Ext. DDS

DEADLINE Tiempo permitido entre las

actualizaciones de una instancia.

T, DW, DR

Sí Sí

DESTINATION_ORDER

Controla cómo se presentan las muestras de diferentes DataWriters de una misma instancia al correspondiente

DataReader.

T, DW, DR

Hasta que se active

Sí

DISCOVERY Configura cómo las

aplicaciones RTI DDS se descubren entre sí.

DP No No Sí

DISCOVERY_CONFIG

Configura el proceso de descubrimiento: qué

temporizadores se usan, cuáles son los límites de

recursos, etc.

DP No No Sí

DOMAIN_PARTICIPANT_RESOURCE_LI

MITS

Límite de recursos para el DomainParticipant.

DP No No Sí

DURABILITY

Controla si las muestras antiguas se guardan y envían

a los nuevos DataReaders que se unan a la red.

T, DW, DR

Hasta que se active

No

HISTORY

Si se almacenan y, en caso afirmativo, cuántas muestras

de una instancia se almacenan en los

DataWriters o DataReaders.

T, DW, DR

Hasta que se active

No Sí

LATENCYBUDGET

Sugiere cuánto retardo es aceptable en la transmisión de datos. Actualmente, RTI DDS no hace uso de esta

información..

T, DW, DR

Sí Sí

LIFESPAN

El tiempo durante el que una muestra enviada por un

DataWriter debe ser considerada válida.

T, DW Sí No

LIVELINESS Configura parámetros que

sirven para determinar si un DataWriter sigue activo.

T, DW, DR

Hasta que se active

Sí

Capítulo 2. Políticas de QoS en DDS

29

Política QoS Descripción Entidades Modifi-cable

RxO Ext. DDS

OWNERSHIP

Controla si es posible que varios DataWriters

modifiquen la misma instancia de un Tópico.

T, DW, DR

Hasta que se active

Sí

OWNERSHIP_STRENGHT

Necesario para discernir qué DataWriters pueden escribir una instancia de un Tópico.

DW Sí No

PARTITION Para crear particiones lógicas que dividen el

dominio DDS. Pub, Sub Sí No

PRESENTATION Controla el orden en el que se presentarán las diferentes

muestras. Pub, Sub

Hasta que se active

Sí

PUBLISH_MODE

Determina el modo de publicación de los

DataWriters, asíncrono o síncrono.

DW No No Sí

READER_DATA_LIFECYCLE

Controla durante cuánto tiempo un DataReader almacena muestras de

instancias cuyos writers ya no están activos.

DR Sí No

RELIABILITY Especifica si RTI DDS debe

enviar datos de forma fiable.

T, DW, DR

Hasta que se active

Sí

TIME_BASED_FILTER

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.

DR Sí No

TRANSPORT_PRIORITY

El efecto depende de la implementación de los

protocolos de transporte utilizados para enviar datos. Sugiere la prioridad deseada.

T, DW Sí No

TRANSPORT_MULTICAST

Especifica un conjunto de direcciones multicast a las

que los DataWriters deberían publicar los datos.

DR No No Sí

TRASNPORT_UNICAST

Especifica un conjunto de direcciones y puertos unicast a las que los

DataWriters deberían publicar los datos.

DW, DR, DP

No No Sí

Tabla 2.1 Políticas de QoS adecuadas para transmisión de audio y vídeo


30

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.

2.2.1 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


31

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 2.2.4 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.

2.2.2 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.


DDS_Duration_t duration Máximo periodo de validez del paquete.


32

Tabla 2.3 Política LIFESPAN


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.

2.2.3 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.


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 .


33

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.

Tabla 2.4 Política LIVELINESS

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.



34

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.

2.2.4 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 2.6.


35


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).


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).


36

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.

2.2.5 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.


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 2.2.4.3, 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.


37

2.2.6 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.


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.

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 .

Tabla 2.8 Política PRESENTATION


38

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.


39

• 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 Secuencia obtenida Orden de envío: {A1, B1, C1, A2, B2, C2} Orden de recepción: {A1, A2, B1, B2, C1, C2}

ordered_access = FALSE access_scope = <cualquiera>

{A1, A2, B1, B2, C1, C2}

ordered_access = T RUE access_scope = INSTANCE

{A1, A2, B1, B2, C1, C2}

ordered_access = T RUE 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:

{ordered_access / access_scope}

Subscriptor

False / Instance

False / Topic

True / Instance

True / Topic

Pu

blic

ad

or

False/Instance Compatible Incompatible Incompatible Incompatible

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


40

{coherent_access / access_scope}

Subscriptor

False / Instance

False / Topic

True / Instance

True / Topic

Pu

blic

ad

or

False/Instance Compatible Incompatible Incompatible Incompatible

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.

2.2.7 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 2.12.


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.


41

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 2.2.1 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


42

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.

43

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 0.5.1 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.


44

• 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

3.1.1 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.


45

• 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.


46

Nombre Iniciar sistema

Resumen El sistema se inicia, quedando listo para recibir órdenes del usuario

Dependencias

Actores Usuario (primario)

Precondiciones El sistema está apagado

Postcondiciones El sistema está iniciado y con la interfaz de descubrimiento/creación de salas activa.

Curso Normal 1. El usuario inicia el sistema 2. Se inicia la interfaz de usuario de descubrimiento/creación de

salas.

Nombre Buscar salas

Resumen El usuario activa el modo buscar salas. El sistema mostrará una lista con las salas disponibles y el tipo de sala.

Dependencias

Actores Usuario (primario), DDS (secundario)

Precondiciones El sistema está iniciado

Postcondiciones El sistema tiene la búsqueda de salas activa.

Curso Normal 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 Configurar sala

Resumen El usuario selecciona si la sala será pública o privada y los usuarios permitidos en caso de ser de tipo privada

Dependencias Es extendido por crear sala.



47


Postcondiciones La configuración de la sala ha cambiado

Curso Normal 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 Crear sala

Resumen 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.

Dependencias Incluye el caso de uso Unirse a sala.



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 Unirse a sala

Resumen 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.

Dependencias Está incluido en Crear sala.

Actores Usuario (primario), communicationDDS .signaling

(secundario), communicationDDS.messenger (secundario)


Postcondiciones 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.

Curso Normal 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 .


48

3. Se muestra la interfaz de sala de conversación al usuario.

Nombre Publicar mensaje

Resumen El usuario escribe un mensaje de texto, para su publicación en la sala.

Dependencias

Actores Usuario (primario), communicationDDS.messenger (secundario)

Precondiciones El sistema está iniciado y asociado a una sala.

Postcondiciones Se ha publicado un mensaje en la sala.

Curso Normal 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 Modificar publicaciones multimedia

Resumen El usuario inicia o detiene la publicación de audio y/o vídeo.

Dependencias Está incluido en Cerrar Sistema.

Actores Usuario (primario), communicationIPCamera (secundario) , client.audioPacket (secundario)


Postcondiciones Se han cambiado las publicaciones activas.

Curso Normal 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 Modificar subscripciones multimedia

Resumen El usuario inicia o detiene la subscripción a audio y/o vídeo

Dependencias Está incluido en Cerrar sistema.


49

Actores Usuario (primario), communicationDDS.videoFrame (secundario) , communicationDDS.audioPacket (secundario)


Postcondiciones Se han cambiado las subscripciones activas.

Curso Normal 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 Cerrar sistema

Resumen 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)


Postcondiciones El sistema termina su ejecución

Curso Normal 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,


50

communicationDDS.messenger, communicationDDS.signaling.

7. Se cierran las entidades de communicationIPCamera . 8. Se cierra la interfaz de usuario

Nombre Mostrar frame

Resumen Se muestra por la interfaz de usuario el nuevo frame de vídeo recibido

Dependencias

Actores communicationDDS.videoFrame (primario)

Precondiciones El sistema está iniciado, en una sala de conversación y subscrito a vídeo.

Postcondiciones Se ha actualizado la interfaz de usuario.

Curso Normal 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 Mostrar cambio LIVELINESS video

Resumen Se muestra a través de la interfaz que se ha producido un cambio en los publicadores de vídeo activos

Dependencias

Actores communicationDDS.videoFrame (primario)



Curso Normal 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 Notificar congestión Vídeo

Resumen Cuando hay situación de congestión, se toman medidas para aliviarla


51

Dependencias

Actores communicationDDS.videoFrame (primario) , communicationDDS.signaling (secundario)


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 Mostrar cambio LIVELINESS audio

Resumen Se muestra en la interfaz que ha habido un cambio en los publicadores de audio activos.

Dependencias

Actores communicationDDS.audioPacket (primario)


Postcondiciones Se ha actualizado la interfaz de usuario

Curso Normal 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 Mostrar solicitud de OWNERSHIP

Resumen Se indica a través de la interfaz una solicitud del canal de audio.


52

Dependencias

Actores communicationDDS.signaling (primario)

Precondiciones El sistema está iniciado y asociado a una sala de conversación.


Curso Normal 1. communicationDDS.signaling informa de la solicitud del canal.

2. La solicitud es mostrada en la interfaz de usuario.

Nombre Cambiar audio OWNER

Resumen 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)


Postcondiciones 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

Curso Normal 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 Mostrar cambio LIVELINESS señalización

Resumen Se notifica a través de la interfaz que un participante ha abandonado el dominio.

Dependencias

Actores communicationDDS.signaling (primario)


Postcondiciones


53

Curso Normal 1. communicationDDS.signaling informa de cambio en el estado de un participante.

2. Se actualiza la interfaz de usuario.

Nombre Mostrar nuevo mensaje

Resumen Se muestra un mensaje recibido a través de la subscripción al tópico de mensajería.

Dependencias

Actores communicationDDS.messenger (primario)


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 .


54

ud client.main

client.main

Usuario

Iniciar SistemaBuscar Salas

Configurar Sala

Crear Sala

Unirse a Sala

DDS



Publicar Mensaje

Modificar Publicaciones

Multimedia


communicationDDS.v ideoFrame

Modificar Subscripciones

Multimedia

Cerrar Sistema

Mostrar Frame

Mostrar Cambio Liveliness Video

Mostrar Cambio LIVELINESS Audio

Notificar Congestión Vídeo

client.audioPacket

communicationIPCamera

Mostrar Solicitud OWNERSHIP

Cambiar Audio Owner

Mostrar Nuevo Mensaje

Mostrar Cambio LIVELINESS Señalización

«include»

«include»

«include»

Figura 3.1 Diagrama de casos de uso para el subsistema client.main


55

3.1.2 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 .


• 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.


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.


• Reproducir paquete de audio: Se envía para su reproducción un paquete de audio a la tarjeta de sonido tras decodificarlo.


Nombre Iniciar captura

Resumen Se asocia al sistema un publicador a través del que se enviarán


56

paquetes de audio.

Dependencias

Actores client.main (primario), communicationDDS.audioPacket (secundario)

Precondiciones La publicación de audio no está activa.

Postcondiciones La publicación de audio está activa.

Curso Normal 1. client.main inicia la captura de audio, asociando un communicationDDS.audioPacket al sistema.

Nombre Finalizar captura

Resumen Se finaliza la captura de audio.

Dependencias

Actores client.main (primario)

Precondiciones La publicación de audio está activa.

Postcondiciones La publicación de audio no está activa.

Curso Normal 1. client.main finaliza la captura de audio.

Nombre Iniciar reproducción

Resumen Se asocia al sistema un subscriptor a través del que se enviarán paquetes de audio.

Dependencias


Precondiciones La subscripción de audio no está activa.

Postcondiciones La subscripción de audio está activa.

Curso Normal 1. client.main inicia la reproducción de audio, asociando un communicationDDS.audioPacket al sistema.


57

Nombre Finalizar reproducción

Resumen Finaliza la reproducción de paquetes de audio.

Dependencias

Actores client.main (primario)

Precondiciones La subscripción de audio está activa.

Postcondiciones La subscripción de audio no está activa.

Curso Normal 1. client.main finaliza la reproducción de paquetes de audio.

Nombre Cambiar audio OWNERSHIP

Resumen Se ajusta el valor de la política OWNERSHIP_STRENGTH según se tenga el control del canal de audio o no

Dependencias


Precondiciones La publicación de audio está activa.

Postcondiciones El valor de OWNERSHIP_STRENGTH ha sido modificado

Curso Normal 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 Publicar paquete de audio

Resumen Se envía para su publicación un paquete de audio.

Dependencias

Actores Dispositivo de audio (primario), communicationDDS.audioPacket (secundario)

Precondiciones El sistema está iniciado y la publicación de audio activa.


58

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 Reproducir paquete de audio

Resumen Se envía para su reproducción un paquete de audio a la tarjeta de sonido.

Dependencias

Actores communicationDDS.audioPacket (primario), dispositivo de audio (secundario)

Precondiciones 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 .


59

ud client.audioPacket

client.audioPacket

client.main

Iniciar captura

Iniciar reproducción

Finalizar captura

Finalizar reproducción

Cambiar audio OWNERSHIP

Publicar paquete de audio

Reproducir paquete de audio

Dispositivo de sonido


Figura 3.2 Diagrama de casos de uso para el subsistema client.audioPacket

3.1.3 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.


• 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.


60


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.


• 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.

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.



61

Nombre Iniciar subscripción

Resumen 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 client.main (primario), DDS (secundario)

Precondiciones No hay subscripción previa.

Postcondiciones El sistema queda subscrito al tópico indicado.

Curso Normal 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 Eliminar subscripción

Resumen El cliente finaliza la subscripción, por lo que dejan de recibirse datos de vídeo.

Dependencias


Precondiciones El sistema está subscrito a un tópico.

Postcondiciones El sistema no está subscrito a ningún tópico.

Curso Normal 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


62

listener . 4. El sistema elimina el subscriptor del

DomainParticipant .

Nombre Iniciar publicación

Resumen 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 communicationIPCamera (primario ), DDS (secundario)

Precondiciones El sistema no ha iniciado la publicación.

Postcondiciones El sistema queda asociado a un tópico en el que publicar datos.

Curso Normal 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 Eliminar publicación

Resumen El sistema communicationIPCamera finaliza la publicación existente

Dependencias

Actores communicationIPCamera (primario), DDS (secundario)

Precondiciones El sistema está asociado a un tópico para publicar datos

Postcondiciones El sistema no está vinculado a ningún tópico.

Curso Normal 1. communicationIPCamera solicita la terminación de la publicación.


63

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 Publicar datos

Resumen El sistema communicationIPCamera envía datos, que serán publicados sobre DDS.

Dependencias

Actores communicationIPCamera (primario), DDS (secundario)


Postcondiciones Los datos han sido publicados sobre DDS.

Curso Normal 1. communicationIPCamera envía datos para publicar. 2. El sistema publica los datos a través de DDS.

Nombre Recibir datos

Resumen DDS entrega datos al sistema, que son enviados al sistema client.main .

Dependencias

Actores DDS (primario), client.main (secundario)

Precondiciones El sistema está subscrito a un tópico

Postcondiciones Los datos han sido entregados a client.main .

Curso Normal 1. DDS entrega datos al sistema. 2. El sistema remite los datos a client.main .

Nombre Notificar expiración de DW DEADLINE

Resumen Cuando se produce una expiración en la política DEADLINE en el DataWriter , se activa un flag que indica el estado DEADLINE


64

incumplido en el DataWriter .

Dependencias

Actores DDS (primario)


Postcondiciones El flag deadlineExpired asociado al DW queda activado.

Curso Normal 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 Notificar expiración de DR DEADLINE

Resumen 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 DDS (primario)


Postcondiciones El flag deadlineExpired asociado al DR queda activado.

Curso Normal 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 Notificar cambio en LIVELINESS

Resumen 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




65

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 Ejecutar comprobación en DW

Resumen 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)


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 Ejecutar comprobación en DR

Resumen 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)


66


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 .


67

cd communicationDDS.v ideoFrame


client.main


DDS

Temporizador

Iniciar Subscripción

Eliminar Subscripción

Iniciar Publicación

Eliminar Publicación

Publicar Datos

Recibir Datos

Notificar Expiración DR

DEADLINENotificar

Expiración DW DEADLINE

Notificar Cambio en LIVELINESS

Ejecutar Comprobación en

DW

Ejecutar Comprobación en

DR

Figura 3.3 Diagrama de casos de uso para el subsistema communicationDDS.videoFrame

3.1.4 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.


• 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.


68

• 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.


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 .



Resumen 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 client.audioPacket (primario), DDS (secundario)



69


Curso Normal 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.


Resumen client.main finaliza la subscripción, por lo que dejan de recibirse paquetes de audio.

Dependencias




Curso Normal 1. client.main solicita la finalización de la subscripción. 2. El sistema finaliza el DataReader y su respectivo


DomainParticipant .


Resumen 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





70

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




Resumen El sistema client.main finaliza la publicación existente

Dependencias




Curso Normal 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 Publicar datos

Resumen El sistema client.audioPacket envía datos, que serán publicados sobre DDS.

Dependencias




Curso Normal 1. client.audioPacket envía datos para publicar. 2. El sistema publica los datos a través de DDS.


71

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



Postcondiciones El valor de la política OWNERSHIP ha cambiado

Curso Normal 1. client.audioPacket cambia el valor de la política OWNERSHIP


Resumen DDS entrega datos al sistema, que son enviados al sistema client.audioPacket .

Dependencias

Actores DDS (primario), client.audioPacket (secundario)


Postcondiciones Los datos han sido entregados a client.audioPacket .

Curso Normal 1. DDS entrega datos al sistema. 2. El sistema remite los datos a client.audioPacket .


Resumen Cuando se produce un cambio en los DataWriters , el sistema notifica a client.main

Dependencias



Postcondiciones


72




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


client.audioPacket

DDS





Publicar Datos

Cambiar OWNERSHIP

Recibir Datos

Notificar Expiración DR

DEADLINE

Notificar Expiración DW

DEADLINE


client.main

Figura 3.4 Diagrama de casos de uso para el subsistema communicationDDS.audioPacket


73

3.1.5 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.


• 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.


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.


• 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 .




Resumen 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



74



Curso Normal 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


4. El sistema inicializa las políticas QoS. 5. El sistema crea un DataReader asociado a dicho tópico y



Resumen client.main finaliza la subscripción, por lo que dejan de recibirse paquetes de señalización.

Dependencias






DomainParticipant .


Resumen 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



75




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.



Resumen El sistema client.main finaliza la publicación existente.

Dependencias






DomainParticipant .

Nombre Publicar Información de Señalización

Resumen client.main entrega información de señalización al sistema para su envío a través de DDS.

Dependencias




Curso Normal 1. client.main entrega información de señalización para su


76

envío. 2. El sistema publica los datos a través de DDS.


Resumen DDS entrega datos al sistema. La información es entregada a client.main

Dependencias



Postcondiciones Los datos han sido entregados a client.main

Curso Normal 1. DDS entrega datos al sistema. 2. La información de señalización es entregada a

client.main


Resumen Cuando se produce un cambio en los DataWriters , el sistema notifica a client.main .

Dependencias



Postcondiciones





Diagrama de Casos de Uso: En la figura 3.5 se muestra el diagrama de casos de uso para el subsistema communicationDDS.signaling .


77

ud communicationDDS.signaling


client.main DDS





Publicar Información de

Señalización

Recibir Datos


Figura 3.5 Diagrama de casos de uso para el subsistema communicationDDS.signaling

3.1.6 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.


• client.main : Será el encargado de iniciar/detener la publicación/subscripción DDS y publicar mensajes de texto.


78

• 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.


client.main

• 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.


• Publicar mensaje: El sistema client.main entrega un mensaje para su publicación en el tópico de mensajería.

DDS

• Recibir mensaje: DDS entrega un mensaje al sistema.




Resumen client.main inicia la subscripción al tópico de mensajería. Una vez iniciada la subscripción, se podrán recibir mensajes.

Dependencias




Curso Normal 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.


79

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



Resumen client.main finaliza la subscripción, por lo que dejan de recibirse mensajes.

Dependencias






DomainParticipant .


Resumen El sistema client.main inicia la publicación a un tópico, momento a partir del cual los se pueden enviar mensajes

Dependencias

Actores client.main (primario , DDS (secundario)




2. El sistema crea el publicador. 3. El sistema comprueba si existe un tópico de señalización en el


4. El sistema crea un DataWriter asociado a dicho tópico y


80



Resumen El sistema client.main finaliza la publicación existente

Dependencias






DomainParticipant .

Nombre Publicar mensaje

Resumen El sistema client.main entrega un mensaje para su publicación en el tópico de mensajería.

Dependencias


Precondiciones El sistema está asociado a un tópico para publicar mensajes

Postcondiciones El mensaje ha sido publicado en DDS.

Curso Normal 1. client.main solicita la publicación de un mensaje. 2. El sistema publica el mensaje a través de DDS.

Nombre Recibir mensaje

Resumen DDS entrega un mensaje al sistema

Dependencias




81

Postcondiciones Los datos han sido entregados al subsistema adecuado

Curso Normal 1. DDS entrega un mensaje al sistema. 2. El sistema entrega el mensaje al sistema client.main


Resumen Cuando se produce un cambio en los DataWriters , el sistema notifica a client.main .

Dependencias



Postcondiciones





Diagrama de Casos de Uso: En la figura 3.6 se muestra el diagrama de casos de uso para el subsistema CommunicationDDS.messenger .


82

ud communicationDDS.messenger


client.main

DDS





Publicar Mensaje

Recibir Mensaje


Figura 3.6 Diagrama de casos de uso para el subsistema communicationDDS.messenger

3.1.7 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.


• 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.


83

• 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.


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.


• 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


Nombre Conectar sistema

Resumen Inicia la conexión del sistema a la cámara y el inicio de la publicación.

Dependencias Incluye el caso de uso Cargar configuración. Está incluido en Cambiar calidad.

Actores client.main (primario), Cámara IP (secundario)

Precondiciones El sistema está desconectado

Postcondiciones El sistema está conectado

Curso Normal 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


84

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 Desconectar sistema

Resumen Finaliza la conexión del sistema a la cámara, tras lo que finaliza la publicación de datos.

Dependencias Está incluido en Cambiar calidad.

Actores client.main (primario), Cámara IP (secundario)

Precondiciones El sistema está conectado

Postcondiciones El sistema está desconectado

Curso Normal 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 Cargar configuración

Resumen Carga una configuración predeterminada para conectar a la cámara IP de un archivo XML

Dependencias Es un caso de uso abstracto incluido por Conectar sistema

Actores

Precondiciones

Postcondiciones

Curso Normal 1. El sistema carga la configuración de la cámara desde un archivo XML.

Curso Alternativo 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 Cambiar calidad

Resumen Solicita un cambio en la calidad del vídeo transmitido para ajustar la cantidad de información enviada a las condiciones del sistema.


85

Dependencias Incluye los casos de uso Desconectar sistema y Conectar sistema.

Actores client.main (primario), communicationDDS.videoFrame (primario)


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 Publicar frame

Resumen Envía un frame que ha de ser publicado en DDS.

Dependencias

Actores Cámara IP (primario), communicationDDS.videoFrame (secundario)


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


Diagrama de Casos de Uso: En la figura 3.7 se muestra el diagrama de casos de uso para el subsistema CommunicationDDS.CommunicationIPCamera .


86

ud communicationIPCamera


client.main

DDSCommunication.v ideoFrame

Cámara IP

Conectar Sistema

Desconectar Sistema

Cargar Configuración

Cambiar Calidad

Publicar Frame

«include»

«include»

«include»

Figura 3.7 Diagrama de casos de uso para el subsistema communicationDDS.CommunicationIPCamera

3.2 Requisitos No Funcionales

3.2.1 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.


87

• 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.

3.2.2 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.

3.2.3 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.


88

• 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.

89

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.


90

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.

4.2.1 Políticas DEADLINE y TIME_BASED_FILTER Las políticas DEADLINE y TIME_BASED_FILTER (discutidas en los apartados 2.2.1 y 2.2.7 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


91

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.

4.2.2 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 3.1.1 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.

4.2.3 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.


92

4.2.4 Política LIFESPAN Como se indicó en la sección 2.2.2 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.

4.2.5 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 2.2.4 y 2.2.5 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 0.

4.3 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.

4.3.1 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.


93

Figura 4.2 Paquete client.main

4.3.2 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.


94

4.3.3 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 data-

space , 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.

Figura 4.3 Paquete client.audioPacket


95

• 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 data-

space .

• 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

4.3.4 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 data-

space , 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.


96

• 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 data-

space .

• 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

4.3.5 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 4.2.1 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


97

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

4.3.6 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.


98

• ImMessageDataWriter , ImMessageDataReader : Clases correspondientes al datawriter y datareader utilizados para recibir y enviar información al data-

space .

• ImMessageTypeCode , ImMessageSupport , ImMessageSeq : Clases de apoyo para el acceso al middleware.

Figura 4.7 Paquete communicationDDS.messenger

4.3.7 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.


99

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.

4.4.1 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”


100

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.


101

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.


102

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”


103

4.4.2 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.


104

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.


105

Figura 4.17 Diagrama de secuencia “Publicar/reproducir paquete de audio”

4.4.3 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.


106

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.


107

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.


108

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 ”.


109

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 .


110

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”

4.4.4 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


111

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.


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.


112


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”


113

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”

4.4.5 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


114

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.


115


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.


116


4.4.6 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.


117


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.


118


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”


119

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.


4.4.7 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.


120

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.


121

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


122

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.

123

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 1.2.1 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:

5.1.1 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.


124

Listado 5.1 Modelo IDL VideoFrame

5.1.2 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

5.1.3 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


125

Listado 5.3 Modelo IDL SessionSignaling

5.1.4 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++,


126

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.messe nger ) 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 0.5.1 y 3.2.3 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.

5.3.1 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.


127

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> 0 - 100 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.

5.3.2 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 2001. 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.


128

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.


129

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.


130

• 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.

5.4.1 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.


131

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 1.0.3 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.


132

133

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].


134

6.2.1 Infraestructuras En las secciones 0.2.2 y 0.2.3 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 2007 80 €

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 1.5 0 € 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.

6.2.2 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 1981. 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:


135

• 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 11500 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)


136

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 0.1 0.2 0.5 0.1 0.9 Entorno 0.0 0.1 0.2 0.0 0.5 Requerimientos 0.2 0.3 0.4 0.0 0.9 Diseño 0.1 0.6 0.8 0.0 1.5 Implementación 0.0 0.2 1.7 0.2 2.1 Evaluación 0.0 0.2 1.2 0.2 1.6 Despliegue 0.0 0.0 0.1 0.2 0.4

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 0.5.2 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


137

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.


138

139

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


140

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.

141

Bibliografía

[1] OBJECT MANAGEMENTT GROUP (2007): “Data distribution service for Real-Time Systems. Version 1.2” Disponible en: http://www.omg.org/docs/formal/07-01-01.pdf

[2] OBJECT MANAGEMENT GROUP (2008): “Object Management Group”. Disponible en: http://www.omg.org/

[3] CLICK TO MEET (2008): “Click to meet platform” Disponible en: http://www.radvision.com/Products/Desktop/CTMPlatform/

[4] ISABEL (2008): “Isabel Plaza – Home”. Disponible en: http://isabel.dit.upm.es/

[5] CONNECTA 2000 (2008): “Connecta 2000 - Videoconferencia Peer-to-peer” http://www.connecta2000.com/

[6] MICROSOFT OFFICE COMMUNICATION SERVER (2008): “Página principal de Office Communications server – Microsoft Office Online”. Disponible en: http://office.microsoft.com/es-es/communicationsserver/default.aspx/

[7] DATA ORIENTED (2008): “Data-Oriented Architecture”. Disponible en: http://www.rti.com/mk/data-oriented-architecture.html

[8] AXIS (2008): “Axis Communications”. Disponible en: http://www.axis.com/

[9] REAL-TIME INNOVATIONS (2008): “The Real-Time Middleware Experts”. Disponible en: http://www.rti.com/

[10] ECLIPSE (2008): “Eclipse.org home”. Disponible en: http://www.eclipse.org/

[11] JSPEEX (2008): “Jspeex – Java implementation of Speex”. Disponible en: http://jspeex.sourceforge.net/

[12] ANKENEY, J. (2006): “Technology Showcase: Videoconferencing Room Systems”. SVC

[revista electrónica]. Disponible en: http://svconline.com/mag/avinstall_videoconferencing_room_systems/


142

[13] AHMED, N.; NATARAJAN, T.; RAO, K.R. (1974): “Discrete Cosine Transform”. IEEE

Trans. Computers, pp. 90-93

[14] COMPRESSION LABS INC (1996): “COMPRESSION LABS INC Annual Report”. Disponible en: http://sec.edgar-online.com/1996/04/15/00/0000891618-96-000217/Section2.asp

[15] COX, J. J. (2007): “Background and history of Videoconferencing”. Content for reprint [revista electrónica]. Disponible en: http://www.content4reprint.com/technology/video-conferencing/background-and-history-of-videoconferencing.htm

[16] DORCEY, T. (1995): “CU-SeeMe Desktop Video Conferencing Software”. Connexions, 9 (3). Disponible en: http://myhome.hanafos.com/~soonjp/dorcey.html

[17] RADVISION (2006): “Click to meet”. Disponible en: http://www.radvision.com/NR/rdonlyres/8D34718C-BBA3-49C9-BD43-465EA8F7AA58/0/CTMPlatform.pdf

[18] RADVISION (2008): “RADVISION Delivering the visual experience”. Disponible en: http://www.radvision.com/

[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: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10986/34623/01651238.pdf?temp=x

[20] SPEEX (2008): “Speex: a free códec for free speech” Disponible en: http://www.speex.org/

[21] CORBA (2008): “Welcome to the OMG’s CORBA website”. Disponible en: http://www.corba.org/

[22] THALES (2008): “Thales Group, information systems serving Aerospace, Defence and Security Markets”. Disponible en: http://www.thalesgroup.com/

[23] PARDO-CASTELLOTE, G. (2005): “OMG Data distribution service: Real-Time publish/subscribe becomes a standar” RTC, 14. Disponible en: http://www.rti.com/docs/reprint_rti.pdf

[24] PRISMTECH (2008): “OpenSplice DDS Data distribution service overview middleware”. Disponible en: http://www.prismtechnologies.com/section-item.asp?id=558

[25] TWIN OAKS COMPUTING, INC. (2008): “High performance communications software”. Disponible en: http://www.twinoakscomputing.com/snews/products/coredx-dds-evaluation-release/

[26] OBJECT COMPUTING, INC. (2008): “OCI-Products-OpenDDS-Object Computing, Inc.” Disponible en: http://www.ociweb.com/products/opendds

Bibliografía

143

[27] MILSOFT (2008): “Milsoft DDS Middleware”. Disponible en: http://dds.milsoft.com.tr/en/dds-home.php

[28] OBJECT MANAGEMENTT GROUP (2007): “Data Distribution RTF 2 DCPS IDL”. Disponible en: http://www.omg.org/cgi-bin/doc?ptc/06-04-11

[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: http://middleware.objectweb.org/

[31] NATO SCIENCE COMMITTEE (1969): “Software Engineering” Disponible en: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF

[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: http://www.omg.org/news/meetings/workshops/rt_2007.htm

[33] DCE/RPC (2008): “Free DCE 1.2.2 License and Download”. Disponible en: http://www.opengroup.org/dce/download/

[34] DCOM (1996): “DCOM Technical Overview”. Disponible en: http://msdn.microsoft.com/en-us/library/ms809340.aspx

[35] HENNING, M.; SPRUIELL, M. (2008): “Distributed Programing with Ice”. Disponible en: http://www.zeroc.com/Ice-Manual.pdf

[36] TIBCO (2008): “TIBCO. Service Oriented Architecture (SOA) Software, Business Process Management (BPM) Software Leader”. Disponible en http://www.tibco.com/

[37] 29WEST (2008): “29West. Home”. Disponible en http://www.29west.com/

[38] JMS (2008): “Java Message Service (JMS)”. Disponible en http://java.sun.com/products/jms/

[39] MQ SERIES (2008): “Welcome to MQSeries.net – Serving IBM WebSphere MQ Professionals Worldwide”. Disponible en http://www.mqseries.net/

[40] GIGASPACES (2008): “GigaSpaces eXtreme Application Platform (XAP). GigaSpaces”. Disponible en: http://www.gigaspaces.com/xap

[41] RTI DDS (2008): “RTI Data Distribution Service”. Disponible en: http://www.rti.com/docs/RTI_DDS_41.pdf

[42] PARDO-CASTELLOTE, G. (2003): “OMG Data-Distribution Service: architectural overview”. Disponible en:


144

http://portals.omg.org/dds/WhitepapersPage?action=AttachFile&do=get&target=DDS_Architectural_Overview.pdf

[43] WATINE, V. (2004): “Data Distribution Service – DLRL” Real-time and Embedded Systems

Workshop. Disponible en: http://www.omg.org/news/meetings/workshops/RT_2004_Manual/00-T6-2_DDS.pdf

[44] OBJECT MANAGEMENTT GROUP (2007): “Data Distribution RTF 2 DLRL IDL”. Disponible en: http://www.omg.org/cgi-bin/doc?ptc/06-04-12

[45] SIERLA, S.; PELTOLA, J.; KOSKINEN, K. (2003): “Evaluation of a Real-Time Distribution Service”. Disponible en: http://www.automationit.hut.fi/file.php?id=300

[46] SCHNEIDER, S. (2006): “Data-centric pervasive information is the wave of the future” Rf

design. Disponible en: http://rfdesign.com/mag/608RFDEf1.pdf

[47] CORSARO, A.; QUERZONI, l..; SCIPIONI, S.; TUCCI, S.; et al (2006): “Quality of Service in Publish/Subscribe Middleware”. Disponible en: http://www.cse.wustl.edu/~corsaro/papers/pubsubChapter.pdf

[48] SCHNEIDER, S. (2008): “Meeting Real-Time requirements in networked systems”. Disponible en: http://www.eetimes.com/news/design/showArticle.jhtml?articleID=207400961

[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. 1-8.

[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: http://grids.ucs.indiana.edu/ptliupages/publications/AVOverNaradaBrokering.pdf

[51] OMG IDL (2008): “OMG IDL”. Disponible en: http://www.omg.org/gettingstarted/omg_idl.htm

[52] OMG IDL ESTÁNDAR ISO 14750 (2008): “ISO – International Organization for Standardization”. Disponible en: http://www.iso.ch/cate/d25486.html

[53] OMG IDL (2002): “OMG IDL Syntax and Semantics”. Disponible en: http://www.omg.org/docs/formal/02-06-07.pdf

[54] PARDO-CASTELLOTE, G. (2004): “Data Distribution Service (DDS) and the RTPS protocol”. Disponible en: http://www.omg.org/docs/realtime/04-11-07.pdf

[55] RTI (2008): “RTI Data User’s Manual”. Disponible en: http://www.rti.com/products/data_distribution/RTIDDS.html

[56] API VAPIX (2008): “Axis Communications – Network Camera Developer pages”. Disponible en: http://www.axis.com/techsup/cam_servers/dev/cam_http_api_2.php

Bibliografía

145

[57] ITU-T (1993): “General aspects of digital transmission systems”. Disponible en: http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.711-198811-I!!PDF-E&type=items

[58] XML Schema Working Group (2008): “W3C XML Schema”. Disponible en: http://www.w3.org/XML/Schema

[59] WEN, H. (2008): “Java solutions profile: Java web conferencing”. Disponible en: http://www.javaworld.com/javaworld/jw-02-2008/jw-02-javawebconferencing_profile.html?page=1

[60] JMF (2008): “Java SE Desktop Technologies – Java Media Framework API (JMF)”. Disponible en: http://java.sun.com/javase/technologies/desktop/media/jmf/

[61] JAVA SOUND (2008): “Java Sound API”. Disponible en: http://java.sun.com/products/java-media/sound/

[62] BOMERS, F.; PFISTERER, M. (2004): “The Java Sound Internet Phone” Java One. Disponible en: http://www.jsresources.org/apps/3196_InternetPhone.pdf

[63] VORBIS (2008): “Vorbis.com”. Disponible en: http://www.vorbis.com/

[64] CELP (2008): “CELP 3.2ª & LPC-10”. Disponible en: http://www.speech.cs.cmu.edu/comp.speech/Section3/Software/celp-3.2a.html

[65] Contenedor ogg

[66] SPEEX MANUAL (2008): “Formats and standards”. Disponible en: http://speex.org/docs/manual/speex-manual/node8.html

[67] NASA (2008): “COCOMO Software Cost Model”. Disponible en: http://cost.jsc.nasa.gov/COCOMO.html

[68] REAL TIME INNOVATIONS (2008): “RTI – The Real-Time Middleware Company – University Progam”. Disponible en: http://www.rti.com/corporate/university.html

[69] USC-CSE1 (2008): “CSSE Website”. Disponible en: http://csse.usc.edu/csse/index.html

[70] IRUS (2008): “Irvine Research Unit in Software (IRUS)”. Disponible en: http://www.ics.uci.edu/~irus/sponsors.html

[71] COCOMO II (2008): “CSSE Website”. Disponible en: http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html

[72] USC (2008): “USC Expert COCOMO II”. Disponible en: http://sunset.usc.edu/research/COCOMOII/expert_cocomo/expert_cocomo2000.html


146

[73] OMG (2008): “Workshop on Distributed Object Computing for Real-time and Embedded systems”. Disponible en: http://www.omg.org/news/meetings/workshops/rt_embedded_2008.htm

147

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.


148

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”.

Anexo A. Manual de Usuario

149

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.


150

• 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


151

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.


152

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


153

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


154

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.


155

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


156

Finalmente, cuando un usuario abandona la sala, el resto de usuarios son notificados, tal y como se aprecia en la figura A.14.

Figura A.14 Mensajes de salida de usuarios

ACTA DE VALORACIÓN

El tribunal constituido para la evaluación del proyecto PFC titulado:

“Plataforma de Trabajo Colaborativo sobre Middleware DDS”

Realizado por el alumno José María López Vega

Y dirigido por el tutor: Juan Manuel López Soler

Ha resuelto asignarle la calificación de:

Con la nota1: puntos

El Presidente: _________________________

El Secretario: _________________________

El Vocal: _________________________


1 Solamente con un decimal

estudios de ingenierÍa de telecomunicaciÓn

Documents