josé maría lópez vega [email protected] dirigido por juan...

José María López Vega

[email protected]

Dirigido por Juan Manuel López Soler

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

E.T.S. Ingenierías Informática y de Telecomunicación

Universidad de Granada

� Nueva aproximación para el diseño de una herramienta de trabajo colaborativo.

� Se aplica el paradigma de la publicación/subscripción.

� Prueba de concepto de la viabilidad de � Prueba de concepto de la viabilidad de implementar aplicaciones muchos a muchos con contenidos de audio y vídeo sobre middleware DDS.

� Selección de políticas de QoS adecuadas.

José María López Vega – Plataforma de trabajo colaborativo sobre middleware DDS 2/26

1. Introducción1. Definiciones básicas

2. Estado del arte

3. Definición del problema

2. Análisis1. Requisitos de la aplicación

2. Otras decisiones

Solución propuesta

1. Introducción2. Análisis3. Solución propuesta4. Diseño e implementación5. Demostración6. Conclusiones7. Trabajo futuro

3. Solución propuesta

4. Diseño e implementación1. Arquitectura del sistema

2. Políticas de QoS incorporadas

3. Descripción IDL

4. Comunicación con cámara IP

5. Gestión de audio

5. Demostración

6. Conclusiones

7. Trabajo futuro


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

Middleware

1. Introducción1. Introducción

2. Análisis3. Solución propuesta4. Diseño e implementación5. Demostración6. Conclusiones7. Trabajo futuro

José María López Vega – Plataforma de trabajo colaborativo sobre middleware DDS

Es una aproximación centrada en datos, los cuales se intercambian a través del así denominado data-space. El data-space permite desacoplar espacial y temporalmente las fuentes (publicadores) y los sumideros (subscriptores) de información. Es adecuado para sistemas distribuidos.

Paradigma de publicación/subscripción

data-

space

4/26

Middleware que permite la distribución de datos basándose en el paradigma de la publicación/subscripción.Es un estándar de la OMG (Object Management

Data Distribution Service (DDS)




Es un estándar de la OMG (Object Management Group).

Tópico

DataWriter

Publicador

PublicaciónDataReader

Subscriptor

Subscripción

*

1 1

*

1 1

* *

EntidadesDDS

5/26

Mecanismos estandarizados que permiten configurar el comportamiento del middleware. Las políticas de calidad de servicio aligeran a la aplicación, al librarla de muchas tareas como por ejemplo la posibilidad de comunicación de uno a muchos

Políticas de QoS (Quality of Service)




por ejemplo la posibilidad de comunicación de uno a muchos fiable, con lo que se reduce la complejidad del sistema.

6/26

Comunicación simultánea bidireccional de audio y vídeo, permitiendo mantener reuniones con grupos de personas situadas en lugares alejados entre sí.

Videoconferencia




Sala Entorno virtual aislado en los que un conjunto de usuarios intercambian mensajes de texto, voz, vídeo, etc.

Moderador Usuario con privilegios especiales. Por ejemplo, determinar qué usuario puede hablar en cada momento.

Descubrimiento Procedimiento por el que el usuario obtiene una lista de las salas disponibles.

Otras definiciones relativas a videoconferencia

7/26

� Existen multitud de plataformas de trabajo colaborativo y videoconferencia, cada una con una serie de características apropiadas para distintos requisitos (Click to Meet, Isabel, Connecta2000, MS Office Communication Server, etc.)

Videoconferencia




MS Office Communication Server, etc.)� Por lo general, orientación cliente-servidor

� Tecnología en pleno auge.� Implementaciones existentes: RTI DDS,

OpenSplice, CoreDX, OpenDDS, MilSOFT.

Middleware DDS

8/26

� Deseamos desarrollar un sistema de trabajo colaborativo, con soporte para videoconferencia entre distintos clientes remotos.

� La plataforma deberá mostrar la viabilidad de




� La plataforma deberá mostrar la viabilidad de implementar aplicaciones de streaming de audio/vídeo sobre middleware DDS aprovechando las políticas QoS disponibles.

� Además, el programa implementado debe facilitar el desarrollo posterior de aplicaciones similares sobre middleware DDS.

9/26

� La aplicación ha de ser multiplataforma o, al menos, portable.

� Debe ser fácilmente extensible.

� Se recomienda que sea modular.

1. Introducción2. Análisis2. Análisis

3. Solución propuesta4. Diseño e implementación5. Demostración6. Conclusiones7. Trabajo futuro


� La totalidad de las comunicaciones se realizarán sobre middleware DDS.

� Para la captura de vídeo, se utilizará una cámara IP modelo 207W del fabricante Axis. El vídeo será transmitido sobre MJPEG.

� En el caso del audio, no existían requisitos específicos.

10/26

� Multiplataforma, prototipado rápido, Javadoc.

Desarrollo en Java

Entorno de desarrollo Eclipse

1. Introducción2. Análisis2. Análisis

3. Solución propuesta4. Diseño e implementación5. Demostración6. Conclusiones7. Trabajo futuro


� Herramienta de código abierto muy potente, extensible mediante sistema de plugins.

Entorno de desarrollo Eclipse

� Código libre, complementario a Vorbis, calidad elevada con reducido ancho de banda, robusto frente a pérdidas de paquetes, permite cambiar la calidad del stream dinámicamente.

Códec de audio SPEEX

11/26

1. Introducción2. Análisis3. Solución propuesta3. Solución propuesta

4. Diseño e implementación5. Demostración6. Conclusiones7. Trabajo futuro


1. Introducción2. Análisis3. Solución propuesta4. Diseño e implementación4. Diseño e implementación

5. Demostración6. Conclusiones7. Trabajo futuro


� DEADLINE fija una separación máxima entre dos actualizaciones del

tópico. DDS informa cuando se supera ese valor máximo, lo que permite detectar problemas en el intercambio de datos entre datawriters y el datareaders.

DEADLINE Y TIME_BASED_FILTER




� TIME_BASED_FILTER limita el número de muestras que se entregan

a la aplicación por segundo, estableciendo una separación temporal mínima entre ellas.

� Cuando se detectan problemas en el datawriter de vídeo, se

reduce la tasa de transmisión (reduciendo la calidad).

� Si aparecen problemas en el datareader de vídeo, se utiliza el tópico de señalización con objeto de informar a los datawritersde la situación, para que reduzcan de forma remota la calidad del stream de vídeo.

14/26

SubscripciónVídeo

Decrementar TBF y DEADLINE en un 20%, si Notificar al




ControlSistema

Publicación Señalización

DEADLINE en un 20%, si son superiores al valor mínimo establecido.

Notificar al sistema que

no hay problemas

Mediante el tópico de señalización, se indica al resto de sistemas que no hay problemas en la

recepción.

15/26

SubscripciónVídeo

Incrementar TBF y DEADLINE al doble de su




ControlSistema

Publicación Señalización

DEADLINE al doble de su valor, si son menores que el valor máximo

permitido.

Notificar al sistema que

hay problemas

Mediante el tópico de señalización, se indica al resto de sistemas que hay problemas en la

recepción.

16/26

� LIVELINESS ha sido utilizada en el sistema aquí presentado para

mantener el servicio de presencia. Es decir, informa a los clientes de la entrada y salida de usuarios a una determinada sala de conferencias.

LIVELINESS




� Esta política establece que las muestras publicadas en un tópico por distintos datawriters sean entregadas en el mismo orden en que se

enviaron.

PRESENTATION

� Esta política asegura que los paquetes con un retardo excesivo no se entregan a la aplicación, al carecer de validez. Se ha fijado para un retardo máximo permisible de 750 ms.

LIFESPAN

17/26

� OWNERSHIP establece si cualquier datawriter puede actualizar los

datos de interés o, por el contrario, sólo podrá llevarlo a cabo un datawriter concreto.

� OWNERSHIP_STRENGTH permite asignar una puntuación a un

OWNERSHIP Y OWNERSHIP_STRENGTH




� OWNERSHIP_STRENGTH permite asignar una puntuación a un datawriter, lo que determinará si los datos que éste escribe serán

entregados.

� Estas políticas han sido utilizadas para la gestión del canal de audio. Concretamente, el usuario con permisos de moderador puede indicar mediante el tópico de señalización qué usuario tiene la palabra. Según esta información, cada cliente actualiza el valor de las políticas OWNERSHIP y OWNERSHIP_STRENGTH para los datawriters, con lo que únicamente se entregarán los paquetes de audio que provengan del cliente con el control del canal de audio.

18/26

� Se ha implementado de forma modular.

� Las cámaras AXIS disponen de una API común denominada VAPIX®.

� La comunicación con la cámara se realiza




� La comunicación con la cámara se realiza mediante HTTP.

� La configuración de la cámara se carga desde un archivo XML, lo que permite fácil extensibilidad de la aplicación.

20/26

� Gran variedad de codecs, versiones para cada plataforma, librería externa, permite personalizar transporte bajo RTP, pero no sustituir RTP.

JMF (Java Media Framework)




� Trabaja a nivel más bajo que JMF, escaso soporte de codecs, es fácilmente extensible.

� Esta fue la opción elegida.

� Se ha extendido mediante JSPEEX. Fue necesario modificar la librería.

Java Sound

21/26

1. Se iniciará la aplicación.1. Se iniciará la aplicación.2. Se creará una sala pública.3. Se iniciarán/detendrán publicaciones

de audio y vídeo.4. Se mostrará el mecanismo de

adaptación a las condiciones de congestión.

5. Se describirá el funcionamiento del mecanismo de moderación.

6. Se creará una sala privada.

22/26

� La utilización de middleware DDS efectivamente acorta los tiempos de desarrollo de aplicaciones que requieren distribución de datos en tiempo real.

� La aplicación del modelo de publicación-subscripción para un sistema de videoconferencia no sólo es viable, sino que es adecuada.

1. Introducción2. Análisis3. Solución propuesta4. Diseño e implementación5. Demostración6. Conclusiones6. Conclusiones

7. Trabajo futuro


es adecuada.

� Se han identificado las políticas QoS más adecuadas para la transmisión de audio y vídeo. Como fruto de este trabajo se presentó un póster 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”

23/26

� Dada la arquitectura modular del sistema desarrollado, el código es altamente reutilizable.

1. Introducción2. Análisis3. Solución propuesta4. Diseño e implementación5. Demostración6. Conclusiones6. Conclusiones

7. Trabajo futuro


código es altamente reutilizable.

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

24/26

� Realización de test analíticos de escalabilidad

� Mayor soporte de codecs de audio

1. Introducción2. Análisis3. Solución propuesta4. Diseño e implementación5. Demostración6. Conclusiones7. Trabajo futuro7. Trabajo futuro


� Mejora de rendimiento alcanzado en audio

� Establecer método para la autenticación de usuarios

� Ampliar el soporte de fuentes de vídeo

25/26

Gracias por su atención

26/26

Gracias por su atención

1. Introducción2. Análisis3. Solución propuesta4. Diseño e implementación5. Demostración6. Conclusiones7. Trabajo futuroA1. CostesA1. Costes

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


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)

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)


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)


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


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

El modelo COCOMO II determina que el proyecto abordado supone un esfuerzo equivalente de 6,6 personas/mes durante 6,5 meses.

josé maría lópez vega [email protected] dirigido por juan...

Documents