José María López Vega Dirigido por Juan

Transcripción

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
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ón
2. Análisis
3. Solución propuesta
4. Diseño e implementación
5. Demostración
6. Conclusiones
7. Trabajo futuro
Introducción
1.
1.
2.
3.
Análisis
2.
1.
2.
4.
1.
2.
3.
4.
5.
6.
7.
Requisitos de la aplicación
Otras decisiones
Solución propuesta
Diseño e implementación
3.
5.
Definiciones básicas
Estado del arte
Definición del problema
Arquitectura del sistema
Políticas de QoS incorporadas
Descripción IDL
Comunicación con cámara IP
Gestión de audio
Demostración
Conclusiones
Trabajo futuro
3/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Middleware
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
Paradigma de publicación/subscripción
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.
dataspace
4/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Data Distribution Service (DDS)
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
Group).
1
1
Tópico
Publicador
1
Subscriptor
*
*
DataWriter
Entidades
DDS
1
*
Publicación
Subscripción
DataReader
*
5/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Políticas de QoS (Quality of Service)
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
fiable, con lo que se reduce la complejidad del sistema.
6/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Videoconferencia
Comunicación simultánea bidireccional de audio y vídeo,
permitiendo mantener reuniones con grupos de personas situadas
en lugares alejados entre sí.
Otras definiciones relativas a videoconferencia
Sala
Moderador
Descubrimiento
Entorno virtual aislado en los que un conjunto de
usuarios intercambian mensajes de texto, voz, vídeo, etc.
Usuario con privilegios especiales. Por ejemplo, determinar qué
usuario puede hablar en cada momento.
Procedimiento por el que el usuario obtiene una lista de las salas
disponibles.
7/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Videoconferencia
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.)
Por lo general, orientación cliente-servidor
Middleware DDS
Tecnología en pleno auge.
Implementaciones existentes: RTI DDS,
OpenSplice, CoreDX, OpenDDS, MilSOFT.
8/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Deseamos desarrollar un sistema de trabajo
colaborativo, con soporte para videoconferencia
entre distintos clientes remotos.
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
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
La aplicación ha de ser multiplataforma o, al
menos, portable.
Debe ser fácilmente extensible.
Se recomienda que sea modular.
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
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Desarrollo en Java
Multiplataforma, prototipado rápido, Javadoc.
Entorno de desarrollo Eclipse
Herramienta de código abierto muy potente,
extensible mediante sistema de plugins.
Códec de audio SPEEX
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.
11/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
12/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
13/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
DEADLINE Y TIME_BASED_FILTER
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.
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 datawriters
de la situación, para que reduzcan de forma remota la calidad del
stream de vídeo.
14/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Subscripción
Vídeo
Notificar al
sistema que
no hay
problemas
Control
Sistema
Publicación
Señalización
Decrementar TBF y
DEADLINE en un 20%, si
son superiores al valor
mínimo establecido.
Mediante el tópico de
señalización, se indica
al resto de sistemas que
no hay problemas en la
recepción.
15/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Subscripción
Vídeo
Notificar al
sistema que
hay problemas
Control
Sistema
Publicación
Señalización
Incrementar TBF y
DEADLINE al doble de su
valor, si son menores
que el valor máximo
permitido.
Mediante el tópico de
señalización, se indica
al resto de sistemas que
hay problemas en la
recepción.
16/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
LIVELINESS
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.
PRESENTATION
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.
LIFESPAN
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.
17/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
OWNERSHIP Y OWNERSHIP_STRENGTH
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
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
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
19/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
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
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
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
JMF (Java Media Framework)
Gran variedad de codecs, versiones para cada plataforma,
librería externa, permite personalizar transporte bajo RTP, pero
no sustituir RTP.
Java Sound
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.
21/26
1.
2.
3.
4.
5.
6.
Se iniciará la aplicación.
Se creará una sala pública.
Se iniciarán/detendrán publicaciones
de audio y vídeo.
Se mostrará el mecanismo de
adaptación a las condiciones de
congestión.
Se describirá el funcionamiento del
mecanismo de moderación.
Se creará una sala privada.
22/26
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
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.
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
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Dada la arquitectura modular del sistema desarrollado, el
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
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
Realización de test analíticos de escalabilidad
Mayor soporte de codecs de audio
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
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
A1. 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
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
A1. Costes
Parámetro
Número de líneas nuevas
Experiencia en la temática del proyecto
Flexibilidad de desarrollo
Arquitectura/Resolución de riesgos
Cohesión de equipo
Madurez del proyecto
Fiabilidad requerida
Tamaño base de datos
Valor
6000
Alta (H)
Máxima (XH)
Normal (N)
Máxima (XH)
Alta (H)
Normal (N)
Bajo (L)
Complejidad del producto
Normal (N)
Reusabilidad
Normal (N)
Documentación
Normal (N)
Porcentaje tiempo ejecución
Porcentaje tiempo almacenamiento
Variabilidad de la plataforma
Alto (H)
Normal (N)
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)
1. Introducción
2. Análisis
5. Demostración
6. Conclusiones
7. Trabajo futuro
A1. Costes
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
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 Dirigido por Juan

Transcripción

Documentos relacionados

San Benito Health Foundation Centro Comunitario de Salud 351

We`re in the Business of Children`s Smiles

La familia de excitadores/transmisores de la serie ADVANCAST