MUSE BT - CLIENT Music Everywhere BlueTooth progetto Client Acquaviva Luca - 231767 Reti di Calcolatori LS AA 2007-2008.

Presentazione sul tema: "MUSE BT - CLIENT Music Everywhere BlueTooth progetto Client Acquaviva Luca - 231767 Reti di Calcolatori LS AA 2007-2008."— Transcript della presentazione:

1 MUSE BT - CLIENT Music Everywhere BlueTooth progetto Client Acquaviva Luca - 231767 Reti di Calcolatori LS AA 2007-2008

2 Music Everywhere Bluetooth MUSE BT - Client –Acquaviva Luca MUSE BT in 3 Parole: Bluetooth Mobilità Continuità Specifiche:  Erogare un servizio di audio streaming;  Utilizzo della tecnologia Wireless Bluetooth;  Mobilità attraverso le reti Bluetooth; Obiettivo:  Continuità del servizio a fronte di handoff orizzontali, rappresentati dallo spostamento del dispositivo da una cella ad un’altra.

3 MUSE BT – Sistema MUSE BT - Client –Acquaviva Luca  Entità del sistema:  Server mantiene i file audio mp3;  Proxy Mediatore tra client e server.  Access Point Accesso del client al proxy.  Dispositivo mobile (client); Riproduzione dello stream ricevuto dal proxy. Lan Bluetooth Lan Bluetooth Rtp proxy

4 handoff trasparente MUSE BT – Infrastruttura di Rete MUSE BT - Client –Acquaviva Luca AP Soluzione: uso di bridge sugli AP per uniformare La rete tra proxy e client. Soluzione: uso di bridge sugli AP per uniformare La rete tra proxy e client. AP Responsabilità dell’infrastruttura di rete : Trasparenza a livello di rete ; la comunicazione avviene sempre tra client e proxy indipendentemente dall’ap che fornisce copertura. Rtp

5 MUSE BT – Infrastruttura di Rete 2 MUSE BT - Client –Acquaviva Luca ETH0 PAN0 BNEP0 Proxy AP Soluzione PAN come bridge tra 2 interfacce ! Creazione dinamica dell’interfaccia BNEP alla connessione di un client. Collegamento dinamico tra PAN e BNEP alla creazione della bnep; Un AP gestisce 1 PAN e fino a 7 BNEP. Collegamento tra PAN e ETH dell’AP. Problema nascondere al proxy ed al client i vari AP per semplificare la comunicazione. Client Risultato il tutto viene visto come un’unica rete. Proxy e Client comunicano direttamente conoscendo solo i reciproci indirizzi IP. Risultato il tutto viene visto come un’unica rete. Proxy e Client comunicano direttamente conoscendo solo i reciproci indirizzi IP. IP Client IP Proxy

6 Soluzione Proposta CLM & NCSOCKScome infrastruttura di supporto:  Mobility Management: gestione degli handoff che occorrono nel passaggio da un Access Point ad un altro (CLM)  Connection Awareness: conoscenza di tutte le informazioni circa lo stato attuale della connessione (qualità del segnale, probabilità di handoff) (NCSOCKS) Comunicazione:  Protocollo UDP, socket datagram offerte da NCSOCKS. Garanzia di Continuità:  Buffer sul Client che permette la riproduzione durante la situazione di handoff e di disconnessione dal proxy. MUSE BT - Client –Acquaviva Luca

7 CLM MUSE BT - Client –Acquaviva Luca  Mobility Management: Demone lato mobile che monitora costantemente l’area di copertura del device in cerca di AP, e che decide a quale connettersi in base:  Potenza del Segnale.  Banda disponibile.  Risultato: handoff trasparenti al client, eseguiti interamente dal CLM.

8 NCSOKCS Supporto per l’Applicazione Client che Offre: Connection Awareness: conoscenza delle informazioni relative allo stato della connessione.  primitive di comunicazione che considerano lo stato della comunicazione (estensione socket datagram) UDP.  funzionalità di notifica delle informazioni di stato della connessione e della probabilità di handoff (Connection Monitor) rilevate dal CLM. MUSE BT - Client –Acquaviva Luca

9 Client - Buffer Circolare MUSE BT - Client – Acquaviva Luca Buffer Circolare Client  Permette la riproduzione durante i vari handoff : continuità del servizio. Oltre la continuità  Riduzione Problemi dovuti al Jitter : sfruttando il ritardo di esecuzione introdotto dal buffer.  Ordinamento frame oltre UDP: I frame ricevuti dal client vengono memorizzati in un buffer circolare ordinandoli in base al loro numero di sequenza, risolvendo la limitazione di UDP.

10 Client - Responsabilità MUSE BT - Client –Acquaviva Luca  Responsabilità Client:  Attivare la sessione di comunicazione con il Proxy.  Inviare le richieste delle traccie.  Concorrentemente Ricevere e riprodurre lo stream audio, utilizzando un buffer circolare per garantire la continuità del servizio durante gli handoff. Monitorare lo stato della connessione gestendo e notificando eventuali handoff.

11 Client - Handoff Management Problema : Il proxy non è supportato da NCSOCKS e non ha alcuna informazione sullo stato della connessione del client. Soluzione: monitorare la connessione lato cliente per fare notificare il proprio stato al proxy.  Notifica Probabile handoff (incremento buffer proxy).  Notifica inizio handoff (Sospensione Trasmissione)  Notifica Riconnessione, fine handoff. (Ripresa Trasmissione). MUSE BT - Client – Acquaviva Luca CLM NCSOCKS APPL. CLIENT Proxy Shared memory

12 Client - Interazione Client/Proxy MUSE BT - Client – Acquaviva Luca Rtp Dopo una fase iniziale di inizializzazione della sessione. Stream emesso dal server verso il proxy via rtp. Proxy inoltra frame per frame tutto lo stream direttamente al client. Client bufferizza i dati in arrivo e riproduce lo stream  Buffer Circolare per Continuità del Servizio e Riduzione del Jitter. AP Variante cosa succede se durante la trasmissione avviene un handoff !?

13 Client - handoff !! MUSE BT - Client – Acquaviva Luca Durante la normale erogazione del servizio il client si sposta.  Client : rileva alta probabilità di handoff e la notifica al Proxy.  Proxy: aumento dinamico del buffer.  Client: Inizio handoff notifica al proxy.  Proxy: interruzzione della trasmissione ed attesa di Riconnessione. Rtp AP Durante la normale erogazione del servizio il client si sposta.  Client : Richiesta di Riconnessione il sequence number dell’ultimo frame correttamente salvato.  Proxy: Preparazione alla trasmissione a partire dall’ultimo frame ricevuto dal Cliente.  Proxy: Invio di un ack al client.  Client: invio di un ack al proxy.  Proxy: Ripristino trasmissione.

14 Client – Test Andamento del Buffer MUSE BT - Client – Acquaviva Luca Andamento del Buffer del Client durante una prova. Prova : erogazione di uno stream audio con handoff ripetuti. Risultato: Continuità del servizio ed evidenza di qualche problema di incertezza di NCSOCKS. Fase 1 Precaricamento Buffer.Fase 2 Inizio Riproduzione.Fase 3 handoff e riconnessione al nuovo AP. Inizio handoff : Sconnessione temporanea dal proxy. Fine handoff: Riconnessione al proxy.

15 Conclusioni  Pro  Semplificazione dello sviluppo dell’applicazione.  Handoff trasparenti allo strato applicativo.  Handoff eseguti in tempi limitati, Risparmio di risorse per la bufferizzazione.  Contro  Riscontro di problemi di incertezza nell’inizio di un handoff.  Distribuzione limitata vincolata a sistemi linux.  Difficilmente installabile su dispositivi mobili pda e smartphone. MUSE BT - Client – Acquaviva Luca Obiettivo parallelo valutazione di ncsocks.

16 Client - Sviluppi Futuri MUSE BT - Client –Acquaviva Luca  Estensione ed Inserimento di controlli per il flusso audio;  Adattamento del servizio in base al device;

17 Client MUSE BT - Client – Acquaviva Luca Fine