televisione digitale soluzione di streaming per internet a banda larga

Transcript

UNIVERSITÀ DI UDINE
FACOLTÀ DI SCIENZE MATEMATICHE FISICHE NATURALI
CORSO DI LAUREA IN INFORMATICA
Anno Accademico 2004-2005
TESI DI LAUREA
SPERIMENTALE
TELEVISIONE DIGITALE
SOLUZIONE DI STREAMING PER INTERNET
A BANDA LARGA
Laureando:
Relatore:
Federico Severin
Ch.mo Dott. Claudio Mirolo
2
INDICE
CAPITOLO 1
: Introduzione
4
CAPITOLO 2
: Streaming
5
CAPITOLO 3
: Progetto
8
3.1
: Requisiti
8
3.2
: Analisi
9
3.3
: Organizzazione generale
13
CAPITOLO 4
: Strumenti
14
CAPITOLO 5
: Caratteristiche tecniche
16
5.1
: Dettagli tecnici di Helix Universal Server 9
16
5.2
: Dettagli tecnici di Helix Producer Basic 9
23
: Realizzazione
31
6.1
: Prima prova su PC
31
6.2
: Installazione su PC appositi
32
6.3
: Soluzione problemi con il server
32
6.4
: Applicazione IP pubblico al server
34
6.5
: Creazione dei client personalizzati
38
6.5.1
: Client per un futuro cliente
38
6.5.2
: Client per Asco Tlc
42
: Comunicazione tra Helix Producer Basic 9 ed Helix Universal
47
CAPITOLO 6
CAPITOLO 7
Server Basic 9
CAPITOLO 8
: Comunicazione tra Real Player 9 ed Helix Universal Server Basic 9 53
CAPITOLO 9
: Test, risultati, confronti
63
9.1
: Test in locale
63
9.2
: Test con cliente
63
9.3
: Test con ADSL privata
64
9.4
: Dimostrazione con un potenziale cliente
64
9.5
: Conclusioni sull’esito dei test
65
CONCLUSIONI
66
GLOSSARIO
67
BIBLIOGRAFIA
69
3
CAPITOLO 1
INTRODUZIONE
Il concetto di streaming è poco conosciuto al giorno d’oggi, nonostante venga impiegato sempre
più spesso e per scopi sempre più vari. È una tecnologia innovativa che è destinata a far parte
della nostra vita quotidiana in misura sempre maggiore, grazie anche all’enorme diffusione di
internet ed al continuo incremento della sua velocità. L’esperienza del tirocinio mi ha dato
l’occasione di studiare questa tecnologia, apprenderne il funzionamento, apprezzarne le qualità e
scoprirne i difetti. Questa tesi non è semplicemente il resoconto di un’esperienza didatticolavorativa: ho cercato di approfondire il più possibile gli argomenti trattati, arrivando a volte a
descrivere e spiegare le caratteristiche tecniche di mezzi e strumenti di cui mi sono avvalso.
Comincio con un capitolo in cui definisco lo streaming, la struttura del processo con cui si
trasmette un file multimediale nella rete in broadcasting, i vantaggi e gli svantaggi nell’uso di
tale tecnologia.
Nel capitolo 3 ho sviluppato una descrizione dell’organizzazione dei lavori condotta analizzando
i requisiti dell’azienda. Nel capitolo 4 ho elencato e descritto brevemente gli strumenti che mi
hanno permesso di risolvere i problemi, semplificato lo sviluppo e consentito di svolgere
accurate analisi. Il capitolo 5 è dedicato ad una descrizione tecnica dei due elementi principali di
questo lavoro: Helix Universal Server ed Helix Producer Basic.
Nel sesto capitolo racconto ed analizzo l’esperienza maturata in azienda, dalle prime prove del
server di streaming alla sua raffinazione, alla creazione delle tv embedded per vedere sia video
on-demand che live.
Il settimo ed ottavo capitolo riportano un’analisi dettagliata ed approfondita dei protocolli di
comunicazione server-client e server-producer. Numerosi screenshot arricchiscono questo
approfondimento, che è stato di essenziale importanza per capire il funzionamento delle
architetture in gioco e risolverne i problemi.
Infine, nel capitolo 9, ho inserito alcuni semplici test eseguiti per determinare le prestazioni del
sistema di streaming.
4
CAPITOLO 2
STREAMING
Cosa si intende per streaming? Lo streaming è una tecnologia che permette di distribuire dati,
audio, video e multimedia sulla rete, live o on-demand, senza il bisogno di scaricare file sul
proprio computer. La distribuzione di multimedia in streaming consiste nella trasmissione
simultanea di media digitali (quali video, voce, dati) in modo tale che siano ricevuti come un
flusso continuo in tempo reale. Lo stream di dati viene trasmesso da un server ed è ricevuto da
un client che lo riproduce in tempo reale. Le applicazioni client possono cominciare a riprodurre
il multimedia appena hanno ricevuto abbastanza dati da riempire il buffer (operazione detta di
“preroll”) in modo da poter garantire la continuità del servizio in caso di perdita di dati.
I protocolli coinvolti nello streaming sono principalmente l’RTP e l’RTSP (vedi Glossario).
I passi principali in un processo che ha come scopo la trasmissione di un file multimediale in
streaming nel web sono i seguenti:
CATTURA AUDIO/VIDEO ED
ACQUISIZIONE DEL SEGNALE
CODIFICA DEL CONTENUTO
CONSEGNA/DISTRIBUZIONE
INTEGRAZIONE IN INTERFACCE
WEB
Figura 2.1
Cattura audio/video ed acquisizione del segnale: la prima cosa da fare è procurarsi il materiale
da trasmettere. È dunque necessario catturare e registrare, tramite opportuni dispositivi (quali
webcam, microfoni o schede di acquisizione audio/video), la clip desiderata. I dati catturati dai
5
dispositivi hardware devono essere trasmessi alla locazione in cui verranno codificati. La
trasmissione può avvenire tramite satellite per esempio, o tramite un ponte telefonico. Varia a
seconda del tipo di media e dei mezzi a disposizione.
Codifica del contenuto: i dati acquisiti vengono convertiti da analogico a digitale e codificati nel
formato più appropriato per poter essere poi distribuiti sulla rete. Nel nostro caso verrà usata la
tecnica denominata Sure Streaming, con cui diversi flussi vengono codificati con tassi di
trasferimento diversi e combinati in un singolo file.
Consegna/distribuzione: è la fase in cui i dati codificati vengono inviati al server adibito alla loro
distribuzione. Come si vedrà, i server odierni danno la possibilità di ricevere stream previa
autenticazione, per ovvie ragioni legate alla sicurezza. Anche per visualizzare il contenuto in
streaming può essere richiesta l’autenticazione. La distribuzione del contenuto ai client può
avvenire in due modalità: unicast e multicast. Verranno entrambe descritte nel capitolo 5,
paragrafo 1.
Integrazione in interfacce web: la distribuzione nel web di contenuti multimediali può essere
operata inserendo in pagine web collegamenti che aprono automaticamente un lettore
multimediale che riproduce il filmato. Alternativamente si può inserire direttamente in una
pagina web uno schermo virtuale che riproduce il filmato e, qualora si voglia, dei controlli per
consentire l’interattività dell’utente.
Questa tecnologia innovativa rende le comunicazioni più efficaci premettendo, per esempio, di
effettuare videoconferenze o la telefonia over IP. Strumenti molto utili nelle aziende odierne che,
per svilupparsi ed essere competitive, necessitano di comunicazioni sempre più frequenti, rapide
e ricche di informazioni. Sta prendendo piede, in ambito commerciale, anche in servizi rivolti
verso utenti privati. Basti pensare alla martellante pubblicità in tv che reclama la possibilità di
guardare le partite o le gare automobilistiche in streaming via internet. Possono altresì essere
trasmessi in streaming anche alcuni video o trailer cinematografici o spezzoni di canzoni, o
anche canzoni intere; infatti, non venendo memorizzato alcun dato sull’hard disk, è possibile
avere un’anteprima o assaporare per intero il lavoro di un artista distribuito da un sito
autorizzato, pur senza violare le normative concernenti il diritto d’autore. Nello stesso tempo si
evita di occupare grosse quantità di spazio sul disco del navigatore web.
6
Quanto a svantaggi, il più importante sembra essere il costo. Se si vuole adottare un server di
streaming potente ed efficiente bisogna spendere qualche migliaio di euro, per non parlare della
necessità di un computer dedicato molto potente e una connessione a banda larga.
7
CAPITOLO 3
PROGETTO
Vado ora ad esporre il progetto vero e proprio. Verrà effettuata un’analisi dei requisiti basata
sulle esigenze dell’azienda. Tali requisiti verranno poi analizzati e, in base a questi, sarà condotta
un’indagine sui prodotti disponibili sul mercato e operata una scelta basata sui criteri dettati dai
requisiti.
3.1: REQUISITI
L’azienda aveva la necessità di un server che fosse in grado di trasmettere file multimediali. Un
obiettivo era quello di poter vedere via web presentazioni, conferenze, convegni o simili
organizzati dalla ditta; ma target forse più affascinante era quello di riuscire a creare un sistema
che permettesse la trasmissione di immagini e/o suoni in un broadcast live. Tale sistema,
permettendo di vedere real-time immagini e audio, sarebbe poi stato la base per lo sviluppo di un
sistema di video-conferenza. Un sistema facilmente personalizzabile, grazie alla potenza della
combinazione dei linguaggi HTML e SMIL: pagine web con il logo della società e un player
embedded che supporta persino la visualizzazione di più videate contemporaneamente, nonché
una chat per permettere la comunicazione istantanea di tutti i partecipanti all’evento.
Per raggiungere tali obiettivi erano necessari:
•
Un pc linux su cui far girare il server.
•
Una distribuzione di linux.
•
Un server per lo streaming.
•
Un pc dal quale catturare le immagini live ed inviarle al server a seguito della codifica.
•
Una webcam per catturare i filmati.
•
Un software di codifica delle immagini.
•
Collegamento dei due computer alla rete locale.
•
Collegamento dei computer alla rete Internet.
•
Un player multimediale per la parte client dello streaming.
8
3.2: ANALISI
Viene ora il momento dell’analisi dei requisiti e delle alternative che il mercato propone per
soddisfarle. Una fase molto importante durante la quale si scelgono gli strumenti che ci
condizioneranno durante la progettazione e ci supporteranno durante lo sviluppo.
Mi sono stati messi a disposizione due pc Dell Optiplex, 2.8 GHz, 1GB di ram.
In uno ho installato Windows XP Service Pack 2, fornito dalla Dell insieme alla macchina.
Nel secondo pc, quello dedicato al server, come sistema operativo si è deciso di usare Linux per
la sua comprovata stabilità e la sua sicurezza. Il problema si poneva riguardo quale distribuzione
scegliere. Su consiglio del mio tutor aziendale, ho scelto di usare QiLinux 1.2 (kernel 2.6.11.8),
una distribuzione di recente comparsa e basata su Debian, gratuita e scaricabile dal web.
Per la cattura di suoni e immagini mi è stata messa a disposizione una webcam USB Logitech
QuickCam Pro 4000.
I due computer sono stati connessi entrambi alla rete aziendale. Accedevano ad internet tramite il
router dislocato nella server farm.
La scelta di server, client e producer (il programma per la codifica) è stata invece più complessa.
Serviva un prodotto che fosse in grado di supportare più stream contemporaneamente e più client
contemporaneamente, oltre che gli stream live. Le soluzioni presenti sul mercato sono
innumerevoli, ma molte sono a pagamento e a prezzi che si aggirano intorno ai 5000 euro per i
prodotti più raffinati. L’azienda invece, non necessitando di strumenti particolarmente sofisticati
né potenti, si poteva accontentare del servizio che è in grado di fornire un software gratuito ed
open source. Il campo della ricerca si restringeva così a pochi prodotti gratuiti ma di buona
qualità, sviluppati da alcune tra le case più conosciute nel mondo dell’informatica. Avevo
individuato fondamentalmente tre candidati.
Il primo era Helix Universal Server Basic, sviluppato dalla RealNetworks.
Il secondo candidato era Helix DNA Server, sviluppato da Helix Community in collaborazione
con RealNetworks.
Infine Darwin Streaming Server, versione gratuita di Apple Quick Time Streaming Server.
Ho cercato a lungo informazioni su questi programmi. Riguardo Darwin Streaming Server non
ho trovato molte informazioni, mentre su Helix Universal Server ho trovato molta
documentazione on-line. In particolar modo mi ha colpito un documento reperito dal sito della
RealNetworks che riporta un test comparativo della KeyLabs tra i server di streaming Helix
Universal Server e Windows Media Technology (WMT) 4.1. Sebbene il test sia relativamente
vecchio (è stato realizzato nel giugno 2002 e con tecnologia Dual Intel Pentium III Xeon 700
9
MHz 2 GB di memoria RAM per i server) indica che, oltre a supportare oltre il doppio delle
connessioni client rispetto a WMT 4.1 sotto Windows, Helix Universal Server arriva addirittura
a duplicare le sue stesse capacità quando gira sotto Red Hat Linux. Riporto qui sotto tabelle e
grafici comparativi tratti dal report della KeyLabs.
Figura 3.2.1
Come si può vedere, la prima tabella (in figura 3.2.1) compara le prestazioni dei due programmi
sotto Windows e mostra poi le prestazioni di Helix Universal Server anche sotto Linux. Si nota
subito la differenza anche tra le stesse performance del server della RealNetworks con i due
sistemi operativi. Differenza rimarcata anche dalla seconda e terza tabella, che le traducono in
termini percentuali. La seconda tabella mostra la superiorità di Helix Universal Server rispetto al
prodotto della Microsoft a parità di condizioni (stesso hardware e stesso sistema operativo). La
terza tabella, invece, rimarca il divario nelle prestazioni di Helix Universal Server in ambiente
10
Linux rispetto a WMT, che è stato sviluppato solo per Windows. Tutte e tre le tabelle si
riferiscono a test svolti trasmettendo file multimediali in formato Windows Media 8.
Il grafico in figura 3.2.2 rappresenta con efficacia le dimensioni riportate dalle tabelle e dà una
chiara idea del gap tra i due prodotti.
Figura 3.2.2
Ma i tecnici della KeyLabs non si sono fermati qui: hanno anche testato Helix Universal Server
usando file multimediali nel formato RealNetworks Version 9, ossia nel formato proprietario
della RealNetworks. Com’è logico aspettarsi, le prestazioni sono ancora migliori. I dati nella
figura 3.2.3:
11
Figura 3.2.3
Pur consapevole che questi dati sono, come detto prima, relativamente vecchi e pur sapendo che
il prodotto della Apple poteva essere una valida alternativa, ho considerato l’esperienza della
KeyLabs nel campo dei benchmark ed ho pensato che il prodotto della RealNetworks poteva
essere una buona soluzione per l’azienda.
A questo punto ho preso in considerazione il prodotto offerto dalla Helix Community. Questa
comunità, aperta a tutti, sviluppa software open-source per piattaforme multimediali con la
collaborazione della RealNetworks. Questo significava che avrei potuto avere a disposizione la
tecnologia di una delle compagnie leader nel settore del multimedia unitamente al supporto di un
vasto team di sviluppatori e appassionati. Il sito www.helixcommunity.org infatti mette a
disposizione newsletter, forum e persino chat in cui si possono trovare suggerimenti e porre
domande. Ho così optato per Helix DNA Server come server di streaming. Di conseguenza ho
12
usato Helix Producer Basic 9 (gratuito) e il player multimediale (anch’esso gratuito) Real Player
9.
3.3: ORGANIZZAZIONE GENERALE
Spiego ora come ho deciso di procedere.
•
Prima di tutto dovevo montare e testatare i pc comprati appositamente per lo scopo. Uno
l’avrei usato come server; l’altro come client, postazione di cattura e codifica delle
immagini nonché come postazione di sviluppo per il client personalizzato.
•
Nelle due macchine era installato Windows XP come sistema operativo ma era
un’installazione personalizzata creata dalla Dell. Ho subito riscontrato anomalie ed
instabilità nel comportamento del sistema operativo, così che ho deciso di reinstallarlo.
Nella macchina adibita a client avrei reinstallato Windows XP Service Pack 2 e l’avrei
protetto con un antivirus (AVG) e un firewall (Sygate) che si trovano gratuiti su inernet.
In seguito avrei proceduto con l’installazione della webcam e di Helix Producer Basic.
•
Nel pc adibito a server invece dovevo installare QiLinux e la versione 11 beta 2 di Helix
DNA Server.
•
Una volta installato il binario del server, avrei provato per prima cosa lo streaming on
demand per testare il funzionamento del software.
•
In un secondo momento, dopo essermi sincerato dell’efficienza del server, sarebbe stato
il momento di provare con lo streaming live.
•
Appena reso operativo uno stream live, misurare eventuali ritardi.
•
Impostare per il server un IP pubblico e verificarne il funzionamento.
•
Costruire un client personalizzato con un player embedded su pagina web.
13
CAPITOLO 4
STRUMENTI
Oltre ai sistemi operativi, al server, al client e al producer già citati nel paragrafo 3.2, mi sono
avvalso di alcuni strumenti che vado ad elencare qui sotto.
•
IPTraf: utility di Linux che fornisce statistiche ed informazioni importanti sulle
connessioni TCP aperte e sul traffico UDP che passa attraverso l’interfaccia di rete. Lo
vedremo nel dettaglio in un esempio pratico nel capitolo 5.
•
Ethereal: programma simile a IPTraf, mi è stato molto utile nel monitorare il traffico lato
client. Specificata un’interfaccia di rete, è sufficiente premere “start” per far iniziare la
cattura dei pacchetti che attraversano la rete. A differenza di IPTraf, Ethereal cattura
pacchetti solo per un lasso di tempo stabilito dall’utente. Infatti bisogna premere “stop”
per interrompere lo sniffing e poter visualizzare i risultati, mentre IPTraf usa una finestra
a scorrimento dove i pacchetti nuovi compaiono in fondo e quelli vecchi, se non ci stanno
più, scompaiono dalla visuale. Non si può salvare nessuna informazione con IPTraf,
mentre Ethereal permette di salvare le informazioni catturate. Questa opportunità mi è
stata molto utile per poter studiare con calma la composizione del traffico. Ethereal
inoltre fornisce molte più informazioni di IPTraf sui singoli pacchetti. Quest’ultimo
infatti fornisce solamente la dimensione del pacchetto, l’origine e la destinazione.
Ethereal invece scompone ogni pacchetto in tutte le sue parti (per esempio header, flag,
payload, codice di correzione degli errori) specificando la dimensione di ciascuna parte e
i valori che essa assume. Se vengono trasmessi dati umanamente leggibili, come stringhe
di testo, Ethereal le visualizza. Nei capitoli 7 e 8 dimostrerò come questo utilissimo
strumento mi abbia permesso di studiare il protocollo di comunicazione tra il producer e
il server e tra il client e il server.
•
Dreamweaver: strumento molto potente per la realizzazione di siti web creato dalla
Macromedia, mi è stato utile per creare le pagine web dei client. Mi è tornato utile per
impostare la struttura delle pagine in modo semplice e veloce grazie alla creazione
semplificata delle tabelle e dei frame, ma il resto del lavoro ho preferito svolgerlo
utilizzando direttamente il codice HTML.
•
WordPad: come ho appena detto, ho editato buona parte del codice HTML “a mano”.
Questo semplice strumento, presente ormai di default in Windows, mi ha permesso di
scrivere il codice agilmente grazie alla sua semplicità e rapidità. La sua leggerezza si fa
apprezzare quando bisogna apportare poche modifiche in varie pagine e bisogna saltare
14
da una all’altra aprendole per editarne il sorgente. La formattazione del testo è altresì
utile per strutturare il codice in modo da renderlo più comprensibile e più accessibile
anche a terzi.
•
Webmin: pratico strumento per l’amministrazione della rete. Molto apprezzato dai
sistemisti per la sua intuitività dovuta ad un’accattivante interfaccia grafica che permette
di trovare immediatamente le risorse, ben divise per categorie, e modificarne i parametri
di configurazione.
15
CAPITOLO 5
CARATTERISTICHE TECNICHE
5.1: DETTAGLI TECNICI DI HELIX UNIVERSAL SERVER 9
1. Formati supportati:
•
RealNetworks: RealAudio (.rm), RealVideo (.rm, .rmvb), RealPix (.rp), RealText
(.rt)
•
Macromedia: Flash (.swf)
•
Microsoft: Windows Media (.asf, .wma, .wmv)
•
Apple: QuickTime (.mov)
•
Standards-Based: MPEG-1, MPEG-4, MP3
•
Image Formats: GIF (.gif), JPEG (.jpg, jpeg), PNG (.png)
•
Altri: AU (.au), AIFF (.aif, .ief), WAV (.wav)
2. Protocolli supportati:
•
Real Time Streaming Protocol (RTSP)
•
Progressive Networks Audio (PNA): vecchio protocollo usato dalla Real, mantenuto
per questioni di compatibilità.
•
Microsoft Media Services (MMS)
•
HyperText Transfer Protocol (HTTP): non è un protocollo di streaming ma è
utilizzato in vari modi, come la consegna delle pagine web di Helix Administrator che
permettono la configurazione del server, o per aggirare le restrizioni dei firewall
tramite cloaking.
3. Aliasing: tecnica grazie alla quale il server maschera l’URL pubblico in cui si trova il file
richiesto.
4. Content Caching (figura 5.1.1): il media player richiede il file ad un server detto
“subscriber” che controlla se nella sua cache è già presente il file. Se non c’è, lo richiede
ad un server “publisher” che gli manda tutto o parte del file. In genere il subscriber
richiede una quantità di dati che dipende dalla velocità di trasferimento del client in modo
da risparmiare spazio della cache. Questa viene svuotata usando una politica LRU. Se il
file viene cancellato sul publisher, non viene più trasmesso dal subscriber, anche se si
trova ancora nella cache. Nel caso vi siano un cluster di server publisher, le richieste
16
vengono inoltrate con una politica di DNS rotation o Round Robin DNS per distribuire il
carico.
Figura 5.1.1
5. Custom Logging: sistema flessibile che permette di creare report personalizzati.
6. SLTA: Simulated Live Transfer Agent. Utility che permette di riprodurre in streaming
una clip video come se fosse un evento live.
7. RTSP Cache Directives: la possibilità di imporre restrizioni ai server Helix Universal
Proxy riguardo la memorizzazione nella cache delle clip.
8. Redundant Servers (figura 5.1.2): ridondanza dell’informazione da spedire. In caso di
interruzione del collegamento con il server (ad esempio a causa di un guasto sul server o
sulla linea), RealOne Player è in grado, grazie ad una lista di server alternativi fornita
durante il set-up del collegamento, di stabilire una nuova connessione con un altro server
scegliendo a caso tra quelli disponibili.
17
Figura 5.1.2
9. Windows Media Streaming: usando MMS (Microsoft Media Services protocol) o HTTP
invia in streaming anche file in formato Windows Media.
10. RTP-Delivered Formats: il formato RTS per i pacchetti è usato come standard di default
con Quick Time e MPEG e opzionalmente con Real Media. Questo formato permette di
trasmettere le clip sfruttando il protocollo RTSP.
11. SureStream Splitting (figura 5.1.3): vengono inviate al client man mano parti del file le
cui dimensioni dipendono dal suo bit-rate.
Figura 5.1.3
18
Il server sceglie il bitrate in base alla stima iniziale che Real Player gli invia tramite il
protocollo RTSP. In seguito adatta il rate in base alle condizioni della rete per evitare la
perdita di troppi dati che causerebbe il blocco della riproduzione.
12. RealOne Player Statistics: informazioni su stream aperti e bit-rate dei client connessi.
13. Distributed Licensing: un gruppo di server della stessa organizzazione che condividono
dei files possono condividerne anche l’eventuale licenza, le cui informazioni sono
generalmente mantenute su un server publisher primario.
14. Port Hinting: per i client che ricevono dati da Helix Universal Server solo attraverso
HTTP cloaking per passare attraverso un firewall, il numero di porta non è più quello
standard del protocollo RTSP (che viene bloccata dal firewall) ma la 80 dell’HTTP.
Quindi si fornisce tramite l’URL la porta corretta.
15. HTTP Cloaking: alcuni firewall limitano protocolli di streaming come RTSP o MMS e il
client non riesce a stabilire la connessione. In questi casi, il client e il server mascherano
il traffico multimediale come HTTP, una soluzione conosciuta come “HTTP cloaking”.
Poichè la maggior parte dei firewall lascia passare il traffico HTTP, questa soluzione
risolve il problema. Tuttavia HTTP non è stato progettato per lo streaming e gli utenti
non ottengono la massima qualità dallo stream. I client RTSP usano due stream HTTP
per connettersi ad un unico Helix Universal Server. La prima connessione sfrutta il
comando HTTP GET, usato per richiedere una Web page. Helix Universal Server elimina
il mascheramento HTTP e usa le informazioni RTSP incapsulate per determinare quali
informazioni mandare al client. Helix Universal Server quindi aspetta la seconda
connessione HTTP dallo stesso client per poter procedere con lo streaming del media.
Questa seconda connessione usa il comando standard per richiedere dati da un server
HTTP: HTTP POST. Una volta che il client ha stabilito questi due stream, inizia con
Helix Universal Server a passarsi pacchetti RTSP in due direzioni, attraverso un firewall
che blocca il traffico RTSP.
16. Redundant Encoders (figura 5.1.4): ridondanza dei codificatori dei file multimediali da
inviare in streaming. Se un codificatore va in crash ce n’è subito pronto uno alternativo.
19
Figura 5.1.4
17. Unicasting (figura 5.1.5): è il modo più semplice per trasmettere uno stream live. Il
server invia ad ogni player multimediale uno stream distinto. Con questa tecnica può
trasmettere sia un evento live che un media on-demand. Gli stream separati consentono
ad ogni client di interagire con esso come se si stesse guardando un filmato in locale,
quindi controllandone la riproduzione per esempio mettendola in pausa o saltando ad un
punto preciso.
Figura 5.1.5
18. Multicasting: a differenza dell’unicast, la tecnica del multicasting trasmette il media su di
un unico stream al quale possono collegarsi più utenti contemporaneamente. La figura
5.1.6 mostra una tipica situazione di streaming multicast.
20
Figura 5.1.6
Nonostante siano tutti collegati allo stesso stream, ciascun client può mantenere un canale
di controllo con il server che permette di inviare comandi come “stop”, inviare statistiche
all’archivio dei log, inviare i dati necessari ad un’eventuale autenticazione, tenere traccia
nel server del numero di client connessi che, vista l’onerosità implicita nel mantenimento
del canale, sarà limitato. Questa tecnica è detta “back-channel multicasting” (figura
5.1.7).
Figura 5.1.7
Utilizzando invece la tecnica “scalable multicasting” (figura 5.1.8) non viene mantenuto
un canale di controllo e si può trasmettere ad un numero illimitato di player multimediali.
La comunicazione infatti è unidirezionale, usa una porzione minore di banda, impegna
21
meno risorse di sistema del server e si ha minore overhead amministrativo. Ovviamente
non sarà possibile ricevere statistiche né sapere quanti client sono connessi.
Figura 5.1.8
19. Tabella riassuntiva: la tabella 5.1.1 riassume le caratteristiche di Helix Universal Server
mostrando i servizi che è in grado di offrire a seconda del formato del media trattato.
22
Helix Universal Server
Windows
Apple
RTP-
Feature
Media
QuickTime
Based
HTTP cloaking for firewalls
yes
no
no
Launch utility for Web page links
yes
no
no
Aliases in URLs
yes
yes
yes
Viewable clip source information
no
no
no
Reconnection to a redundant server no
no
no
Cached content
yes
yes
yes
yes
yes
yes
Unicasting
yes
yes
yes
Redundant live stream encoders
yes
yes
yes
Back-channel multicasting
no
no
no
Scalable multicasting
yes
yes
yes
yes
yes
yes
Simulated live broadcasts
yes
yes
yes
Access control by IP address
yes
yes
yes
no
yes
no
Media player ID validation
no
no
no
SMIL-based ad insertion
no
no
no
Access request logging
yes
yes
yes
Custom logging reports
yes
yes
yes
Online activity monitoring
yes
yes
yes
Proxied on-demand and live
streams
Splitting from transmitter to
receiver
User name and password
validation
Tabella 5.1.1
5.2: DETTAGLI TECNICI DI HELIX PRODUCER BASIC 9
Helix Producer è un programma che serve per codificare e comprimere i dati audio e video che
arrivano da una sorgente (quale potrebbe essere una webcam) preparandoli per la trasmissione al
23
server di streaming. Non solo: è anche in grado di convertire vari formati di file in modo da
poterli poi trasmettere con Helix Universal Server.
Helix Producer Basic supporta i seguenti tipi di file:
AIFF Files: *.aif; *.aifc; *.aiff
AVI Files: *.avi
Digital Video Files: *.dv
MPEG: *.mpg; *.mpeg; *.m1v; *.mp2; *.mp3
NeXT Sound Files: *.snd
QuickTime Files: *.mov; *.qt
Sun Audio Files: *.au
WAV Files: *.wav
Windows Meta Files: *.wma; *.wmf; *.wmv
La figura 5.2.1 mostra la schermata principale di Helix Producer:
Figura 5.2.1
24
Nella parte di sinistra si sceglie la sorgente per l’audio e per il video, che sono mantenute distinte
dando la possibilità, per esempio, di creare un video con una colonna sonora musicale anziché
con l’audio originale. In alternativa si prende in input un file. In tal caso il file verrà convertito
nel formato “rm”. C’è anche la possibilità di limitare la cattura audio/video con un tempo
preimpostato.
Il pulsante “Video Filters” nella parte di destra apre una finestra nella quale si possono impostare
vari filtri quali noise filter, resize filter, inverse-telecine e de-interlace filter. In “Clip
Information” si possono invece impostare informazioni riguardanti la clip, come la provenienza,
il genere e altre. Molto più interessante è il pulsante “Audiences” che consente di scegliere fino a
tre bitrate ai quali codificare la clip (nella versione Plus si possono codificare infiniti bitrate). Il
Sure Splitting si può così garantire grazie alla codifica a più bitrate dello stesso file. In genere
codificavo il bitrate della clip per un modem a 56 Kbps (34 Kbps effettivi per la trasmissione
della clip in streaming), una ISDN a 128 Kbps (100 Kbps effettivi) e un’ADSL a 500 Kbps (450
Kbps effettivi).
La figura 5.2.2 mostra come appare l’interfaccia che permette di impostare i suddetti parametri:
Figura 5.2.2
25
Sempre sulla destra (della figura 5.2.1) si trova un pulsante con l’icona di un server che apre una
finestra di dialogo nella quale inserire i dati del server di destinazione della clip. Dati quali
indirizzo IP, porta di destinazione, nome del file di destinazione, eventuale mount point ed
eventuali user name e password. Gli ultimi due non sono richiesti per tutti i tipi di broadcast.
Ecco nel dettaglio quali sono le modalità di broadcast e in cosa consistono.
Account-Based Push Broadcast (figura 5.2.3): è la modalità standard di trasmettere all’audience
attraverso il server i media codificati. Il vantaggio principale del metodo Push è che i dati
vengono appunto “spinti” dentro il server continuamente, quindi un client che si collega non
deve aspettare che il producer si colleghi al server (come nel metodo Pull) e non subirà alcun
ritardo. Ecco cosa succede:
Figura 5.2.3
Al passo 1 il producer si collega al server ed invia user name e password.
Al passo 2 il server dà la conferma della avvenuta connessione e delle modalità di trasmissione
dei pacchetti (come le porte alle quali indirizzarli).
Al passo 3 il producer inizia la trasmissione dei dati, sia che un client li abbia chiesti o no.
Al passo 4 vi è un client che si collega al server e richiede lo stream.
Al passo 5 il server invia i dati al client che li decodifica e riproduce.
Questa è la modalità che ho scelto di usare per la semplicità e sicurezza, oltre ai bassi tempi di
latenza e dato che non sussistevano problemi di spazio su disco nel server. La comunicazione tra
producer e server e tra client e server sarà approfondita nei capitoli 7 e 8.
26
Password-Only Push Broadcast (figura 5.2.4): questa modalità è consigliata solo per gli esperti.
Il principale vantaggio è che non è necessaria una connessione iniziale con autenticazione.
Questo comporta un leggero guadagno nelle prestazioni. Il rovescio della medaglia è che il
producer non ha un feedback da parte del sever quindi, se qualcosa non andrà a buon fine, il
broadcast non raggiungerà il server e il producer non avrà riscontri.
Figura 5.2.4
Al passo 1 il producer si collega al server inviando la password ed iniziando subito la
trasmissione dei pacchetti senza che nessuno debba richiederla, come nella modalità precedente.
I passi 2 e 3 sono come il 4 e 5 rappresentati nella figura 5.2.3.
Multicast Push Broadcast (figura 5.2.5): anche questa è una modalità raccomandata soltanto agli
esperti. Il producer invia i dati a più server che si agganciano allo stesso stream, risparmiando
larghezza di banda e carico dei server usando server multipli per consegnare il contenuto.
Figura 5.2.5
27
Se non si usasse il multicasting, il producer manderebbe uno stream separato ad ogni server.
Il Multicast Broadcasting può anche essere usato per il broadcasting attraverso una rete satellitare,
dove le connessioni a due vie non sono supportate ma esistono solo monodirezionali.
Pull Broadcast (figura 5.2.4): in questa modalità la clip viene codificata ma non viene inviata al
server fintantochè un client non la richiede. Il vantaggio è che se una clip deve essere sempre
disponibile ma viene richiesta raramente, con questo metodo si risparmia spazio sul disco del
sever e si preserva larghezza di banda.
Figura 5.2.6
Al passo 1 inizia la codifica della clip ma non viene ancora inviata.
Al passo 2 un utente usa il suo Real Player per richiedere il broadcast.
Al passo 3 il server, che ha ricevuto la richiesta dal client, inoltra la richiesta al producer. Una
volta che la connessione col producer sarà approntata, il server continuerà a mandare richieste di
invio dei dati fintanto che il client continuerà a richiederli ("keep alive" requests).
Al passo 4 il producer stabilisce la connessione con il server e continuerà a mandare dati finchè
verranno richiesti.
Al passo 5 si vedono i dati arrivare finalmente al client che li può decodificare e riprodurre.
Legacy Push Broadcast: è una modalità che permette la connessione del producer con un server
Helix di una versione precedente alla 9. Prima di usare questa modalità è bene conoscere alcune
informazioni importanti del server a cui ci si vuole connettere: indirizzo IP, porta di
comunicazione, username, password, etc.
28
Ora ci sono tutte le informazioni neccessarie a creare uno stream live di dati. Quando inizia la
trasmissione, si vede nella schermata di sinistra l’immagine catturata dal dispositivo e sulla
destra quella codificata dal producer. Le due colonne a sinistra delle videate sono gli indicatori di
livello dell’audio. La figura 5.2.7 indica come dovrebbe apparire il producer durante la codifica
di una clip video:
Figura 5.2.7
Il menu a tendina sopra la finestra di destra permette di scegliere, durante la codifica, il bitrate
rispetto al quale visualizzare l’anteprima del video codificato. Molto utile per controllare la
qualità del prodotto che si sta creando.
L’area bianca a metà schermo sulla destra mostra lo status della connessione col server nel caso
di un live broadcasting. Quella grande in fondo invece mostra lo status del job.
Questi sono gli aspetti principali di Helix Producer Basic. Oltre a queste opzioni ve ne sono
molte altre più avanzate ma non di rilievo per il mio lavoro.
29
CAPITOLO 6
REALIZZAZIONE
6.1: PRIMA PROVA SU PC
La primissima prova di Helix DNA Server è stata eseguita su un PC con QiLinux. Dopo aver
installato il server ho cercato di accedere alla sezione di amministrazione per configurarlo ma ho
incontrato alcune difficoltà: l’Helix Administrator sfrutta un’interfaccia grafica basata su pagine
html ma in quel momento la mancanza del plug-in java per il browser non mi permetteva di
visualizzare le pagine correttamente. Ho così deciso di demandare la configurazione e passare
immediatamente ad una prova pratica: ho inserito dei file .mp3 nella cartella “Content” di Helix,
cartella che contiene i file da trasmettere on demand sulla rete. Quindi, dal mio computer
personale (Apple iBook G4), ho provato ad inviare una richiesta tramite protocollo rtsp alla
macchina che ospitava il server scrivendo la seguente stringa nel browser Safari:
rtsp://192.168.1.203/test.mp3. Si apriva immediatamente un pop-up di QuickTime che cercava di
caricare il file test.mp3 ma senza successo. RealPlayer e iTunes portavano allo stesso risultato.
Inizialmente pensavo che non riuscisse ad accedere alla cartella “Content”, così ho provato a
modificare i permessi di accesso alla cartella ma senza nessun risultato. Quindi ho pensato che
probabilmente non vedeva il server, forse nemmeno a livello fisico. Con un ping all’indirizzo del
server ho verificato che il collegamento fisico fosse stabilito. In seguito all’esito positivo di
questo test ho verificato le impostazioni di rete del server per accertarmi che l’indirizzo che
avevo fosse corretto e che la maschera di sottorete fosse la stessa impostata sul mio computer,
altrimenti i due non si sarebbero potuti “vedere”. Nessun errore riscontrato. I miei dubbi si sono
rivolti alla porta 554 (quella adibita al protocollo rtsp) quindi dovevo verificare che non fosse
chiusa. Un telnet eseguito dalla macchina server alla suddetta porta aveva successo, mentre se
eseguito dal mio notebook dava esito negativo. Ciò significava che la porta era aperta ma un
client non poteva collegarsi da un computer esterno perché veniva bloccato da qualcosa. Quel
qualcosa era il firewall di linux che ho provveduto a disattivare usando Webmin: questo
programma usa una tabella degli IP autorizzati che per semplicità ho disabilitato, in modo che
qualunque computer avesse pieno accesso alle porte. Così è stato infatti: tutti e tre i client sopra
menzionati hanno riprodotto senza problemi il file test.mp3 e un altro file .mp3 all’interno della
medesima cartella “Content”.
30
6.2: INSTALLAZIONE SU PC APPOSITI
In seguito mi sono stati messi a disposizione due pc DELL. Su uno ho installato QiLinux 1.2,
mentre sull’altro Microsoft Windows XP Professional Service Pack 2. Naturalmente, in entrambi
ho installato Helix DNA Server e, sul pc Windows, anche Helix Producer Basic (free) e una
webcam. Contavo infatti di utilizzare quest’ultima postazione per la produzione di uno stream
audio e video live da inviare al server Linux. Prima però sarebbe stato più semplice provare la
cosa in locale.
Dapprima ho riprovato con la riproduzione di file on-demand e la cosa non è stata problematica.
Ho provato allora a configurare Helix Producer Basic per codificare ed inviare al server uno
stream live. Da qui sono iniziati i problemi dal momento che non sono stato in grado di inviare il
flusso di dati prodotto al server. Ho provato ad installare anche Real Producer 10 Plus ed Helix
Universal Server Advanced 9.07 (entrambi trial) per vedere se erano di utilizzo più immediato
ma senza ottenere cambiamenti di rilievo.
Il producer codificava i dati catturati dalla webcam ma non riusciva a mandarli al server.
Sistematicamente compariva un messaggio di errore rosso nella finestra che indicava lo status
della connessione con il server: “Authentication failed”. I dati immessi durante la configurazione
del job erano senza dubbio corretti, eppure non riusciva ad autenticarsi.
Ho allora abbandonato per un momento i prodotti Helix per fare una prova con VLC media
player. Si tratta di un interessante programma open source che funge, oltre che da client, anche
da producer e server. Grazie a questo sono riuscitito a vedere live su un altro pc quello che la
webcam catturava e sono così stato in grado di fare una breve dimostrazione di streaming live ad
un potenziale cliente, al quale poi potrebbe essere venduto il servizio una volta realizzato;
servizio che comprenderebbe anche un client personalizzato con SMIL.
6.3: SOLUZIONE PROBLEMI CON IL SERVER
Nonostante VLC si rivelasse di utilizzo più immediato, era altresì evidente che non forniva le
potenzialità di comunicazione e configurazione fornite dal progetto Helix. Fu ben presto chiaro
infatti che non sarebbe stato semplice configurare VLC per distribuire in broadcast uno stream
live a causa del fatto che i parametri di configurazione erano di difficile accesso e
interpretazione. Per non parlare della potenza: VLC è nato come player multimediale piuttosto
31
che come server di streaming. Tuttavia si è svelato di semplice impiego per inviare i dati ad un
solo client.
A seguito di questa confortante esperienza con VLC, sono tornato ad Helix. Approfondite
ricerche ed esperimenti inconcludenti mi convincevano sempre più che in Helix DNA Server
mancava qualcosa. Nella guida on-line è scritto che per ricevere stream live da un producer è
necessario scegliere “Enable” dal menu a tendina alla voce “Live Archiving” del menu
dell’Administrator. Il problema era che nella pagina di amministrazione quella voce mancava e
non ce n’era una equivalente. Con grande delusione ho constatato che dal forum del sito ufficiale
non ottenevo aiuto, nonostante molte persone avessero il mio stesso problema. L’unico
suggerimento era di editare manualmente il file di configurazione togliendo il commento ad
alcune righe. Non cambiava nulla. Avevo perso molto tempo ed energie senza raggiungere alcun
risultato, così ho deciso di tentare installando la versione base di Helix Universal Server. Ho
notato subito una sezione dell’Administrator che non c’era nel DNA Server: “Broadcasting”. In
questa sezione si trova la voce “Live Archiving”, nella quale mi è bastato scegliere “Enable” dal
menu a tendina che chiede se si vuole abilitare l’archiviazione degli stream live. È bastato questo
per far funzionare il tutto alla perfezione. Se lo stream live si chiama “live.rm”, basta scrivere nel
campo “URL” del player multimediale: rtsp://<indirizzo server>/broadcast/live.rm. In questo
modo era possibile vedere, tramite Real Player, le immagini riprese dalla telecamera da qualsiasi
computer connesso alla rete locale. Persino da un palmare: sono riuscito a visualizzare video e
audio live in ottima qualità anche su un palmare collegato alla rete via wi-fi.
Le differenze tra Helix DNA Server ed Helix Universal Server tuttavia non si fermano qui. Ho
effettuato un test per verificare se erano in grado di trasmettere gli stessi tipi di file ed ho
osservato che c’è una leggera differenza anche in questo. Helix DNA Server infatti è in grado di
trasmettere, oltre ovviamente ai file “rm”, soltanto gli “mp3”. Helix Universal Server invece non
dispone della licenza per trasmettere gli “mp3” in quanto è una versione base, però trasmette i
“wav” e, seppur con alcuni problemi, anche gli “avi”. Non tutti gli “avi” vengono trasmessi,
anzi, molti tenta di trasmetterli ma o non ci risultano o si vedono immagini confuse. Una tabella
riassuntiva (tabella 6.3.1) contribuirà a chiarire le idee. Dove indicato “no” non significa che
l’applicazione non è in grado di riprodurre il formato ma semplicemente che con la versione
“free” non è prevista.
32
Formato file
Helix DNA Server
Helix Universal Server
mp3
sì
no
wav
no
sì
rm
sì
sì
avi
no
sì (non tutti)
mov
no
no
mpg
non supportato
no
mp4
no
no
wmv
no
no
swf
no
no
streaming live
no
sì
Tabella 6.3.1
6.4: APPLICAZIONE IP PUBBLICO AL SERVER
Per rendere il servizio accessibile dall’esterno, ossia da internet, si rendeva necessario assegnare
un IP pubblico al server e settare il firewall in modo che lasciasse aperte le porte necessarie alla
comunicazione.
Inizialmente non sono riuscito a far funzionare il sistema poiché la comunicazione tramite
protocollo UDP dava problemi. Infatti, il Producer effettuava correttamente la connessione al
server e mandava i dati dello stream, ma questi non arrivavano a destinazione. Real Player, di
conseguenza, mi dava un errore che indicava che il file richiesto non era presente o non era
aggiornato. Ho così usato sul server un’utility di Linux chiamata IPTraf che mi permette di
monitorare in tempo reale le connessioni TCP/IP e il traffico UDP. Sebbene fosse presente la
connessione TCP tra i due pc, non arrivavano pacchetti UDP dall’indirizzo del Producer. Allora
ho “sniffato”, come si dice in gergo, il traffico sul pc del producer con un programma gratuito,
Ethereal. Ho potuto notare che, dopo un handshake a tre vie per stabilire la connessione,
venivano inviati al server i dati necessari all’autenticazione. Questo rispondeva con un “ok” ed
alcuni dati necessari a stabilire il flusso di dati UDP, tra cui le porte utilizzate. In seguito il
Producer inviava pacchetti UDP alla porta indicata dal server, ma a questo non arrivavano. Oltre
a ciò, ogni 2 secondi, il server inviava un frame di controllo al producer che sembrava indicare
33
quanti pacchetti aveva ricevuto e quanti ne aveva persi. Il messaggio “Total packets = 0”
sembrava indicare in maniera eloquente che al server non arrivava nulla (in realtà, come
vedremo nel capitolo 7, questa interpretazione va precisata). In risposta a questo pacchetto il
Producer inviava un ACK, ma continuava a spedire dati come se nulla fosse. Le relative porte
erano aperte e non capivo come mai il traffico non arrivasse. Così ho provato ad usare il
protocollo TCP per far comunicare i due computer poiché, essendo un protocollo orientato alla
connessione, una volta che questa fosse stata stabilita i due pc non avrebbero dovuto avere
problemi a scambiarsi dati. Infatti è proprio quello che è successo: lo streaming funzionava alla
perfezione. Bisogna tener conto dei firewall che spesso, come anche in questo caso, sono molto
più selettivi rispetto ai pacchetti UDP piuttosto che rispetto al TCP. Stabilendo le regole del
firewall si può tener conto del fatto che una connessione TCP lanciata dall’interno presuppone
dei pacchetti in risposta, mentre non sempre si sa se dei pacchetti UDP in entrata sono stati
richiesti da qualche servizio o sono, invece, “abusivi”.
Il TCP è un protocollo più affidabile rispetto all’UDP, ma proprio questa potrebbe rivelarsi
un’arma a doppio taglio: il fatto che se un pacchetto viene perso ne venga richiesta la
ritrasmissione implica, in caso di congestione del traffico, un rallentamento che può portare al
blocco del flusso di dati.
Impostando un IP locale fisso al pc del producer e aprendone tutte le porte, ma soltanto verso il
server di streaming, sono riuscito a far comunicare il producer con il server anche tramite il
protocollo UDP. Prima non ci riuscivo perché il firewall, che si trova tra la rete internet e il
Producer, non permetteva di far passare i pacchetti UDP diretti al server. Assegnandogli un IP
fisso è stato possibile impostare le regole del firewall in modo da aprire tutte le porte da (e verso)
il server. Il Producer apre ad ogni avvio una porta diversa per comunicare con il server, quindi è
stato necessario aprirle tutte. Si potrebbe pensare che questa situazione possa essere
potenzialmente pericolosa. Tuttavia sia il server che il producer si trovano dietro un firewall.
Quello del producer lascia passare il traffico in entrata solamente se proviene dall’indirizzo del
server. Un attacco di tipo ip-spoofing potrebbe permettere ad un hacker di simulare l’IP del
server, magari dopo averlo messo fuori gioco con un attacco DoS, e sfruttare così l’accesso alla
rete locale, ma il pc del producer non è mai stato configurato per accedere alla NAS aziendale (la
rete interna con i suoi archivi contenenti i dati importanti). Non disponendo dell’autorizzazione
ad accedere a tale sistema, il computer su cui si trova il producer non rappresentava un punto di
accesso al cuore della rete ASCO TLC. Malgrado ciò, il primo giorno in cui il server è stato
proiettato nel web con indirizzo pubblico, è stato soggetto a numerosi attacchi. Così, nonostante
34
il monitoring costante e le misure di sicurezza adottate dai tecnici, questi mi hanno consigliato,
per prudenza, di scollegare fisicamente il server dalla rete la sera prima di lasciare la postazione.
Nello schema in figura 6.4.1 è rappresentata la rete in questione:
Figura 6.4.1
35
Una volta reso operativo il server di streaming, ho iniziato a mettere mano al file di
configurazione per imparare ad usare alcune delle caratteristiche che rendono questo prodotto
potente e lo rendono migliore, per esempio, del VLC.
Si può limitare il numero di connessioni e addirittura specificare degli indirizzi IP dai quali
accettare la connessione, ma questo genere di cose non mi interessava. Piuttosto, pensando alla
possibilità di fornire un servizio di videoconferenza ad eventuali futuri clienti, poteva essere utile
creare un mount point per ogni cliente ed assegnargli una password personale. Quando viene
inviato uno stream live al server senza specificare un mount point, il file viene memorizzato
nella cartella “Archive”, sottocartella di “Content” (dove sono archiviati i file per la trasmissione
su richiesta). User name e password che si forniscono nell’autenticazione al momento della
connessione tra producer e server possono benissimo essere anche quelle dell’amministratore.
Come vedremo nel capitolo successivo però, tali dati non vengono criptati e far viaggiare sulla
rete la password dell’amministratore in chiaro non è buona cosa.
Creare un mount point significa, in pratica, creare una nuova cartella all’interno di “Archive”. Si
supponga di creare il mount point “federico”. Questo significa che all’interno della cartella
“Archive” troverò una cartella denominata “federico”. Devo anche impostare una password,
diciamo “mia_password”. Questi dati vengono scritti in un database dedicato agli account per la
ricezione degli stream live, chiamato “SecureRBSEncoder”.
Si faccia finta che io sia il presidente di un’azienda e che mi trovi all’estero. Ho bisogno di
comunicare delle notizie al personale. Imposto il producer con l’indirizzo del server, user name e
password e chiamo il file “presidente.rm”. Posso così far iniziare uno streaming live che va a
scrivere il file “presidente.rm” nella cartella “Content/Archive/federico/”. I miei impiegati
potranno vedermi e sentirmi semplicemente aprendo con Real Player l’URL rtsp://<nome
server>/broadcast/federico/presidente.rm. I miei dipendenti, dal canto loro, potrebbero fare
altrettanto, solo chiamando il file “dipendenti.rm”. A questo punto avrei due file nella cartella
“Content/Archive/federico/”: “presidente.rm” e “dipendenti.rm”. Se io aprissi l’URL
rtsp://<nome server>/broadcast/federico/dipendenti.rm vedrei e sentirei le voci dei miei
dipendenti nella sala riunioni e potremmo instaurare una comunicazione vera e propria.
Naturalmente si potrebbe creare una conferenza con più di due partecipanti, ma portebbe essere
difficile per un computer, a causa dei limiti della banda, gestire molti stream in entrata
mantenendo una buona qualità delle immagini e del suono. Questo è il presupposto dal quale
sono partito per creare il client personalizzato per un futuro cliente dell’azienda, al quale avrebbe
potuto interessare anche il sistema di videoconferenza. Nel paragrafo successivo descriverò nel
dettaglio quanto ho fatto.
36
Le potenzialità del server non sono finite qui. Ci sono, infatti, molte altre opportunità di
migliorare il servizio, per esempio impostando una password anche per poter vedere uno stream
o altre ancora (si veda il capitolo sui dettagli tecnici).
6.5: CREAZIONE DEI CLIENT PERSONALIZZATI
6.5.1: CLIENT PER UN FUTURO CLIENTE
Esamino ora la realizzazione del client per un possibile futuro cliente. L’idea era quella di
inserire in una pagina web quattro videate da sfruttare per una videoconferenza. Non ne avrei
messe di più per evitare, oltre al problema della disponibilità di banda, anche la confusione che
potrebbe sorgere dalla sovrapposizione dell’audio dei partecipanti. Per permettere a più di
quattro utenti di partecipare attivamente alla conferenza, ho pensato di affiancare alle schermate
una chat, in modo che si potesse interagire con brevi messaggi di testo mentre si assiste agli
interveti dei principali membri del team dirigenziale.
Nella figura 6.5.1.1 si può vedere come appare il client.
Figura 6.5.1.1
37
In alto il logo della società, che in questo caso è la ditta “Tata”, con la quale abbiamo effettuato
dei test di cui parlerò nel capitolo 9. A sinistra le quattro schermate e a destra la chat, inserita
sfruttando il codice fornito da www.chatexpert.it. Sotto le videate ho inserito i controlli del
volume e per silenziare l’audio.
Descrivo nel dettaglio il codice scritto per generare il player a quattro videate.
Prima di tutto ho creato il player con SMIL.
<smil xmlns="http://www.w3.org/2001/SMIL20/Language" >
<head>
<layout>
<root-layout backgroundColor="black" width="800" height="600" />
<region id="im1" left="0" top="0" right="400" bottom="300" fit="fill"/>
</layout>
</head>
<body>
<par>
<video src="real9video.rm" region="im1" />
</par>
</body>
</smil>
Nel tag “layout” creo le quattro videate. Con il “root-layout” definisco dimensioni e sfondo dello
spazio dedicato al player multiplo. Quindi uso “region” per impostare nome, posizione e
dimensione delle singole schermate, indicando con l’attributo “fill” di adattare l’immagine alle
dimensioni della regione. Con il tag “par” faccio partire contemporaneamente (in parallelo
appunto) le quattro presentazioni. Con questo codice fanno partire un semplice filmato
dimostrativo in locale, ma ho testato personalmente il client usando, come sorgente, un filmato
presente nel server. Dunque è possibile specificare quattro percorsi differenti per poter vedere
38
quattro diverse presentazioni, che potrebbero essere le immagini di quattro dirigenti in
videoconferenza, ognuno in un angolo diverso del globo.
Per inserire questa presentazione SMIL in una pagina web, è necessario creare prima un file con
estensione “rpm”, con questa semplice riga di testo all’interno:
file://videate3.smil
dove “videate3.smil” è la nostra presentazione, il cui codice ho descritto sopra.
Ora uso il tag “embed” per inserire il file “videate3.rpm” nella nostra pagina web. Questa
operazione permette di visualizzare la presentazione specificata dal file “videate3.rpm” nella
web page.
<EMBED SRC="videate3.rpm" CONSOLE=video1 WIDTH=533 HEIGHT=400
CONTROLS=ImageWindow AUTOSTART=true >
Specifico le dimensioni della presentazione, le parti del player da inserire (in questo caso
soltanto la finestra delle immagini, senza la barra dei controlli) e l’opzione che fa partire la
presentazione appena viene aperta la pagina (AUTOSTART=true).
Per inserire lo slider del volume ho usato il seguente codice:
CONTROLS=VolumeSlider>
Si noti il valore “VolumeSlider” per l’attributo “CONTROLS” che indica che sto inserendo il
controllo del volume.
Analogamente, per il pulsante del muto, uso lo stesso codice, solo con “MuteCtrl” al posto di
“VolumeSlider”.
CONTROLS=MuteCtrl>
Per la chat invece ho inserito questo codice, fornitomi dal sito web di Chat Expert. Ho soltanto
messo mani alle dimensioni per aggiustare il layout della pagina. Il resto consiste in parametri di
39
configurazione scelti da me durante la procedura guidata che ha portato alla generazione del
codice e alcuni parametri necessari al funzionamento del servizio, come l’URL dell’applet e
delle pagine ASP.

<applet code="Showclient.class" width="450" height="400"
codebase="http://server80.chatexpert.it/client_asp/">
<param NAME="fore_red" VALUE="">
<param NAME="fore_green" VALUE="">
<param NAME="fore_blue" VALUE="">
<param NAME="back_red" VALUE="">
<param NAME="back_green" VALUE="">
<param NAME="back_blue" VALUE="">
<param NAME="TITOLO" VALUE="Tata">
<param NAME="FONT" VALUE="Tahoma">
<param NAME="DIMENSIONE" VALUE="50">
<param NAME="HOMEPAGE" VALUE="http://www.tata.it">
<param NAME="REGISTRAZIONE" VALUE="/admin/condizioni.asp">
<param NAME="DESCRIZIONE" VALUE="Servizio gestito da ChateXpert - Idea e
sviluppo Alessandro La Ciura - alex at chatexpert.it">
<param NAME="cabbase" VALUE="client.cab">
<param NAME="sfondo" VALUE="no">
<param NAME="porta" VALUE="8191">
<param NAME="reg" value="false">
<param NAME="stanze" VALUE="Conferenza;">
<param NAME="valid" VALUE="false">
<param name="link" value="true">
<param NAME="privati" value="true">
<param NAME="nickname" value="Inserisci il nick...">
<param NAME="congela" value="false">
<param NAME="banner_img" value="">
<param NAME="banner_link" value="">
<param NAME="banner_desc" value="">
40
</applet>

6.5.2: CLIENT PER ASCO TLC
Mi è stato chiesto di creare anche un client simile a queso per l’azienda stessa in cui ho svolto il
tirocinio. Era necessaria una pagina web dalla quale poter vedere in streaming eventi quali
convegni, fiere, conferenze, servizi televisivi e quant’altro potesse riguardare l’azienda. L’idea è
nata da un servizio dedicato all’azienda fatto da una TV locale, Antenna3, su un convegno
tenutosi a Montebelluna quest’estate. Abbiamo pensato di sfruttare l’occasione per codificare e
inserire nel server di streaming il video dell’evento e renderlo accessibile a tutti via internet.
Purtroppo il periodo di tirocinio è terminato proprio mentre attendevamo che ci fosse consegnato
il video dalla TV locale, tuttavia ho fatto in tempo ad approntare il client prima di lasciare
l’azienda.
Stavolta ho usato una struttura a frame: uno orizzontale in alto e due verticali sotto. In quello in
alto è sempre presente il logo della società, sul quale cliccare per tornare all’home page del sito.
A dire il vero, questa funzione non è stata ancora implementata ma non sarà difficile farlo al
momento dell’integrazione della pagina nel sito web. Sotto, a destra, troviamo un elenco dei
filmati disponibili. A sinistra invece, di default compare un breve suggerimento su come
interagire con la pagina. È sufficiente cliccare su uno dei link sulla destra per visualizzare il
relativo filmato. Nella figura 6.5.2.1 uno screenshot:
41
Figura 6.5.2.1
Se si clicca su una delle iconcine blu, si apre una pagina web nel frame di sinistra. La pagina che
viene aperta ha un player embedded che parte automaticamente al caricamento della pagina. Solo
che questa volta, a differenza del client descritto al paragrafo precedente, trattandosi di video ondemand ho permesso tutti i controlli del player con “CONTROLS=All”.
42
Figura 6.5.2.2
Nel caso in cui il filmato non sia ancora disponibile ma di prossima pubblicazione, si vedrebbe la
pagina in figura 6.5.2.3:
43
Figura 6.5.2.3
Il codice HTML per creare la pagina con i frame è il seguente:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>ASCO TLC TELEVISION</title>
</head>
<frameset rows="188,*" cols="*" framespacing="0" frameborder="NO" border="0">
<frame src="asco_top.htm" name="topFrame" scrolling="NO" noresize>
44
<frameset rows="*" cols="50%,50%" framespacing="0" frameborder="NO" border="0">
<frame src="instructions.htm" name="leftFrame" scrolling="auto">
<frame src="asco_right.htm" name="rightFrame" scrolling="auto">
</frameset>
</frameset>
<noframes><body>
<p>E' necessario avere un browser che supporta i frame per visualizzare correttamente questa
pagina.</p>
</body></noframes>
</html>
Con il tag “frameset” definisco la suddivisione in frame, in cui il primo frame occupa 188 righe,
mentre il secondo va dalla 189esima riga fino alla fine della pagina (indicato dall’asterisco).
Come estensione in larghezza occupa tutta la larghezza della finestra, ma senza dimensioni fisse
(ancora una volta l’asterisco sta a significare questo).
Il secondo frame lo divido in due frame usando un tag “frameset” annidato. Per la dimensione
dei due frame uso valori percentuali, così che i frame si adattino alle dimensioni della finestra.
Avendo impostato come valori cols="50%,50%" per le colonne, indico che ciascun frame si
“prende” metà dello spazio disponibile in larghezza. Per questi due frame ho impostato
l’attributo “scrolling” al valore “auto” in modo che la barra dello scrolling compaia solamente se
necessaria.
45
CAPITOLO 7
COMUNICAZIONE TRA:
HELIX PRODUCER BASIC 9 ED HELIX UNIVERSAL SERVER BASIC 9
Questa, in figura 7.1, è l’interfaccia dell’utility IPTraf di Linux che ho usato per monitorare il
traffico del server:
Figura 7.1
Nella metà superiore si ha un elenco delle connessioni TCP. Sulla sinistra è indicato l’indirizzo
IP e la porta sorgente con immediatamente sotto il rispettivo destinatario, collegati da una
parentesi quadra azzurra. Sulla destra invece vi sono dati relativi allo stato della connessione
quali numero pacchetti inviati, numero di Byte inviati, flags, interfaccia. Ciascun flag è un bit
che può venir posto a 1 a seconda dello stato della connessione. I flag del protocollo TCP sono i
seguenti:
•
F
FIN
Chiusura della connessione
•
S
SYN Sincronizzazione: richiesta di apertura della connessione
46
•
R
RST
Reset della connessione, quando viene rifiutata
•
P
PSH
Push, indica che sta trasferendo dati senza bufferizzare
•
A
ACK Acknowledgment, indica che il pacchetto a cui fa riferimento è arrivato a
destinazione
•
U
URG Indica che il pacchetto deve essere considerato urgente
•
E
ECE
•
W
CWR Finestra di congestione ridotta
Notifica di congestione
Si possono anche trovare combinazioni di flag. Per esempio: “PA” alla terza riga indica che
vengono inviati acknowledments inseriti all’interno di pacchetti di dati da spedire subito senza
bufferizzazione. Questa tecnica di inserire gli acknowledgment all’interno del prossimo frame in
uscita è detta “piggybacking”. Un ulteriore esempio si ha nella seconda fase dell’handshake a tre
vie: viene inviato un pacchetto con flag “SYN+ACK” ossia un acknowledgment, riferito alla
richiesta di connessione del client effettuata tramite il precedente pacchetto con flag SYN,
allegato alla richiesta di connessione inviata a sua volta dal server in conseguenza della richiesta
del client.
Nella metà inferiore invece vi è un elenco dei pacchetti UDP che passano per l’interfaccia eth0.
La struttura è semplice: mostra rispettivamente il protocollo, la dimensione del pacchetto,
mittente, destinatario, interfaccia.
Quando avevo problemi a far giungere lo stream live al server, non venivano segnalati pacchetti
UDP in arrivo dal Producer. Dopo che sono riuscito a farlo funzionare invece, scorrevano a
video una grande quantità di pacchetti provenienti dal Producer.
Sul pc del Producer invece, che monta Windows XP come sistema operativo, ho usato Ethereal
per monitorare il traffico. Ecco la prima schermata che ho ottenuto (figura 7.2):
47
Figura 7.2
Le prime tre righe rappresentano l’handshake a tre vie. Si noti infatti che il primo pacchetto parte
dal pc del Producer (192.168.1.54) con flag SYN per richiedere la connessione. Il server
(194.20.142.173) risponde con un ACK al pacchetto di sincronizzazione (flag SYN, ACK) e il
pc del Producer risponde con un acknowledgment all’ACK del server che completa così
l’handshake. Ora la connessione è stabilita.
Il quarto frame, quello evidenziato in blu nella parte superiore della schermata, è mandato al
server dal Producer inviando i dati necessari all’autenticazione. Il Producer infatti deve
autenticarsi al server con user name e password prima di potergli trasmettere dati poiché è stato
scelto “Push, Account-Based Login” come metodo di Broadcast. La riga blu nella seconda parte
della finestra indica proprio i dati delle credenziali, sotto forma di <user name>:<password>. Si
può notare la password anche nella terza parte della finestra, dove sono mostrati i dati “crudi”
che trasporta il pacchetto. Mi ha lasciato perplesso il fatto che le credenziali, soprattutto la
48
password, non vengano crittografate. In questo modo, infatti, chiunque potrebbe intercettare il
traffico esattamente come ho fatto io ed impossessarsi dei dati necessari all’autenticazione. Se
poi le credenziali intercettate dovessero essere quelle dell’amministratore, il danno sarebbe
ancora più grave.
Ad autenticazione avvenuta il server risponde con un pacchetto che, come si può vedere nella
seconda parte della schermata 7.3, contiene nell’ordine: l’indirizzo IP con cui il pc del Producer
si interfaccia verso la rete internet, il range di porte usato, il protocollo per la trasmissione dei
dati, il nome del file su cui scrivere e, infine, con il valore 1 dell’ultima variabile indica che, in
caso alcuni pacchetti vadano persi o danneggiati, verranno accettate richieste di ritrasmissione.
Figura 7.3
In figura 7.4 ho evidenziato il pacchetto che ho menzionato al paragrafo 6.4, quello che sembra
indicare la mancata ricezione dei dati da parte del server. Inizialmente credevo che la voce
49
“TotalPackets=0” indicasse la mancata ricezione dei pacchetti inviati dal Producer, mentre ho
scoperto che questi pacchetti arrivano anche dopo. Ho dunque ipotizzato che questi frame
segnalassero, con il campo “TotalPackets”, il totale di pacchetti arrivati con errori dal momento
che i parametri successivi indicano il numero di pacchetti persi, il numero di ritrasmissioni, il
numero di pacchetti FEC (Forward Error Correction) ricevuti e richiesti.
Quando il producer non riusciva ad inviare i dati al server, nella situazione descritta al paragrafo
6.4, al server non arrivavano pacchetti UDP del producer. Su 0 pacchetti arrivati, ovviamente, ce
ne saranno 0 corrotti. Ecco spiegato dunque il perché della presenza di questo pacchetto,
nonostante l’assenza del flusso di dati in entrata nel server.
Figura 7.4
Questo è ciò che avviene nel caso in cui Producer e server comunichino tramite il protocollo
UDP. Se usassero il TCP invece, si vedrebbe una schermata come quella nella figura 7.5:
50
Figura 7.5
Come si può notare dalla figura 7.5, il pacchetto HTTP di configurazione inviato dal server
indica che il protocollo stavolta è, ovviamente, il TCP, mentre le richieste di re-invio dei
pacchetti sono disabilitate essendo questa una funzionalità già implementata nel protocollo usato.
Subito dopo l’ok del server, viene effettuato un ulteriore handshake a tre vie per stabilire una
connessione stavolta con la porta 50033, alla quale dovranno essere spediti i dati. Terminato
l’handshake, inizia lo scambio di dati tramite lo scambio di pacchetti e dei relativi
acknowledgment.
51
CAPITOLO 8
COMUNICAZIONE TRA:
REAL PLAYER 9 ED HELIX UNIVERSAL SERVER BASIC 9
Ecco ora cosa succede quando il client, in questo caso Real Player, si collega per ottenere il
servizio di streaming.
Figura 8.1
Dopo il solito handshake a tre vie (si vedano i pacchetti 791, 792 e 793, figura 8.1), inizia la
comunicazione secondo il protocollo RTSP. La prima cosa che fa il client è mandare il comando
“OPTION”. Questo comando ottiene, come risultato, una lista dei comandi RTSP supportati.
Nella figura 8.2 la risposta del server:
52
Figura 8.2
Come si può notare nella seconda parte della finestra in figura 8.2, alla quart’ultima riga, dopo
“Public:” segue la lista di comandi RTSP. Tali comandi sono:
•
OPTIONS: come detto sopra, fornisce una lista dei comandi RTSP supportati.
•
DESCRIBE: torna la descrizione tramite SDP. SDP è un protocollo che descrive le
sessioni multimediali (sessione: connessione logica che deve essere instaurata tra due
unità indirizzabili perchè possano scambiarsi dati). In questo caso fornisce informazioni
quali l’URL del media, il tipo di file e la dimensione.
•
ANNOUNCE: annuncia un evento che riguarda la sessione multimediale, come per
esempio la fine dello stream. Può essere eseguito sia dal server sia dal client.
•
PLAY: fa partire/ripartire il flusso di dati verso il client. Contiene anche il numero di
sequenza che avrà il prossimo pacchetto RTP.
53
•
SETUP: configura il metodo di trasporto dei dati. Le varianti supportate sono:
o RTP/AVP;unicast;client_port=port1-port2
o RTP/AVP;multicast;client_port=port1-port2
o RTP/AVP/TCP;unicast
(AVP = Audio Video Profile)
I parametri di trasporto dello stream devono essere settati soltanto con questo
comando, non con SET_PARAMETER.
•
GET_PARAMETER: richiesta per ottenere dal server il valore di un parametro di
configurazione.
•
SET_PARAMETER: richiesta di modificare il valore di un parametro. L’ideale sarebbe
passare un parametro alla volta a questa funzione in modo da poter capire in caso di
fallimento dove si sia verificato l’errore.
•
TEARDOWN: pone fine alla consegna di dati da parte del server.
Lo schema seguente, tratto dall’RFC2326, riassume i comandi disponibili. In “direction” la
direzione della comunicazione (C = client, S = server). In “object” l’oggetto su cui i comandi
operano (P = presentation, S = stream). In “requirement” indica se il comando è richiesto o può
essere tralasciato.
method
direction
object
requirement
DESCRIBE
C->S
P,S
recommended
ANNOUNCE
C->S, S->C
P,S
optional
GET_PARAMETER
C->S, S->C
P,S
optional
OPTIONS
C->S, S->C
P,S
required
(S->C: optional)
PAUSE
C->S
P,S
recommended
PLAY
C->S
P,S
required
RECORD
C->S
P,S
optional
REDIRECT
S->C
P,S
optional
SETUP
C->S
S
required
SET_PARAMETER
C->S, S->C
P,S
optional
TEARDOWN
C->S
P,S
required
54
Il passo successivo è una richiesta di descrizione della sezione tramite il comando DESCRIBE:
Figura 8.3
Si può notare, all’interno del pacchetto in figura 8.3, informazioni quali l’URL del file
multimediale, il player multimediale e vari dati che riguardano la sessione come la larghezza di
banda, client ID, lingua, etc. Il server risponde con un OK e una serie di attributi che riguardano
la sessione e l’elemento multimediale da trasmettere. Questo pacchetto è mostrato nella figura
8.4:
55
Figura 8.4
In seguito viene inviata una richiesta di SETUP:
56
Figura 8.5
Come si vede dalla quint’ultima riga in figura 8.5, alla voce “Transport:”, la modalità di
trasmissione impostata è RTP/AVP/TCP;unicast;mode=play. Oltre a questo, ci sono anche altre
informazioni che riguardano la sessione, le stesse che sono già state incontrate nei precedenti
pacchetti; dunque, null’altro di rilevante.
Ora viene fatta una richiesta di SET_PARAMETER dal client (figura 8.6) il quale indica al
server, tramite il comando “Subscribe”, quali sono le regole da seguire durante la
comunicazione. Tali regole, contenute nel “rule book” ASM (Adaptive Stream Management),
descrivono al server i tipi di dato trasmessi e lo aiutano a prendere decisioni intelligenti su come
consegnare pacchetti in modo efficiente e sicuro. Tali regole si basano sulle condizioni della
rete: il client analizza lo stato della rete (basandosi su parametri quali larghezza di banda,
57
pacchetti persi, priorità, etc.) e sottoscrive la regola che meglio si adatta. Se le condizioni
cambiano, il client sottoscrive una nuova regola.
Figura 8.6
Il passo successivo è il comando PLAY (figura 8.7). Subito sotto la riga evidenziata, che riporta
il nome del comando, vengono indicati: il nome dello stream (URL), il numero di sequenza che
verrà usato dal prossimo pacchetto RTP (CSeq), dati relativi al client (User-Agent), dati relativi
alla sessione multimediale in corso (Session) ed infine l’intervallo temporale di durata dello
stream (Range). Trattandosi di uno stream live, quest’ultimo parametro sarà settato con tempo di
inizio “0” (ossia istantaneamente), mentre lo stop time non verrà specificato, lasciando un
trattino “-” ad indicare l’indeterminatezza dell’istante di fine del flusso di dati.
58
Figura 8.7
Il frame che segue quello appena descritto (si veda sempre la figura 8.7) porta l’”OK” del server.
Da questo momento inizia il flusso di dati tra server e client, lo streaming vero e proprio. Mostro
ora nel dettaglio come avviene questo scambio di dati.
Il server, per evitare di incorrere in problemi con i firewall o per altre circostanze dovute alla
rete, incapsula i pacchetti RTSP in pacchetti TCP. Questa tecnica viene usata anche dal server da
me installato. Osservando l’immagine 8.8 infatti, si può vedere che il client riceve pacchetti TCP
con l’etichetta “Interleaved” che sta ad indicare appunto l’incapsulamento di un protocollo nel
TCP. Nella seconda parte della finestra di Ethereal, dove si trova la descrizione del pacchetto,
sono indicati due frame RTSP. A volte se ne trovano due insieme, a volte uno soltanto. L’inizio
del frame RTSP è indicato dal campo Magic che ha il valore esadecimale 24, corrispondente al
simbolo del dollaro in ASCII (come si vede anche dalla rappresentazione cruda dei dati nella
59
terza parte della finestra). Dal documento RFC 2326 (Request for Comments, documenti ufficiali
numerati che descrivono vari aspetti tecnici di Internet), apprendo inoltre che anche i pacchetti
RTCP possono essere incapsulati nel tunnel TCP dal server per la sincronizzazione del traffico
RTP.
Figura 8.8
Oltre a questi frame se ne vedono altri, che viaggiano sempre dal server al client, di tipo RTPS
con etichetta “Continuation” (con riferimento alla figura 8.9).
60
Figura 8.9
61
CAPITOLO 9
TEST, RISULTATI, CONFRONTI
9.1: TEST IN LOCALE
Quando il server era pronto per inviare stream live sulla rete, ho fatto alcuni test per verificare il
ritardo dovuto alla trasmissione delle immagini via cavo. Cavo inteso come cavo di rete classe 5,
100BaseTX.
Già osservando le due schermate del producer si poteva notare un leggerissimo ritardo
nell’immagine di destra, dovuto al tempo richiesto per la codifica delle immagini. Si trattava
comunque di una frazione di secondo. Decisamente più consistente era invece il ritardo che si
notava aprendo il Real Player nello stesso schermo ed affiancando le tre immagini. Il tempo di
latenza variava tra i 5 e i 6 secondi con picchi di 10-11 secondi, molto probabilmente a causa
della congestione della rete. Il ritardo medio era comunque intorno ai 6 secondi.
9.2:TEST CON CLIENTE
Abbiamo chiesto ad un cliente da Vicenza, dotato di una connessione ADSL a 1.2 Mbps, di
collegarsi al server Helix per una prova. Non ha avuto difficoltà nel visualizzare lo stream, anzi,
la qualità era ottima (il broadcast aveva un bitrate di 450 Kbps). Abbiamo effettuato un test per
studiare il ritardo: da Vicenza veniva inviato un messaggio istantaneo via chat che leggevo ad
alta voce appena veniva visualizzato sul mio monitor. Inizialmente il ritardo misurava addirittura
15 secondi ma poi mi è venuto in mente che la chat poteva introdurre un ulteriore ritardo dovuto
alla consegna del messaggio. Così abbiamo ideato un metodo empirico per misurarlo: dall’altro
capo della comunicazione mi veniva inviato un messaggio consistente in una cifra. Io, appena
ricevevo il messaggio, leggevo la cifra ad alta voce e, contemporaneamente, rispondevo con un
messaggio identico (ossia la stessa cifra). Il tempo necessario per rispondere al messaggio,
trattandosi di inviare un solo carattere, era di un secondo. Al ritardo doveva quindi essere
sottratta la metà del tempo necessario al messaggio per tornare al mittente. Il ritardo, così
misurato, si abbassava fino a 11-12 secondi circa.
62
9.3: TEST CON ADSL PRIVATA
Ho condotto un test anche connettendo un pc con Real Player al server pubblico. Anche in
questo caso l’ADSL usata aveva una larghezza di banda pari a 1.2 Mbps e, come enl caso
precedente, il broadcasting funzionava a 450 Kbps mostrando audio e video di ottima qualità.
Test ripetuti, come quello descritto sopra, hanno confermato una stima di 10 secondi circa di
ritardo.
9.4: DIMOSTRAZIONE CON UN POTENZIALE CLIENTE
Ho chiamato un potenziale cliente (la ditta “Tata”) per fargli una dimostrazione chiedendogli di
collegarsi dalla loro sede. Anche loro, come i clienti di Vicenza, erano collegati con l’ADSL ,
solo con una larghezza di banda quasi doppia (2 Mbps). Nonostante l’alta velocità del loro
collegamento, ricevevano lo stream ad un rate di appena 16 Kbps con una qualità audio e video
assai scadente. Il giorno dopo ho riprovato facendoli collegare la mattina presto, prima che gli
impiegati arrivassero ed accendessero i loro computer. Temevo che il problema fosse dovuto alla
congestione della loro rete, ma nemmeno stavolta riuscivano a vedere nulla, sebbene il log del
server mi desse la conferma del collegamento. Vista la capacità della loro connessione non
potevano ricevere dati più lentamente di un modem 56K. Così ho fatto fare loro un test che
misura la banda di cui dispongono: basta digitare su Google “bandwidth” o “speedometer” o
simili per trovare un qualunque software per la misurazione della velocità di connessione. Sono
strumenti poco affidabili in quanto di scarsa precisione, ma utili per avere una stima
approssimativa. Dopo che il test era stato condotto ripetute volte, ho notato con grande sorpresa
che i risultati erano sempre eccellenti. A questo punto ho supposto che la causa della disfunzione
fosse il loro firewall che ostacolava il traffico. Purtroppo, a causa dell’avvento delle vacanze
estive e della fine del periodo di tirocinio, non ho potuto verificare la mia ipotesi. Resto tuttavia
convinto, visti anche i risultati degli altri test, che il problema risiedeva nella loro rete e non nella
nostra.
63
9.5: CONCLUSIONI SULL’ESITO DEI TEST
Cosa ricavare dai test sopra descritti? Il ritardo può sembrare consistente, ma per una
comunicazione live di ottima qualità è il prezzo da pagare. Con uno stream a 450 Kbps le
immagini sono molto nitide e l’audio piacevolmente chiaro e comprensibile. Sarebbe stato
interessante studiare i ritardi anche con altri rate ma, per motivi di tempo, non è stato possibile
condurre un’indagine accurata in questo frangente. Tuttavia prevedo un abbassamento dei ritardi
proporzionale alla diminuzione del rate di trasmissione. L’abbassamento dei ritardi non dovrebbe
essere lineare poiché il ritardo introdotto dalla rete è impossibile da eliminare ed è quello che
incide in maniera maggiore (basti ricordare che si passa dai 5-6 secondi misurati con la LAN ai
10-12 secondi rilevati con i test dall’esterno).
64
CONCLUSIONI
In questa interessante esperienza ho approntato un server in grado di trasmettere file
multimediali sulla rete globale, accessibili a tutti da qualunque angolo del pianeta dotato di un
collegamento ad internet. Ho approntato un sistema in grado di convertire qualunque formato di
file multimediale di tipo audio/video in breve tempo e trasmetterlo al server, pronto per essere
visualizzato su richiesta. Ho costruito le basi per un sistema di videoconferenza sfruttando le
potenzialità di codifica di Helix Producer Basic 9 e le capacità del server Helix Universal Server
Basic 9, che in ambiente Linux dà il meglio di se riuscendo a gestire anche migliaia di
connessioni, come dimostrato dal test della KeyLabs. Il tutto arricchito da client embedded che
permettono di avere una vera e propria TV digitale sul monitor del proprio computer
semplicemente installando un player gratuito da pochi megabyte (sto parlando ovviamente di
Real Player).
Il tirocinio mi ha permesso di incrementare la mia conoscenza e manualità con il sistema
operativo Linux, mi ha permesso di apprendere molte conoscenze di tipo tecnico sia sulle reti di
calcolatori che sui software utilizzati. Mi ha dato modo di applicare ciò che ho imparato in questi
tre anni di università con un processo di trasformazione delle mie conoscenze teoriche in un
prodotto tangibile e, soprattutto, funzionante.
Lo streaming è un argomento affascinante che ho studiato con molto interesse, contribuendo ad
alimentare la mia passione per l’informatica ed in particolare per le tecnologie nel campo delle
reti di calcolatori e della programmazione. Questa esperienza extra-scolastica è stata un ottimo
banco di prova che mi ha permesso di conoscere meglio il mondo del lavoro, procurandomi
altresì l’occasione di mettermi in mostra nel campo lavorativo.
65
GLOSSARIO
SIMBOLI / ACRONIMI
•
LRU: Least Recently Used
•
DNS: Domain Name System. È un database distribuito che esegue la trasformazione tra
nomi simbolici (nomi a dominio) e indirizzi IP numerici dei computer.
•
RDP: RealNetworks Data Transport, usato per lo streaming di Real Media su RTSP
•
RTP (Real Time transfer Protocol)
Supporta il trasferimento real-time dei dati. Tipicamente si appoggia sul protocollo UDP
(User Datagram Protocol) un protocollo non orientato alla connessione di livello 4
(ISO/OSI).
È composto dalla parte di trasporto dati, RTP e la parte di monitoraggio RTCP (Real
Time Control Protocol). Mediante il protocollo RTCP l’applicazione viene informata
sulle statistiche della comunicazione, come la percentuale di pacchetti persi, il jitter, ed i
pacchetti ai quali le informazioni date si riferiscono.
Il protocollo RTP è descritto in [RFC1889].
•
RTSP (Real Time Streaming Protocol)
È un protocollo di controllo che si basa su TCP per comunicare e permette all’utente di
richiedere dei flussi (streams) a uno o più server, richiedere uno specifico tipo di
trasporto e destinazione dei dati, richiedere informazioni sui dati, iniziare, fermare,
sospendere l’erogazione dei dati, accedere in maniera random a varie porzioni dei dati
(un po’ come il telecomando di un videoregistratore).
Il protocollo RTSP è descritto in [RFC2326].
•
RFC (Request For Comments): documento molto utilizzato in ambiente Internet per
promulgare standard ufficiali, diffondere informazioni di ricerca, inchieste, osservazioni
e idee. Viene utilizzato anche per proporre nuove specifiche per le quali, appunto, si
richiedono commenti e giudizi. Una volta che il processo di discussione è terminato
l’RFC diventa il testo finale dello standard concordato. Tutte le RFC sono disponibili
66
presso il Network Information Center gestito dal Dipartimento della Difesa
ftp://nic.ddn.mil e presso i singoli NIC continentali tra cui ftp://ftp.rs.internic.net,
ftp://ftp.ripe.net, ftp://erasmus.terena.nl, ftp://ftp.nis.garr.it
•
DoS (Denial of Service): tipo di attacco a sistemi di computer e reti che ha lo scopo di
impedire l’accesso alle informazioni o di interrompere l’utilizzo dei sistemi. Gli attacchi
di tipo denial of service spesso intasano le reti con un tale traffico che gli utenti
autorizzati non sono più in grado di utilizzarle, oppure rallentano la velocità delle reti al
punto di rendere praticamente impossibili le trasmissioni autorizzate.
67
BIBLIOGRAFIA
•
http://service.real.com/help/library/guides/helixuniversalserver/realsrvr.htm
•
http://service.real.com/help/library/guides/helixproducer/Producer.htm
•
http://www.helixcommunity.org
•
http://www.realnetworks.com
•
http://www.axis.com/techsup/cam_servers/dev/cam_rtsp_api.htm
•
http://www.beta.it
•
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-announce01.txt
•
http://www.faqs.org/rfcs/rfc2326.html
•
http://www.cs.columbia.edu/~hgs/rtp/
•
http://www.qilinux.it
•
http://www.videolan.org/vlc/
•
http://www.chatexpert.it/
•
http://www.yle.fi/mikaeli/info/tutkimukset/wang/
68

televisione digitale soluzione di streaming per internet a banda larga

Transcript

Documenti analoghi

Sposarsi Con Rito Civile - Sito ufficiale del Comune di Sestri Levante

Corso di Applicazioni Telematiche

the pdf

The Sims 3 Vita Universitaria

Streaming

versione pdf

La Videoevoluzione sul WWR

World Wide Web

PowerTerm® WebConnect Server