MUSE 2 WIFI MUSic Everywhere with WIFI presentazione di Pierangeli Diego Membri del gruppo: Bambini Stefano Bergamini Andrea Pierangeli Diego AA 2006/2007

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 Handoff PROXY 2 Server Client PROXY 1 Flusso audio Handoff trasparente all’utente

Architettura - Componenti SERVER CLIENT PROXY PROXY-MANAGER Entità che trasmette il flusso audio ai vari 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

Architettura - Schema PROXY- MANAGER 2 Server PROXY- MANAGER 1 RETE PRIVATA RETE PUBBLICA 2 RETE PUBBLICA 1 Client reteIP manager Tabella statica PROXY 1 Buffer Risiedono sulla stessa macchina

Comunicazione tra le entità Utilizzo del protocollo RTP per trasmettere il flusso audio 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 Real-Time Control Protocol (RTCP), per monitorare la qualità del servizio e fornire informazioni sui partecipanti di una sessione RTP in atto 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 principaleThread Secondario New Stream Request DATA SOURCE Astrazione della sorgente dati RTP-Trasmitter Componente che si occupa di gestire la trasmissione RTP Flusso RTP Change Destination X

Proxy ParserThread MultiplexerThread buffer Connessione RTP Server Connessione RTP Client ProxyControl Messaggi di controllo Strutturato su più Thread: Thread di controllo, riceve i messaggi applicativi e gestisce la creazione degli altri Thread ed il protocollo di migrazione del Client Legge i frame RTP dalla connessione e li inserisce nel Buffer Legge i frame RTP dal Buffer e li invia al Client tramite una connessione RTP

Buffer Il componente Buffer è necessario per ritrasmettere al Client eventuali Frame RTP persi durante la disconnessione HEAD TAIL FRAME 1 FRAME 2 FRAME 3 FRAME 4 FRAME 5 È un Buffer circolare con 2 puntatori:HEAD: cella da cui è possibile leggere TAIL: cella in cui è possibile scrivere È necessario che durante la migrazione il Buffer sia trasferito tra il Proxy della rete iniziale e quello della rete finale Soluzione: estendere il CircularBuffer del java in modo che sia serializzabile e poi trasmetterlo attraverso una connessione TCP La lettura e la scrittura aggiornano i puntatori I proxy prevedono due metodi che permettono di trasmettere e ricevere il Buffer attraverso la rete privata e che sono invocati dai rispettivi Manager durante il protocollo di gestione della migrazione

Handoff 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) Come viene gestito l’evento di Handoff? PREDITTORE HANDOFF MONITOR

Protocolli di Migrazione PREDIZIONE CORRETTA Sottorete 1 Sottorete 2 Sottorete 3 Client Manager 1 Proxy 1 Manager 2 Manager 3 server Il predittore sul client rileva un possibile handoff e segnala la previsione al proxy insieme all’ identificatore della rete su cui prevede che avverrà la riconnessione NEW_AP(SUB2) NEW_PROXY_SUBNET Proxy 2 > NEW_PROXY_RESPONSE CHANGE_DESTINATION PREDICTION_CORRECT Il proxy avvia il protocollo per gestire la migrazione Il Buffer viene trasferito tra i due proxy Il client mobile cambia sottorete e contatta il nuovo proxy per farsi inviare il flusso audio Il nuovo proxy segnala al vecchio proxy che la predizione era corretta Il vecchio proxy può terminare l’esecuzione L’infrastruttura è pronta per eseguire nuovamente il protocollo di Handoff!

Protocolli di Migrazione PREDIZIONE ERRATA Sottorete 1 Sottorete 2 Sottorete 3 Manager 1 Proxy 1 Manager 2 Manager 3 Proxy 2 Client server NEW_PROXY Proxy 3 > PREDICTION_WRONG CHANGE_DESTINATION TERMINATE_WRONG_PROXY La predizione si rivela errata: il Client migra verso una rete diversa da quella prevista Protocollo REATTIVO : bisogna trasformare l’infrastruttura per garantire la fruizione del servizio all’utente Il Client contatta il Manager della nuova rete per farsi creare un nuovo Proxy Segnalazione dell’errata previsioneTrasferimento Buffer e invio del flusso bufferizzato dal Proxy al Client Terminazione del Proxy errato e del Proxy iniziale L’infrastruttura è pronta per gestire un nuovo Handoff!

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.