presentacion final

24
TV P2P STREAMING TV P2P STREAMING PRESENTACIÓN FINAL - IST -

Upload: didac-montero

Post on 26-Jun-2015

115 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Presentacion final

TV P2P STREAMINGTV P2P STREAMINGPRESENTACIÓN FINAL

- IST -

Page 2: Presentacion final

Índice� Introducción

� Esquema general

� Elementos del sistema

� Tracker

� Fuente

� Peer� Peer

�Web y Base de datos

�Substreams

�Buffering

�Scheduling

�Protocolo

�Actualizaciones

�Conclusiones

Page 3: Presentacion final

Esquema general

• Una fuente emite un video y para ello informa al tracker sobre la

existencia de un nuevo canal.

• Los peers obtienen la lista de canales del tracker y

posteriormente la lista de peers de un canal del mismo.

Page 4: Presentacion final

Elementos del sistemaTracker

Aporta a los peers la información mínima para el correcto funcionamiento de estos.

• Centralizado. Pueden existir trackers de back-up.

Elementos del tracker:

Variable Descripción

String name Nombre del canal.

Timer t Ejecuta periódicamente la comprobación de usuarios.

Int bitrate Bitrate del video.

String desc Descripción del canal.

Int num_Peers Número de Peers que dispone ese canal.

Boolean cifrado Indica si en canal está cifrado o no.

Stringmethod Indica el paquete con el que ciframos el canal.

Vector clientsV Lista de los Peers conectados a ese canal.

Variable Descripción

InetAdress IP IP pública del usuario.

Int priority Prioridad asociada al usuario.

Byte buid UID de ese usuario.

Usuario 1

Canal 1

Page 5: Presentacion final

Elementos del sistemaTracker

Funciones (implementadas con nuestro protocolo):

-Añadir canal.

-Actualizar canal.

- Generar UIDs para los peers.

-Añadir un peer a un canal.

-Eliminar un peer de un canal.

-Actualizar lista de peers.

Además, los peers pueden consultar al tracker para aumentar su lista.

Page 6: Presentacion final

Elementos del sistemaWeb

• Centralizado.

• Dinámico � Servlets y JSP.

• Seguro � Utilización de SSL (librerías OpenSSL).

• Restringido � Utilización de filtros.

Servicios Web:

- Autenticación de usuario, necesaria para descargar la aplicación y para obtener las distintas contraseñas de cifrado.

- Registro de usuario, necesario para poder autenticarse.

- Acceso seguro a la base de datos de usuarios a través de un Servlet.

Page 7: Presentacion final

Elementos del sistemaWeb

Base de datos (MySQL):

• Almacenamiento de los datos persistentes: datos de los usuarios.

Datos de cada usuario:

Variable Descripción

String Login Nombre con el que el usuario se autenticará. Campo único ya que identifica al restoString Login Nombre con el que el usuario se autenticará. Campo único ya que identifica al resto

(primary key)

String Pass Contraseña del usuario.

String Nombre Nombre del poseedor de la cuenta.

String Apellidos Apellidos del poseedor de la cuenta.

Int Prioridad [0-6] Elegida según la velocidad de subida del usuario (introducida en el formulario de

registro). Mayor número de prioridad indica mayor velocidad de subida.

Int Paquete [0-3] Hace referencia al tipo de seguridad o niveles de acceso que tiene ese usuario

(introducido en el formulario de registro). 0=sin acceso a cifrado. 3=acceso a todos los

paquetes de cifrado.

Page 8: Presentacion final

Elementos del sistemaWeb

Servlets:

• Generación de respuestas dinámicas a distintos parámetros de una petición.

Autenticación: El método GET verifica login y passwords a través del acceso a la BD. El método POST verifica el registro de un usuario (que no exista ese nombre) y lo añade a la base de datos.lo añade a la base de datos.

AutenticaciónJava: Intermediario seguro entre la aplicación y la BD. Responde a una petición GET del tipo: “htpps://IP_WEB/Proyecto/Login=login_usuario&Pass=Pass_usuario”. La respuesta será la contraseña asociada al paquete que el usuario login_usuario se ha registrado.

DeleteSesion: Utilizado para salir de una sesión. Borra los atributos de una sesión, para conectarnos a otra.

Page 9: Presentacion final

Elementos del sistemaPeer

Usuario del sistema que es a la vez cliente y servidor�recibe el flujo de video y a la vez puede enviarlo.

Elementos del peer:

ClientMM: Tabla indexada a partir del UID que contiene la información necesaria de cada peer.de cada peer.

ClientRS: Tabla indexada a partir del UID+substream que contiene la información necesaria de cada peer+threads de envío+threads de recepción.

UID1 PeerInfo1

UID2 PeerInfo2

UID3 PeerInfo3

UID1 + substream RemotePeer1

UID2 + substream RemotePeer2

UID2 + substream RemotePeer2

UID3 + substream RemotePeer3

Page 10: Presentacion final

Elementos del sistemaPeer

Dispone de tantas colas finitas como substreams haya.

Tiene una Heap para ordenar los chunks.

Modos de funcionamiento:

Normal: El peer recibe los chunks y los envía a la Heap, que es la encargada de Normal: El peer recibe los chunks y los envía a la Heap, que es la encargada de ordenarlos para su correcta reproducción. Puede, a su vez, servir a otros peers.

Relay: El peer recibe los chunks pero no los reproduce ni los envía a la Heap. Los mantiene en la cola finita para servir a otros peers. Puede mantener en la cola chunks cifrados aunque no conozca la clave; actúa de intermediario.

Page 11: Presentacion final

Elementos del sistemaFuente

Usuario del sistema que hace de servidor.

• Encargado de generar un canal.

• Encargado de fragmentar el flujo de video en chunks y de asignarle números de secuencia.

Elementos de la Fuente:

Dispone de la ClientRS pero no de la clientMM.

Dispone de una cola finita pero no de la Heap.

Page 12: Presentacion final

Substreams

Conjunto de fragmentos de un flujo.

Nos permite obtener el video de diferentes nodos a la vez.

En nuestro proyecto, el flujo de video, está dividido en 4 substreams.

Elección de substreams:

Compromiso entre el retardo, la tasa del vídeo y la carga de la aplicación.

A mayor número de substreams:

tasa de subida.

retardo.

carga en la aplicación (cada substream, dos Threads más).

Page 13: Presentacion final

Buffering…Cola finita

•Lugar donde se irán almacenando los Chunks recibidos.

• Cola FIFO. Sale un Chunk de la cola cuando se empuja fuera de ésta , es decir, cuando la cola está llena y llega otro Chunk.

•Fuente solo tiene una, en cambio los peers una por cada substream.•Fuente solo tiene una, en cambio los peers una por cada substream.

•Las chunks de las colas no tienen porqué superponerse.

Page 14: Presentacion final

Buffering…

Heap

•Cola infinita ordenada.

•Una por cada uno de los peers

•Cada nodo padre tiene un valor inferior que el de todos sus nodos hijos.

•Procedimiento para añadir a esta cola será el siguiente:

1. Esperar a tener Chunks en cada cola finita

2. Guardamos el primer ID de cada cola

3. Compararemos IDs y elegimos el mayor

4. Se añaden a la Heap los Chunks que cumplen: ID > LastID – Nº de substreams

Page 15: Presentacion final

Buffering…Heap

• Ejemplo:

•Retardo añadido por sincronización de las colas:

Page 16: Presentacion final

Scheduling

Peer genera un mensaje INTERRUPT hacia sí mismo cuando es necesaria una adaptación. Causas de adaptación:

-Desconexión de un padre (Recibimos un BYE).

-Caída inesperada de un padre (Expira el Timeout).

-Tasa de subida de un padre inferior a la esperada (Expira el Timeout).

Ante un mensaje INTERRUPT:

1 – El Peer detiene el Thread del VLC.

2 – Regenera la Heap.

3 – Se conecta a un miembro de la ClientsMM. (No la añade a la ClientsRS hasta tener la conexión establecida.

Durante la adaptación se resetea el sistema, por lo tanto se pierde la continuidad a la hora de reproducir en un momento determinado.

Page 17: Presentacion final

Cifrado

Algoritmo escogido para cifrar: “PBEWithMD5AndDES”,motivos:

•Cifrado basado en Password, nos permite controlar aquellos usuarios quetengan acceso a los canales cifrados.

•Compromiso entre el nivel de encriptación con la carga que pueda sometereste algoritmo a la hora de cifrar (fuente) y descifrar (Peers).

•El nivel de seguridad que nos proporciona para una aplicación de estas

Teniendo en cuenta que puede a ver routers que únicamente hagan de relay, y eltratamiento de los paquetes en las colas, solo viajará cifrado el campo de datos.

•El nivel de seguridad que nos proporciona para una aplicación de estascaracterísticas es suficiente.

Page 18: Presentacion final

Protocolos (TCP)Se comentaran los mensajes más importantes.

CLS_JOIN_UID_SUBSTREAM_DATAPORT

Respuestas:

Fuente Peer

CLS_JOIN_UID_SUBSTREAM_DATAPORT

Mensaje para conectarse a un peer.

RESPUESTARespuestas:

�OK 200� Agregado.

�CIPHER_coded� Agregado a un canal cifrado.

�ERROR 300� Eres un Peer y no tienes la colacon los substreams que te ha pedido.

�ERROR 310�Tiene la cola pero está vacía.

Page 19: Presentacion final

CLS_LST_ID

PeerTracker

CLS_LST_ID

RESPUESTA

Respuestas:

•ERROR 504� No hay canales emitiendo.

Protocolos (TCP)

•ERROR 504� No hay canales emitiendo.

•OK 260� La lista no ha cambiado respecto a laconsulta anterior.

•CLS_LISTCHAN_ID� ID que tiene el Trackery toda la lista de canales.

ID = Identificador que el Tracker incrementa por cada cambio que haya en su lista de canales.

El peer empieza con el ID a cero y tras cada consulta es actualizado al valor del ID del tracker.

Page 20: Presentacion final

CLS_BYE_UID

CLS_BYE_UID

Peer o Fuente Peer

Protocolos (TCP)

Mensaje generado al desconectarseun peer.

CLS_LISTPEERSUID1_IP1_Prioridad1UID2_IP2_Prioridad2UID3_IP3_Prioridad3ENDLIST

un peer.

Lista de peers de los que el peer con intención de desconectarse estaba recibiendosubstreams.

Page 21: Presentacion final

Actualizaciones (UDP)

CLS_KEEPALIVE

PeerFuente o Peer

OK

CLS_KEEPALIVE

CLS_KEEPALIVE

Peer Tracker

OK

Mensaje periódico que envía unpeer para comprobar que otropeer sigue activo.

Mensaje periódico que envía eltracker para comprobar que lospeers que tiene siguen activos.

Page 22: Presentacion final

Actualizaciones (UDP)

CLS_SENDACK_UID-SUBSTREAM

Peer o FuentePeer

CLS_SENDACK_UID-SUBSTREAM

Mensaje enviado tras recibir quince chunks de un peer.

Permitirá al Peer que envia el substream, darse cuenta de que el peer receptor

se ha caído.

Page 23: Presentacion final

Conclusiones…• Sistema descentralizado en cuanto los usuarios sean mayor o igual al número desubstreams.

• Funcionamiento de la aplicación depende de la conexión de cada usuario.

• Adaptación� Obligación de reseteo del sistema.

• Objetivos logrados:

� Correcto funcionamiento del sistema básico.� Correcto funcionamiento del sistema básico.

� Cifrado de múltiples canales.

� Actualización periódica de las listas de peers, tanto en el tracker como en los nodos.

� Adaptación por desconexión explícita o implícita (caída del peer) y por jitter.

�Web dinámica, segura y con acceso restringido.

� Interfaz gráfica amigable.

Page 24: Presentacion final

Conclusiones…•Posibles mejoras:

� Atravesar NATs para que el sistema funcione en cualquier entorno.

� Adaptación � recepción de chunks distantes (id).

� Descentralización � Inicialmente, primer peer recibe todos los substreams de la fuente. Tras un tiempo adaptarse y recibir de distintos peers.

� Transcodificación� Conseguir una tasa de reproducción fija para cualquier video.

� Campo de prioridad (implementado pero no utilizado) � utilizarlo con el fin de mejorar la conexión de los peers.