MUSE2
Progetto di un servizio di audio
streaming in reti wireless
Reti di Calcolatori L-S
Autore: Andrea Bergamini
Progetto in collaborazione con Bambini Stefano e Pierangeli Diego
1
Bologna, 2/11/2006
Sommario
Target Progettuale
► Architettura generale del sistema
► Analisi dell’entità Client
► Gestione dell’Handoff
► Protocolli adottati
► Conclusioni e sviluppi futuri
►
2
Target progettuale
►
Realizzazione di una applicazione distribuita per lo
streaming di contenuti audio in reti wireless IEEE
802.11 (Wi-Fi) verso un dispositivo mobile
Gestione opportuna di un possibile handoff del
dispositivo
► Realizzazione di una infrastruttura di supporto quanto
più flessibile e scalabile
► Interesse prevalente nella logica e nell’implementazione
dell’architettura del client
►
3
Architettura del sistema
Server
Manager1
Manager2
SUBNET2
SUBNET1
Proxy1
Proxy2
Client
4
Analisi dell’entità Client
Il Client si occupa di interfacciarsi all’end-user
fornendo ad esso contenuti audio
► Deve garantire la continuità della sessione anche a
fronte di handoff (che può anche prevedere
disconnessioni di durata limitata)
►
E’ possibile avere una previsione sempre corretta della sua migrazione?
Quali provvedimenti adottare in caso di previsione errata?
► Bisogna
effettuare delle scelte progettuali precise in
fase di analisi
► A livello implementativo, client realizzato su
piattaforma Java standard (J2SE+JMF)
5
Analisi dell’entità Client
Comunicazione
Interazione del client con i contenuti del server mediata da un proxy
(creato da un manager, responsabile di quella subnet)
Due livelli:
► RTP / RTCP per il trasporto dei frame audio
► UDP per garantire coordinamento tra le entità (attraverso un
protocollo ad-hoc)
RTP / RTCP
Client
Proxy / Manager
UDP
Wi-fi
6
Analisi dell’entità Client
Interfacciamento con
proxy / manager della
subnet
Monitoraggio
Ricezione pacchetti
dell’handoff,
audio
grazieeall’uso
riempimento
di un predittore,
di
un
chebuffer
cerca circolare
di predirre uno
spostamento del client da
subnet
a subnet
Buffer con
struttura
a ring:
● Scritture e letture mediante
due puntatori (head e tail).
Estrazione
pacchetticritiche
● Gestione
di di
situazioni
dal buffer
e inoltro al JMF
con
condizionamento
del flusso
per la presentazione
in ingresso
● Estensione del componente
unibo
Interfacciamento con l’utente
finale per la riproduzione dei
contenuti audio
Wireless Interface
Handoff Monitor
Parser
Predictor
Circular
Buffer
Client
Multiplexer
User Interface
7
Protocollo di attivazione del Client
E’ il protocollo che gestisce, in una fase iniziale, l’ingresso di un
client in una subnet, e che permette ad esso di iniziare lo streaming
audio
►
Il Client contatta il Manager di quella subnet
per farsi creare un proxy a lui dedicato: uso di
una tabella (conoscenza statica)
Erogazione dei contenuti dal
server al client attraverso la
mediazione del proxy
SUBNETn
Managern
Proxyn
<<CREATE>>
NEW_STREAM_
REQUEST
Server
CREATE_FIRST
_PROXY
Client
Subnet Manag.
SUB1
x.x.x.x
SUB2
x.x.x.x
…
Client
…
8
Predizione di Handoff




Obiettivo: intervenire in modo opportuno o a fronte di un’handoff del
client, o a fronte di una previsione di handoff.
Il dispositivo client, facendo uso dell’HandoffMonitor, stabilisce
politiche di gestione dell’handoff, secondo due modelli: proattivo e
reattivo.
Due protocolli per la gestione dell’handoff, a seconda che il predittore
effettui una predizione corretta, oppure sbagliata (rientra in
quest’ultimo anche il caso che il predittore non effettui nessuna
predizione!).
Ad intervalli regolari, l’HandoffMonitor rileva (mediante JWRAPI) l’AP
al quale il client è correntemente connesso. La variabile initialAP
contiene il MAC dell’AP al quale il client è connesso inizialmente.
Se viene rilevato un AP diverso da quello della variabile, ho avuto
Handoff → protocollo di predizione sbagliata.
9
Predizione di Handoff




A fronte di una previsione di migrazione individuata dal predittore (per una
subnet diversa da quella in cui il client risiede), viene instaurato un
opportuno protocollo di handoff, secondo un modello proattivo.
Se dopo un timeout (custom), il MAC dell’AP al quale il client è attualmente
connesso (rilevato dall’HandoffMonitor) coincide con quello impostato
nella variabile initialAP, la predizione è sbagliata: nessuno spostamento
effettivo del client.
Se invece è diverso, vengono instaurati due diversi protocolli, di previsione
corretta o errata, a seconda che l’AP rilevato dal predittore coincida o
meno con quello al quale il client è attualmente connesso (individuato
dall’HandoffMonitor).
Nel primo caso, grazie ad una previsione corretta, e al modello proattivo,
rispondiamo in modo immediato alle richieste di flusso del client. Nel
secondo caso invece, il protocollo di previsione errata permette, in modo
reattivo, di “preparare” la rete di destinazione ad ospitare il client (gestendo
anche il suo “deficit” di pacchetti).
10
Previsione di Handoff corretta
Continuità dello
Rilevazione
del predittore
streamingdiaudio
Streaming
audio
nella
Migrazione
Trasferimento
del client
del
buffer
nella
una possibile
anche
a frontemigrazione
di disconnessioni
subnet la predizione
nuova
proxy-to-proxy
sottorete:
verso laadSUBNET2
grazie
un livello di
era corretta
bufferizzazione sul client
Avvertimento al proxy, per
fargli iniziare il protocollo di
handoff
SUBNET2
STREAM_
Manager2
REQUEST
Server
NEW_PROXY
_SUBNET
SUBNET1
Manager1
Proxy2
<<CREATE>>
NEW_PROXY
_RESPONSE
Proxy1
Manager3
NEW_AP
(SUBNET2)
Client
SUBNET3
11
Previsione di Handoff errata
Il client migra verso una
Il
Protocollo
Client contatta
di predizione
il Manager
sottorete
diversa
da
quellaerrata
della
(semplificato)
nuova
rete per farsi
rilevata
dal predittore:
grazie alla
creare
un Proxy
a lui dedicato
rilevazione
dell’HandoffMonitor
SUBNET2
Manager2
Bisogna adottare politiche
adeguate
Proxy2
Server
PROXY_END
STREAM_
REQUEST
SUBNET1
Manager1
Proxy1
Manager3
PREDICTION
_WRONG
Proxy3
<<CREATE>>
NEW_PROXY
Client
SUBNET3
12
Conclusioni e Sviluppi Futuri



La sessione sul client è garantita a fronte di un handoff
Dai benchmark effettuati si è riscontrato un buono
streaming sul client senza interruzioni nell’ascolto, anche a
fronte di handoff multipli.
Le scelte progettuali adottate garantiscono estendibilità e
flessibilità al sistema
Sviluppi futuri:
 Coinvolgimento nel sistema di più entità client (non testato
ma predisposizione dell’infrastruttura all’accettazione)
 Estensione dell’interfaccia utente per permettere la scelta del
brano ad un utente
→ DEMO
13