2
MUSE WIFI
MUSic Everywhere with
WIFI
presentazione di
Membri del gruppo:
Pierangeli Diego
Bambini Stefano
Bergamini Andrea
AA 2006/2007
Pierangeli Diego
Overview

Scenario Applicativo

Architettura proposta

Analisi del componente Server

Analisi del componente Proxy

Protocolli di Migrazione

Conclusioni e Sviluppi Futuri
Scenario Applicativo
Rete 1
Rete 2
Flusso audio
PROXY 2
PROXY 1
Server
Handoff
Handoff trasparente all’utente
Client
Architettura - Componenti
CLIENT
PROXY-MANAGER
PROXY
Applicazione installata su un terminale
mobile che riceve il flusso audio e lo
presenta all’utente
Entità presente su ogni sottorete, ne è il gestore
centralizzato e si occupa della creazione e
gestione dei Proxy
Intermediari tra il Client ed il Server, gestiscono
la trasmissione del flusso audio e la sua
bufferizzazione, inoltre si coordinano con i
Manager ed il Client durante la migrazione
Sono creati dinamicamente alla connessione del
Client o durante il protocollo di migrazione
SERVER
Entità che trasmette il flusso audio ai vari Proxy
Architettura - Schema
Risiedono sulla stessa macchina
RETE PUBBLICA 2
RETE PUBBLICA 1
Buffer
RETE PRIVATA
PROXYMANAGER 2
PROXY 1
PROXYMANAGER 1
Server
Tabella statica
rete
IP
manager
Buffer
Client
Comunicazione tra le entità
Utilizzo del protocollo RTP per trasmettere il flusso audio
Real-Time Control Protocol (RTCP), per monitorare la qualità
del servizio e fornire informazioni sui partecipanti di una
sessione RTP in atto
Ma..
Il supporto java all’RTP (Java Media Framework) non permette
di sfruttare i pacchetti che RTCP mette a disposizione per
trasmettere dati Application Specific (pacchetti APP) quindi..
È stato necessario sfruttare una ulteriore connessione di
controllo per inviare i messaggi applicativi necessari ai protocolli
di gestione dell’Handoff
Flusso audio
RTP
Flusso di controllo
Server
Struttura basata su Thread:
Thread principale
• è in attesa di messaggi
• crea i Thread secondari
Thread secondari
• gestiscono la connessione RTP e l’invio dello Stream
• ridirige un flusso RTP cambiandone destinatario
Thread principale
Thread Secondario
New Stream Request
Change Destination
X
DATA SOURCE
Componente
che si
Astrazione della
occupa
di gestire
sorgente
dati la
trasmissione RTP
RTP-Trasmitter
Flusso RTP
Proxy
Strutturato su più Thread:
Legge i frame RTP dal Buffer e li
invia al Client tramite una
connessione RTP
Thread di controllo, riceve i
messaggi applicativi e
gestisce la creazione degli
altri Thread ed il protocollo
di migrazione del Client
Connessione
RTP Client
MultiplexerThread
ProxyControl
buffer
Legge i frame RTP dalla
connessione e li inserisce
nel Buffer
ParserThread
Messaggi di controllo
Connessione
RTP Server
Buffer
Il componente Buffer è necessario per ritrasmettere al Client
eventuali Frame RTP persi durante la disconnessione
È un Buffer circolare con 2 puntatori: HEAD: cella da cui è
leggere due metodi
Ipossibile
proxy prevedono
TAIL:
cella in cuidiètrasmettere
che
permettono
epossibile
ricevere scrivere
il Buffer attraverso
FRAME 1 FRAME 2
la
privata che
e che
sono la
È rete
necessario
durante
invocati
dai rispettivi
Manager
migrazione
il Buffer sia
FRAME 3
durante
protocollo
trasferitoil tra
il Proxydidella rete
gestione
migrazione
iniziale e della
quello
della rete
FRAME 4
FRAME 5
La lettura e la scrittura
aggiornano i puntatori
finale
Soluzione: estendere il
CircularBuffer del java in
modo che sia serializzabile
e poi trasmetterlo attraverso
una connessione TCP
Handoff
Come viene gestito l’evento di Handoff?
PREDITTORE
HANDOFF
MONITOR
il predittore sul Client monitora i segnali che riceve dai vari AP ed è
in grado di segnalare al Proxy un possibile Handoff..
APPROCCIO PROATTIVO!
Prepariamo il supporto per gestire l’evento PRIMA che l’handoff si
verifichi
Esiste un altro protocollo che gestisce il caso di predizione errata
(protocollo REATTIVO; copre anche il caso di nessuna previsione)
Protocolli di Migrazione
PREDIZIONE CORRETTA
Sottorete 1
Il Ilpredittore
sul client
un possibile
Ilvecchio
nuovo
client mobile
proxy
proxy
segnala
cambia
puòrileva
terminare
al
sottorete
vecchio
handoff
e segnala
la previsione
Buffer
viene
tra
proxy
avvia
iltrasferito
protocollo
proxy
l’esecuzione
eIlcontatta
che
lail predizione
nuovo
proxy
era
peri al
proxy
identificatore
due
proxy la
perinsieme
gestire
migrazione
corretta
farsi
inviare
ilall’
flusso
audio della
rete su cui prevede che avverrà la
riconnessione
L’infrastruttura è pronta per
eseguire nuovamente il protocollo
di Handoff!
Manager 1
Proxy 1
NEW_AP(SUB2)
Client
server
<<NEW INSTANCE>>
Proxy 2
Manager 3
Manager 2
Sottorete 2
Sottorete 3
Protocolli di Migrazione
PREDIZIONE ERRATA
Sottorete 1
Manager 1
Proxy 1
Client
IlSegnalazione
Client
La predizione
contatta
siil Manager
rivela
errata:
il Client
Terminazione
Trasferimento
del
Buffer
dell’errata
Proxy
e invio
errato
previsione
deldella
eflusso
del
nuova
migra
rete
verso
perProxy
una
farsirete
creare
diversa
un nuovo
da
bufferizzato
Proxy
iniziale
dal
al Client
Proxy
quella prevista
L’infrastruttura è pronta per gestire un
nuovoProtocollo
Handoff! REATTIVO : bisogna
trasformare l’infrastruttura per
garantire la fruizione del servizio
all’utente
server
Proxy 2
Manager 2
CHANGE_DESTINATION
<<CREATE>>
Manager 3
Proxy 3
Sottorete 2
Sottorete 3
Conclusioni e Sviluppi Futuri
• Il sistema progettato ed implementato garantisce la continuità della
fruizione di un flusso audio da parte di un utente a fronte di un
Macro Handoff.
• Dai test effettuati si è riscontrato un buono streaming sul client
senza interruzioni nell’ascolto.
• Componenti Manager,Proxy e Server portabili su qualunque
architettura.
Sviluppi futuri:
• Creazione di un interfaccia grafica per permettere la scelta del
brano ad un utente.
• Permettere la creazione dei Proxy su macchine differenti da quelle
che ospitano i Manager.
• Replicazione delle risorse.