1 / 14

MUSE BT Proxy

Reti di Calcolatori LS A.A. 2006/2007. MUSE BT Proxy. Colombini Gabriele 231491. Invio di Streaming Audio attraverso rete wireless Bluetooth Mobilità attraverso la rete Bluetooth, con passaggio eventuale da un Access Point ad un altro Continuità di servizio a seguito di handoff.

conroy
Download Presentation

MUSE BT Proxy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Reti di Calcolatori LS A.A. 2006/2007 MUSE BTProxy Colombini Gabriele 231491

  2. Invio di Streaming Audio attraverso rete wireless Bluetooth • Mobilità attraverso la rete Bluetooth, con passaggio eventuale da un Access Point ad un altro • Continuità di servizio a seguito di handoff Server: mantiene le canzoni sotto forma di mp3 Proxy: agisce da mediatore tra Client e Server Access Point: permette la accedere alla rete Bluetooth Introduzione Client: riceve le richieste dell’utente e riproduce il file audio richiesto

  3. Zona di handoff Zona critica Struttura

  4. Doppio livello di bufferizzazione • Buffer sul Client che permette la riproduzione durante la situazione di handoff e di disconnessione da qualsiasi Access Point • Buffer sul Proxy che permette di memorizzare i frame inviati dal Server durante le situazioni di handoff e di disconnessione da qualsiasi Access Point e di inviarli al Client una volta riconnesso Utilizzo di NCSOCKS come infrastruttura di rete • Mobility Management: gestione degli handoff che occorrono nel passaggio da un Access Point ad un altro • Connection Awareness: conoscenza di tutte le informazioni circa lo stato attuale della connessione (qualità del segnale, probabilità di handoff) Soluzione

  5. ApplicationProxy: thread in continuo ascolto, in attesa di una richiesta di connessione al servizio proveniente da Client • SessionProxy: thread che viene generato appena ricevuta una richiesta di connessione da un Client • RTPProxy: thread utilizzato per gestire il flusso multimediale: riceve il flusso dal Server, inoltrandolo al Client Application Proxy Session Proxy RTP Proxy Proxy

  6. Per ogni Client che si connette viene creata un interfaccia bnep per l’incapsulamento dei dati • Lato Access Point le interfacce bnep create sono unite con bridge a pan0 • L’interfaccia di rete eth0 viene unita tramite bridge all’interfaccia virtuale pan0 Proxy ETH0 AP ETH0 PAN0 BNEP0 BNEP1 BNEPn … Client 1 Client n Unica rete a cui i Device si collegano tramite una serie di bridge Access Point BNEP0 BNEP0

  7. Ad ogni Client è associato un IP fisso • Trasparenza al Proxy: continua ad inviare sempre allo stesso IP •  Il Proxy potrebbe continuare a inviare al vecchio Access Point ETH0 ETH0 PAN0 PAN0 Handoff BNEP0 BNEP0 Handoff SOLUZIONE!?!

  8. A regime il livello di riempimento è minimo Durante la fase handoff • I frame provenienti dal Server vengono memorizzati nel buffer • In questa fase il livello di riempimento si alza costantemente, fino alla riconnessione del Client • Dopo essersi riconnesso il Client invia il numero di sequenza dell’ultimo frame ricevuto • Il Proxy riprende l’invio dal frame con numero di sequenza ricevuto Ora il buffer è pieno (o quasi)…e se si verifica un altro handoff????? Politica Adottata: 2 differenti velocità Bassa: a regime Alta: dopo la riconnessione del Client Buffer

  9. Problema di gestione delle risorse Per molto tempo (a regime) il buffer è quasi vuoto ma alloca comunque lo stesso numero di risorse di quando è pieno Buffer dinamico: modifica la sua capacità in base alla situazione • 50 Frame quando non deve immagazzinare i frame provenienti dal Server • 150 Frame quando il Client è disconnesso Buffer dinamico

  10. Proxy Session RTP Proxy Handoff Probabilità Alta Handoff Imminente Il Proxy invia iterativamente i frame che arrivano dal Server Il Client notifica che si sta avvicinando a una situazione di handoff: il Proxy ingrandisce il proprio buffer Il Client notifica che la situazione di handoff è imminente: Il Proxy blocca l’invio dei frame al Client e comincia a memorizzare quelli provenienti dal Server Disconnessione

  11. Proxy Session Reconnect Ack RTP Proxy Ack Il Client invia un messaggio di riconnessione con il sequence number dell’ultimo frame ricevuto Il Proxy risponde con un Ack al Client Questa fase viene eventualmente iterata fino a quando il Client riceve l’Ack Il Client invia un Ack al Proxy Il Proxy riprende l’invio dei frame immagazzinati Riconnessione

  12. Per i test sono stati utilizzati 5 portatili Un portatile per il Client Due portatili per gli Access Point Un portatile per il Proxy Un portatile per il Server Frame Tempo in sec Test Il Proxy invia i frame che riceve dal Server Il Proxy si prepara ad un eventuale handoff: ingrandisce il buffer Il Proxy comincia a immagazzinare i frame provenienti dal Server Il Proxy ricomincia a inviare i frame al Client, svuotando il buffer

  13. Il Sistema progettato garantisce continuità di servizio anche a fronte di ripetuti handoff • L’utilizzo di un buffer dinamico permette di gestire al meglio l’allocazione di risorse • Il protocollo utilizzato garantisce al Client la ricezione di tutti i frame della canzone, ad esclusione di quelli persi per il protocollo UDP Per il futuro… • Adattamento del servizio in base alla caratteristiche del Device • Aggiunta di funzionalità che permettono di controllare il flusso audio in uscita dal Proxy • Utilizzo di differenti dispositivi device, come ad esempio Palmari Conclusioni e sviluppi

  14. Fine

More Related