Unibo Streaming System

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
[email protected]
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 WebTV) 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
1.2 Client
sfruttate le librerie fornite da Java tramite in
Java Media Framework.
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.
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.
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.
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 CSeq 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
Alla pressione del Pulsante OK il client
manda al Server un messaggio RTSP di
3
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:
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: 631
Content-type: application/sdp
Content-Length: 394
RTSP/1.0 200 OK
CSeq: 632
Session: 151251593
Transport: RTP/AVP; unicast; client_port=40052-40053;
server_port=2000-2001;
Bandwidth:128000
v=0
o=StreamingServer
s=TrasmissioneFile
i=Sessione di trasmissione del file richiesto
u=http://casafrassinago3.homeip.net
[email protected] (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
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.
-4-
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
PLAY rtsp://192.168.0.3/L4.mp2 RTSP/1.0
CSeq: 633
Range: npt=0.0Session: 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:
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
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 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.
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: 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.
RTSP/1.0 200 OK
CSeq: 634
Session: 151251593
-5-
Esempio: il client invia al server
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.
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:
REDIRECT rtsp://192.168.0.1/L4.mp2 RTSP/1.0
CSeq: 640
Location: rtsp://192.168.0.1
Range: npt=19.34-
RTSP/1.0 501 Not Implemented
CSeq: 639
Figura 2: La comunicazione tra client e server per la richiesta di un file multimediale on demand
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.
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
-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
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.
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,
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
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.
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
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/jw04-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/ID/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/ID/draft-ietf-mmusic-rtsp-nat-00.txt
http://www.ietf.org/proceedings/04mar/ID/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