Unibo Streaming System a C/S system to stream audio / video over the web

Unibo Streaming System a C/S system to stream audio / video over the web realized by Loris Cancellieri - matr. No 171431 University of Bologna Reti di Calcolatori LS prof. Antonio Corradi A.A. 2004-2005 loris.cancellieri@studio.unibo.it Abstract: Negli ultimi anni abbiamo assistito ad una rapida espansione di Internet ed ad una equivalente diffusione delle tecnologie ad esso legate; fra queste un ruolo di primo piano è occupato dall erogazione di servizi multimediali attraverso la rete. Offrire agli utenti questo tipo di servizio significa assicurare innanzitutto una buona comunicazione fra il fruitore del servizio (client) e il distributore del servizio (server di streaming); a questo fine sono state sviluppate molte architetture proprietarie che però non permettevano l interoperabilità fra sistemi simili. Ultimamente sono però stati proposti e «standardizzati» alcuni protocolli proprio al fine di garantire una buona comunicazione tra Client e Server, garantire una buona QoS e permettere ad applicazioni diverse di interoperare fra loro. Questi protocolli sono RTP-RTCP per la trasmissione dei dati e il controllo della comunicazione, l SDP per fornire al client le informazioni relative al media che si va a trasmettere e l RTSP per la comunicazione fra client e server al fine di scambiarsi informazioni e garantire l interoperabilità fra la piattaforma di streaming e il client (Player) che invece deve riprodurlo sul PC dell utente. L RTSP standardizza anche l interazione tra l utente e il server in modo che l utente possa riavviare il media, metterlo in pausa o iniziare la riproduzione da un punto qualsiasi a sua scelta. Il mio lavoro si prefigge proprio l obiettivo di andare ad analizzare questi protocolli e di andarli ad utilizzare per fornire un server che permetta sia la trasmissione multicast di contenuti in streaming (come Web-Radio o Web- TV) sia la trasmissione unicast di contenuti audio e video on-demand con politiche di Load Balancing e disaster recovery. 1. Architettura del sistema L architettura che si è utilizzata per la realizzazione del nostro servizio di streaming si rifà all architettura Client / Server anche se l architettura è contornata da soluzioni che permettono di non sovraccaricare il server facendo Load Balancing (se il server è sovraccarico le richieste vengono redirette verso altri nodi) e permettono di attuare una politica di fault-tolerance in caso di fallimento del server di streaming sempre però sotto l ipotesi di guasto singolo. Il client e il server del nostro sistema possono essere trattati in maniera completamente separata; infatti proprio per garantire l interoperabilità, e grazie all implementazione di protocolli standard, il server può lavorare anche con client di terze parti come il JMStudio di Sun o il progetto open-source VLC, o il QuickTime Player, e il client può essere usato anche per riprodurre contenuti in streaming trasmessi da altri server come il Sun Streaming Server. Ogni nodo che funge da sorgente di dati per lo streaming ha due istanze dello stesso server, una chiamata MainServer che funge da server principale e una istanza chiamata SlaveServer che invece è idle e in attesa di essere avviata in caso di problemi al server principale che non gli permettono di svolgere le proprie funzionalità. A queste due istanze si aggiunge un altro server chiamato ControlServer che ha lo scopo di fornire ai client che glielo richiedono il file xml con la lista dei mediafile presenti sul server e che possono essere richiesti e ha lo scopo di «pingare» ad intervalli regolari il MainServer per vedere se è ancora attivo. Se viene rivelata una failure nel MainServer, il ControlServer manda un messaggio allo SlaveServer per farlo attivare e fargli prendere le veci del MainServer. Nell implementazione del sistema sono state 1

sfruttate le librerie fornite da Java tramite in Java Media Framework. 1.1 Server Il server alla partenza configura i suoi parametri di funzionamento sulla base delle informazioni contenute in un file xml di configurazione (ConfigServer.xml) e in particolare setta la porta base della trasmissione RTP, la porta sulla quale si metterà in attesa dei messaggi RTSP proveniente dai client (di default la 554), la porta dove riceverà i messaggi di controllo e l indirizzo IP del nodo al quale ridirigere le richieste dei client in caso di sovraccarico del server oltre ad altri parametri propri del server stesso. Dopo la fase di configurazione iniziale, il server recupera dal file xml i parametri della trasmissione MultiCast e istanzia un oggetto Unicast_rtp per iniziare la trasmissione dello stream multicast (Stile Web-Radio o Web-TV). Anche se per la trasmissione multicast uso lo stesso oggetto della trasmissione unicast, non ho problemi e la trasmissione dello stream avviene il Multicast. Infatti la distinzione del tipo della trasmissione è fatta dall oggetto del JMF RTPManager che gestisce la trasmissione dello stream e che al suo interno implementa un metodo chiamato ismulticastaddress() che controlla gli indirizzi passati come target della trasmissione e modifica il tipo di trasmissione in base al TargetAddress. Successivamente verrà istanziato un oggetto su un thread separato isalivethreadresponse che si occupa di ricevere le richieste di isalive e di rispondere a queste richieste. Da ultimo verrà istanziato un oggetto di tipo RTSP_Manager che crea la ServerSocket per la ricezione delle richieste RTSP da parte dei client e si mette in attesa di richieste di trasmissione on-demand. Per la trasmissione il server sfrutta il protocollo RTP / RTCP implementato dalla Sun nel Java Media Framework, mentre il protocollo RTSP per lo scambio di messaggi tra Client e Server e il protocollo SDP per la descrizione del contenuto del file multimediale sono stati implementati da me. 1.2 Client Il Client è l utilizzatore dei servizi che il server mette a disposizione ed implementa anche tutte le procedure che permettono all utente di interagire con il server durante la fruizione del servizio di streaming on demand. Dopo l avvio l utente può scegliere tre tipi di operazione: Connettersi all indirizzo di Multicast ed ascoltare l audio trasmesso in streaming dal server. Richiedere la trasmissione di un file audio o video specificando l indirizzo del server RTSP e il nome del file Ricevere e visualizzare la lista dei file audio e video disponibili sul server e poi scegliere cosa ascoltare. Nel primo caso l utente non può intervenire sulla trasmissione e quindi non gli viene lasciata possibilità alcuna di interagire con il server. L unica cosa che può fare è terminare l ascolto o visualizzare i messaggi RTCP di controllo della trasmissione scambiati tra Client e Server. L utente può visualizzare questi messaggi, decidere se fermare / far ripartire la loro visualizzazione e volendo può salvare i messaggi RTCP su un file di testo per una successiva analisi. Negli altri due casi invece si sfrutta il protocollo RTSP per la comunicazione fra client e server al fine di scambiarsi informazioni relative al media da trasmettere e al fine di garantire l interazione dell utente che può avviare la riproduzione, metterla in pausa, riavviarla da capo o chiuderla. Il client sfrutta uno stack RTSP implementato della Sun nella classe Player del JMF, ma questa implementazione della Sun è molto di base e infatti il client non supporta alcune delle funzioni che invece sono state implementate sul Server. Se l utente sceglie di visualizzare la lista dei file multimediali disponibili sul server, deve inserire l indirizzo IP del server da cui vuole recuperare la lista, il client si connette al Thread che fornisce il servizio di trasferimento file e quest ultimo invia al client un file XML di nome medialist.xml che contiene la lista dei file multimediali che 2

il server mette a disposizione per lo streaming insieme a una loro descrizione (tipo, Autore, Titolo). Il client, attraverso una specifica classe, fa il parsing di questo file e fornisce all utente i dati sotto forma tabellare. L utente può selezionare il file da riprodurre e alla pressione del tasto Ascolta gli viene presentata una finestra con un mini-player attraverso il quale può interagire con il server per la gestione dello stream. Figura 1 Interfaccia Utente del Client 2. Richiesta di media on-demand Mostriamo i passaggi e i messaggi scambiati tra client e server al momento della richiesta, da parte del client di un file multimediale. Questi messaggi vengono scambiati attraverso il TCP per avere maggiori garanzie di ordine dei messaggi. Consideriamo un caso d uso di questo tipo: Precondizioni: l utente conosce sia l indirizzo del server che il nome del file che vuole richiedere. Azione: l utente inserisce questi dati nella casella di testo che compare a video alla pressione del pulsante apri sulla Toolbar o di Apri RTP URL sul Main_Menu e preme OK. Postcondizioni: compare l interfaccia grafica del miniplayer e la riproduzione ha inizio. Alla pressione del Pulsante OK il client manda al Server un messaggio RTSP di 3 DESCRIBE con il quale il client manda al server l URL del file da trasmettere, il numero di sequenza del messaggio insieme ad altre informazioni come lo User-Agent. Il numero di sequenza del messaggio è un must del protocollo e deve essere specificato in ogni messaggio che si scambiano il Client e il Server; ad ogni richiesta con un certo numero di sequenza deve corrispondere una risposta con lo stesso numero. Le risposte devono essere mandate in ordine con le richieste; a fronte di due richieste una con C- Seq 631 e una con C-Seq 632 non può verificarsi che prima venga mandata la risposta con C-Seq 632 e poi la risposta con C-Seq 631. DESCRIBE rtsp://192.168.0.3/l4.mp2 RTSP/1.0 CSeq: 631 Accept: application/sdp User-Agent: JMF RTSP Player Version 2.1.1e

Il server innanzitutto verifica se il file richiesto esiste e in caso di esito positivo restituisce un messaggio con status-line RTSP/1.0 200 OK. La status-line è costituita dalla versione del protocollo, da un codice che identifica lo stato di errore o di successo e dalla relativa descrizione. I codici di errore sono ben descritti nell RFC 2326 e comunque sono molto simili a quelli usati nell HTTP. Oltre alla status-line, il server restituisce al client una descrizione completa del file richiesto seguendo i criteri del protocollo SDP (Session Description Protocol) che verranno descritti meglio in seguito. Le informazioni SDP vengono così costruite: se il file esiste URL del file viene passato alla classe MySDP che costruisce la stringa SDP sulle informazioni che gli vengono restituite dalla classe MediaInfo. Questa classe, che sfrutta le API del JMF, crea un oggetto Processor a cui viene passato il MediaLocator (l url del file multimediale) e attraverso l oggetto Processor determina la lunghezza del file ed estrae le tracce video e audio; da queste poi è possibile ricavare il formato audio e video e attraverso una serie di if determinare il tipo di payload associato a questi formati. Il payload è determinato sulla base delle specifiche dell RFC 1890 del Gennaio 1996 e delle successive modifiche avutesi con RFC 3551 del Luglio 2003. Questa è la stringa che il server restituisce al client per uno stream solo audio: RTSP/1.0 200 OK CSeq: 631 Content-type: application/sdp Content-Length: 394 v=0 o=streamingserver s=trasmissionefile i=sessione di trasmissione del file richiesto u=http://casafrassinago3.homeip.net e=loris.cancellieri@studio.unibo.it (Loris Cancellieri) p=+39-000-0000000 c=in IP4 192.168.0.3 b=as:2048 t=0 0 a=charset:iso-8859-1 m=audio 2000 RTP/AVP 14 a=rtpmap:14 MPA/44100 a=control:rtsp://192.168.0.3/audio a=mimetype: audio/mpa a=range:npt=0-264 - 4 - A questa risposta, segue la richiesta di SETUP da parte del client, dove questo specifica il protocollo di trasporto che deve essere utilizzato per il flusso di dati multimediali e la porta sulla quale il client si aspetta i dati. Il primo numero di porta (sempre pari) è la porta sulla quale devono essere mandati i pacchetti UDP con il flusso multimediale secondo il protocollo RTP, mentre la seconda porta (dispari) rappresenta la porta sulla quale devono essere inviati i pacchetti UDP di controllo del flusso secondo il protocollo RTSP. SETUP rtsp://192.168.0.3/audio RTSP/1.0 CSeq: 632 Transport: RTP/AVP;unicast;client_port=40052-40053 User-Agent: JMF RTSP Player Version 2.1.1e Il server riceve questa richiesta, ne fa il parsing sfruttando la classe Parser nel package it.unibo.mystream.protocol.rtsp per estrarne il C-Seq e i numeri di porta e crea una stringa di risposta dove indica anche le porte che esso userà per la trasmissione del flusso e la trasmissione/ricezione dei pacchetti RTCP. Oltre a questo, il server include nella risposta al SETUP un numero di sessione opportunamente generato che servirà ad individuare fino alla chiusura questa specifica «sessione» di trasmissione e include anche informazioni relative alla banda massima (espressa in bit/s) disponibili per la trasmissione. RTSP/1.0 200 OK CSeq: 632 Session: 151251593 Transport: RTP/AVP; unicast; client_port=40052-40053; server_port=2000-2001; Bandwidth:128000 Fa seguito la richiesta di PLAY da parte del Client che presenta ancora l URL del file, il numero di Sequenza del messaggio, il numero di Sessione che il Server aveva precedente comunicato con la risposta al SETUP e il Range. Il Range Header comunica il punto da cui la riproduzione deve avviarsi; questo può essere espresso in unità NPT (Normal Play Time) come nel nostro caso o in unità di tempo smpte. Nel nostro esempio il client indica che la riproduzione dello stream deve cominciare dall inizio.

PLAY rtsp://192.168.0.3/l4.mp2 RTSP/1.0 CSeq: 633 Range: npt=0.0- Session: 151251593 User-Agent: JMF RTSP Player Version 2.1.1e Alla ricezione di questo messaggio, il server fa il parsing ricavando come sempre il numero di Sequenza, il numero di Sessione e il Range (si sfrutta la funzione double getrange della classe Parser), crea la risposta alla richiesta di Play e la invia al client. Inoltre costruisce tanti oggetti Unicast_rtp per quante sono le tracce da trasmettere e lancia il metodo run() su questi oggetti per avviare la trasmissione dello stream. Ora si ha la trasmissione dello stream da parte del server e la ricezione / riproduzione da parte del client; l utente può intervenire su questo processo con la pressione dei tasti pause, rewind o close. Alla pressione del tasto pause, lo stack RTSP embedded nel client manda al server un messaggio di PAUSE: PAUSE rtsp://192.168.0.3/l4.mp2 RTSP/1.0 CSeq: 634 Session: 151251593 User-Agent: JMF RTSP Player Version 2.1.1e Il server fa il solito parsing del messaggio e invoca il metodo pausestream() su tutti gli oggetti Unicast_rtp con l effetto di mettere in pausa lo stream. Nel nostro caso si ha che sia il client (in NPT) sia il server (Classe Time) memorizzano il momento in cui la riproduzione / trasmissione è stata messa in pausa e questo è stato fatto per permettere l interoperabilità del nostro server con i client che non memorizzano questo dato. (Solo per curiosità: all atto della ripresa della trasmissione è possibile vedere sulla console del server un messaggio che ci dice lo scarto fra il tempo memorizzato dal client e quello memorizzato dal server). Il server risponde al messaggio di pausa con un messaggio RTSP di OK RTSP/1.0 200 OK CSeq: 634 Session: 151251593 Ad una eventuale successiva pressione del tasto play, il client invia al server un messaggio di play identico al precedente, con l unica differenza che il campo Range riporta in NPT il tempo in cui riprendere la riproduzione. (Il server riporta il tempo indietro di 2 secondi per compensare eventuali ritardi di trasmissione e riempimento della cache). Per riprendere la trasmissione il server invoca il metodo StartStreamAgain su tutti gli oggetti Unicast_rtp. La pressione del tasto rewind invece provoca da parte del Client l invio prima di un messaggio di PAUSE, e poi subito dopo di un messaggio di PLAY con il Range settato a 0.0 Se invece l utente clicca sul pulsante di chiusura, questo provoca l invio da parte del client di una richiesta di TEARDOWN per fermare la trasmissione dello stream e liberare le risorse allocate. TEARDOWN rtsp://192.168.0.3/l4.mp2 RTSP/1.0 CSeq: 638 Session: 151251593 User-Agent: JMF RTSP Player Version 2.1.1e Il Server fa il parsing della richiesta, prepara la Stringa di risposta e chiama il metodo teardownstream() su tutti gli oggetti di tipo Unicast_rtp; questo metodo chiude l oggetto processor e lo dealloca, chiude l oggetto SendStream, rimuove il client dalla lista dei target di quello stream e fa il dispose degli RTP_Manager definiti per la trasmissione. RTSP/1.0 200 OK CSeq: 638 Session: 151251593 Il protocollo RTSP da me implementato supporta anche altri tipi di comandi che non vengono però sfruttati o non sono supportati dallo stack RTSP implementato nel JMF. Fra questi abbiamo il comando di OPTIONS che viene inviato dal client al server per conoscere la lista dei comandi che il server implementa e mette a disposizione (getsupportedcommands())e il comando SET_PARAMS per settare dei parametri sul server. - 5 -

Esempio: il client invia al server OPTIONS * RTSP/1.0 CSeq: 630 Require: implicit-play e il server risponde RTSP/1.0 200 OK CSeq: 630 Public: DESCRIBE, SETUP, PLAY, OPTIONS, PAUSE, TEARDOWN, SET_PARAMETER, ANNOUNCE, RECORD Il server fa il parsing corretto anche di comandi come ANNOUNCE e RECORD, ma risponde con un messaggio di errore di Not_Implemented (501). La classe ErrorMessagge è stata implementata proprio per costruire i messaggi di risposta ai più frequenti messaggi di errore che si possono presentare fornendo anche l opportuna status-line. Es: RTSP/1.0 501 Not Implemented CSeq: 639 Nelle situazioni viste finora, il Server risponde a messaggi inviati dal Client, ma ci sono anche delle situazioni in cui è il Server che è promotore di un messaggio verso il Client e questo deve rispondere. Questo comportamento del server si può notare nella classe BaseRTSP dove sono stati definiti due modi di funzionamento per il Server: il SERVER_MODE dove risponde a messaggi del client e il CLIENT_MODE dove è il server a proporre messaggi. Esempio di richieste dove il server lavora il client mode sono quelle di GET_PARAMETER dove il server specifica dei parametri di funzionamento di cui vuole sapere i valori dal client e di REDIRECT dove il server informa il client che deve connettersi ad un altro server e contiene le informazioni sul server a cui deve connettersi e (opzionalmente) sul momento in cui il servizio non sarà più disponibile. REDIRECT rtsp://192.168.0.1/l4.mp2 RTSP/1.0 CSeq: 640 Location: rtsp://192.168.0.1 Range: npt=19.34- Figura 2: La comunicazione tra client e server per la richiesta di un file multimediale on demand Se il Client non conosce l URL del file da richiedere, deve richiedere la lista dei file disponibili in un server. Per fare ciò deve inserire l indirizzo del nodo dove risiede un ControlServer, il quale restituisce il file medialist.xml che contiene le info sui media disponibili e l indirizzo fisico del server di streaming che contiene quei mediafile (Il tutto avviene attraverso una comunicazione TCP). Gli indirizzi dei nodi dove risiedono i ControlServer possono essere recuperati, ad esempio, da una pagina web. - 6 -

Figura 3: Comunicazione client-server con richiesta file 3. Politiche di Load balancing Il sistema implementa anche una politica di Load balancing volta a non intasare troppo un nodo poiché la trasmissione di stream richiede lo sfruttamento di molta banda e quindi se un nodo è troppo carico la qualità della ricezione ne risente particolarmente. A questo scopo il file xml di configurazione del server (ServerConfig.xml) contiene un elemento maxclients dove viene specificato il numero massimo di trasmissioni on-demand da servire contemporaneamente. Il bilanciamento del carico è gestito dalla classe LoadBalancing e la variabile che rappresenta internamente il numero di client forniti contemporaneamente viene incrementata quando il client fa il SETUP e decrementata quando fa il TEARDOWN. In caso il player cadesse durante la riproduzione e comunque prima di fare il TEARDOWN, la variabile che mantiene il numero degli «slots» occupati verrebbe decrementata appena il server termina la trasmissione dello stream. L unico problema che si potrebbe porre è quello relativo alla PAUSA poiché lo «slot» rimane occupato anche se non stiamo sfruttando banda. La mia scelta progettuale è stata quella di lasciare lo «slot» al client perchè non accada che questo, alla ripresa della riproduzione, non abbia più «slot» disponibili; nella mia scelta è anche implicita una certa fairness dell utente che non dovrebbe divertirsi a tenere illimitatamente in pausa uno stream. Si potrebbe anche implementare un timeout dopo il quale le risorse compreso lo «slot» vengono liberate. Se il numero dei client che richiedono lo stream supera quello massimo consentito, il server risponde ad una richiesta di Describe con un messaggio di Redirect dove si indica anche la location del server dove fare redirect (la location è recuperata dal file xml di configurazione del server). RTSP/1.0 301 Moved CSeq: 230 Location: rtsp://192.168.0.1/l4.mp2 Connection: Close 7

Figura 4: Comportamento del nodo 192.168.0.3 in caso di overload 4. Politica di replicazione e recovery Le politiche di replicazione e recovery da guasti implementate nel sistema partono innanzitutto dall ipotesi di guasto singolo. IL sistema è formato complessivamente da tre parti: un server principale MainServer che funge da Server di streaming sia per la trasmissione multicast, sia per la trasmissione unicast on-demand un server ControlServer che assolve a tre funzioni: restituisce il file medialist.xml ai client che lo richiedono, «pinga» periodicamente il MainServer per testarne il funzionamento e mantiene la lista di tutti i client connessi in modo da poterli avvertire in caso rilevi una failure nel sistema un server SlaveServer che è una copia fredda cioè viene avviato e configurato ed è in stand-by, in attesa di svolgere le sue funzioni quando attivato. Il ControlServer manda periodicamente (ogni 30 secondi) al MainServer un datagramma per verificare se questo è ancora funzionante e poi si mette in attesa di ricevere il datagramma di risposta. Se questo non arriva entro 10 secondi, il ControlServer ritenta la trasmissione del datagramma (UDP non ha alcuna garanzia di consegna e può essere andato perso) e si pone in attesa. Se scade di nuovo il time-out senza aver ricevuto risposta da parte del MainServer, il ControlServer considera il MainServer down e manda un datagramma con il messaggio START_SLAVE allo SlaveServer per attivarlo. Alla ricezione di questo messaggio, lo SlaveServer inizializza e attiva lo stream multicast e successivamente apre la sua ServerSocket sulla porta 554 e si mette in attesa delle richieste on-demand del client. Dopo l attivazione dello SlaveServer, il ControlServer, sfruttando la lista dei Client attivi, invia un messaggio RTSP di REDIRECT a tutti i client connessi indicando loro la locazione del nuovo server. REDIRECT rtsp://192.168.0.3/l4.mp2 RTSP/1.0 CSeq: 1 Location: rtsp://192.168.0.1 La ricezione di questo messaggio da parte del client fa fermare la riproduzione e il client rinegozia la connessione con il nuovo server inviando un messaggio di SETUP; la trasmissione verrà fatta ripartire dal punto in cui si era interrotta inviando al client il Range opportuno insieme alla richiesta di Play. Lo stack RTSP del JMF non supporta tali tipi di messaggi e sia per questo motivo, sia per qualche eccezione di ConnectionRefused che veniva lanciata quando tutti i client e i server risiedevano sullo stesso nodo, la parte di invio del 8

messaggio vero e proprio è stata commentata nel codice. I tre servitori possono risiedere tutti e tre sullo stesso nodo o su nodi differenti; è possibile configurare sia gli indirizzi dei nodi dove risiedono i servitori sia le porte dove questi vanno a lavorare tramite i file di configurazione XML. Se i servitori e in particolare il MainServer e lo SlaveServer risiedono sullo stesso nodo, si può reagire a guasti singoli del MainServer che impediscono il funzionamento del sistema o ad errori che ne hanno provocato la chiusura, ma non si può reagire a guasti dell intero nodo o a cadute della rete. Questo non accade invece se il MainServer risiede su un nodo diverso rispetto allo SlaveServer e al ControlServer. Naturalmente se lo SlaveServer risiede su un nodo diverso, dopo la sua attivazione, dovuta a una caduta del MainServer, anche il ControlServer dovrà restituire al Client un file medialist.xml contenente i mediafile presenti nel nodo dello SlaveServer e restituire come indirizzo del server di streaming l indirizzo del nuovo nodo. Figura 5: Comportamento globale del sistema a regime 9

Figura 6: Azioni del sistema quando viene individuata una failure nel MainServer Figura 7: Comportamento del sistema dopo le azioni correttive (Disaster Recovery) 10

5. Testing dell applicazione Known Issues Sono stati eseguiti anche dei test sull intero sistema e tutto sembra funzionare correttamente. Sono stati però riscontrati alcuni problemi come frame persi o in ritardo che non rendevano sempre fluida la riproduzione del file multimediale; questi problemi sono però nettamente diminuiti passando da una connessione su rete wireless Ad-Hoc 802.11b 11Mbps ad una su rete wired 100 Mbit. Inoltre nella trasmissione di stream audio/video a volte si nota una desincronizzazione tra i due stream. Dopo qualche ricerca in rete, ho scoperto che il problema è riconducibile all implementazione del JMF. E stato anche eseguito un test dell occupazione di banda della rete; i valori presentati nel grafo qui sotto sono stati ottenuti facendo il play contemporaneo in rete dello stream multicast e di un stream audio richiesto on-demand. Dalla linea rossa in poi, invece gli stream audio (on-demand) trasmessi sono diventati due per poi tornare ad essere uno solo nel finale dopo la linea blu in quanto il primo stream è terminato. I picchi sono dovuti o a richieste RR del client o a collisioni / ritrasmissioni della rete wireless in configurazione Ad-hoc 11Mbit. Figura 8: Analisi del traffico di rete Legenda: In Verde il totale dei byte che transitano sulla rete In Rosso i byte inviati In Giallo i byte ricevuti 6. Sviluppi futuri L applicazione si presta a molteplici sviluppi futuri lungo diverse direttrici di progetto. La prima direttrice è quella di implementare la parte di livestreaming in modo da permettere la cattura dello stream e la successiva diffusione. Anche in questo caso possiamo sfruttare qualche libreria che il JMF ci mette a disposizione. Di pari passo a questo va anche l implementazione dei messaggi RTSP di ANNOUNCE e RECORD. Un altra direzione verso cui varrebbe la pena estendere il progetto è quella dell aumento della compatibilità con client già sul mercato come ad esempio il RealPlayer o il Windows 11 Media Player che attualmente non sono supportati. Allo stesso modo sarebbe interessante aumentare anche i formati supportati (vedi http://java.sun.com\products\javamedia\jmf\2.1.1\solutions\custompayload.html) e creare degli artefatti che evitino le desincronizzazioni tra stream audio e video. Sul fronte del Disaster Recovery sarebbe interessante estendere il progetto in modo da prevedere la possibilità di avere n SlaveServer ed avere replicazione anche per il ControlServer poiché attualmente se il ControlServer cade, per avere la lista dei file devo interrogare il ControlServer di un altro nodo il cui indirizzo deve essere reperito da una pagina web.

7. References Non tutti i riferimenti bibliografici qui presentati trovano una piena applicazione nel progetto del sistema sviluppato. Essi sono stati consultati per la creazione di un background di conoscenza utile a capire il funzionamento dei protocolli, ad implementarli e a fare alcune scelte progettuali che poi alla fine hanno portato al risultato finale. 1. A. Corradi Dispense di Reti di Calcolatori L-S A.A. 2004-05 http://www.lia.deis.unibo.it/courses/retil S/ 2. JMF 2.0 API March 2001 http://java.sun.com/products/javamedia/jmf/2.1.1/guide/index.html 3. Java Media Framework (JMF) http://java.sun.com/products/javamedia/jmf/ 4. JMF RTP Support: http://java.sun.com/products/javamedia/jmf/2.1.1/support-rtp.html 5. JMF 2.0 FAQs: 6. http://java.sun.com/products/javamedia/jmf/reference/faqs/index.html 7. JMF 2.0 Samples http://java.sun.com/products/javamedia/jmf/2.1.1/samples/samplecode.html 8. RFC1889: RTP: A Transport Protocol for Real-Time Applications Jan 1996 http://www.faqs.org/rfcs/rfc1889.html 9. RFC1890: RTP Profile for Audio and Video Conferences with Minimal Control Jan 1996 http://www.faqs.org/rfcs/rfc1890.html 10. RFC2326: Real Time Streaming Protocol (RTSP) Apr 1998 http://www.faqs.org/rfcs/rfc2326.html 11. IETF Internet Draft Real Time Streaming Protocol (RTSP) RFC2326bis Mar 03 Expires Sept 03 http://www.rtsp.org/2003/drafts/draft03/dr aft-ietf-mmusic-rfc2326bis-03.pdf 12. RTSP Site: http://www.rtsp.org 13. RFC2327: SDP: Session Description Protocol April 1998 http://www.faqs.org/rfcs/rfc2327.html 14. RFC3551: RTP Profile for Audio and Video Conferences with Minimal Control July 2003 Obsoletes RFC1890 http://www.faqs.org/rfcs/rfc3551.html 15. JavaWorld: Proramming multimedia with JMF April2001 http://www.javaworld.com/javaworld/jw- 04-2001/jw-0406-jmf1_p.html 16. Internet Media Group - Introduction to RTP/RTCP http://media.polito.it 17. J.C. De Martin Protocolli per la trasmissione real-time su reti IP Polito Jun 2002 http://demartin.polito.it/etim/etim_prot ocolli_per_il_real_time_su_ip.pdf 18. Sito IANA per mime-type http://www.iana.org/assignments/mediatypes/audio http://www.iana.org/assignments/mediatypes/video 19. RFC2045: Multiporpouse Internet Mail Extension http://www.faqs.org/rfcs/rfc2045.html 20. IETF Draft di D. Yon: Connection-Oriented Media Transport in SDP July 2002 http://www.ietf.org/proceedings/02mar/i- D/draft-ietf-mmusic-sdp-comedia-01.txt 21. IETF Draft di M.Westerlund: How to make Real-Time Streaming Protocol (RTSP) traverse Network Address Translators (NAT) and interact with Firewalls Feb 2003 Exp. Aug 2003 http://www.ietf.org/proceedings/03mar/i- D/draft-ietf-mmusic-rtsp-nat-00.txt http://www.ietf.org/proceedings/04mar/i- D/draft-ietf-mmusic-rtsp-nat-02.txt 22. Steve Mack :Streaming Media Bible Hungry Minds http://www.streamingmediabible.com/htm l/toc.html (c) 2005 Loris Cancellieri 12