Sviluppo di un plugin per Internet Explorer per la riproduzione di contenuti multimediali visitati

Il progetto prevedeva l'estensione di tale applicazione già sviluppata per il browser 
Mozilla Firefox per il prodotto Microsoft. In realtà più che un'estensione si trattava di 
un vero e proprio progetto a parte in quanto non era in alcun modo possibile utilizzare il 
software  sviluppato  per  Firefox  per  questa  nuova  applicazione.  Le  due  architetture 
erano e  sono completamente  differenti  e  per  il  loro sviluppo si  utilizzano per  altro 
linguaggi di programmazione diversi.
Partendo  quindi  da  una  base  pressochè  teorica  e  totalmente  sconosciuta  (ma 
soprattutto ostica come vedremo in seguito) il nostro progetto prevedeva l'esplorazione 
di  tale  nuovo  ambiente,  andando  a  contribuire  allo  sviluppo  di  plugin  per  Internet 
Explorer,  che così  scarsamente  come numero sono presenti  nel  nostro panorama di 
oggi.
Realizzato interamente in c++ nell'ambiente Microsft Visual Studio, il progetto si è 
sviluppato analizzando e cercando di capire per prima cosa la complessa architettura del 
browser e di Microsoft (per quanto riguarda però la gestione di Internet Explorer). Solo 
dopo tale attenta analisi che ha per altro richiesto diverso tempo si è potuto iniziare con 
la realizzazione attraverso piccoli step.
Il  progetto sfrutta uno sniffing esterno che lavora ad un basso livello della pila 
protocollare in  modo da rimanere  indipendente dall'applicazione tenendo traccia dei 
contenuti visitati.
Sfruttando  tale  componente  il  plugin  presenta  a  video  i  contenuti  catturati 
consentendo all'utente di riprodurli in un successivo momento e fornisce una serie di 
servizi aggiuntivi quali ad esempio un semplice notepad per appunti rapidi.
Il nostro progetto rappresenta di certo un primo passo verso quello che potrebbe in 
futuro  essere  un  plugin  più  completo  che  integri  al  suo  interno  lo  sniffing  stesso 
consentendo così di fornire all'utente un servizio completo e di certo innovativo per 
quanto  riguarda il  browser Micrsoft,  al  giorno d'oggi  ancora  il  più  diffuso e  il  più 
utilizzato fra tutti.
La tesi presenterà quindi una prima analisi della parte di sniffing al quale si collega 
il plugin sviluppato nel primo capitolo, analizzerà brevemente la storia del browser e le 
differenze fra i due principali e più diffusi (secondo capitolo) per poi passare al progetto 
vero e proprio, prima con un'analisi astratta (capitolo 3) poi analizzando l'architettura 
(capitolo 4) ed infine concentrandosi sui dettagli tecnici (capitolo 5).
8
                        Capitolo 2
Background – Lo Sniffing
Il plugin sviluppato, “Multimedia Web Recorder” sfrutta le potenzialità di uno sniffing 
che lavora ad un basso livello protocollare.  Per analizzare a fondo lo sniffer però è bene 
trattare  diversi  argomenti  utili  a  capirne  il  funzionamento.  Dal  funzionamento  della 
trasmissione  di  streaming,  ai  protocolli  disponibili,  al  funzionamento  dell'attività  di 
sniffing, fino ad arrivare a che cos'è lo sniffer, alle librerie utilizzate per il suo sviluppo e 
alla sua realizzazione vera e propria.
INTRODUZIONE – La multimedialità -
Prima di analizzare il funzionamento dello sniffing è bene definire che cosa si intende 
con il termine multimedialità. Ma che cosa significa di preciso il termine Multimedialità? 
Le definizione specifica indica che è un termine usato per descrivere l'utilizzo simultaneo 
di  differenti  media  per  fornire  informazioni  all'utente.  Dal  momento  però  che  le 
informazioni sono presentate in vari formati digitali, multimedia intensifica l'esperienza 
dell'utente e rende più facile e veloce percepire informazioni (learning content). Ad oggi i 
più importanti tipi di media e i corrispondenti formati digitali sono:
– Web Based Text (formati PDF, DOC, XLS, HTML, XML, PPT)
– Web Based Graphics, drawings, photos (formati JPEG, BMP, GIF, VML, SVG)
– Audio, sound, music (formati MP3, Real Audio, WMA, AVI)
– Video, Films, Movies (formati AVI, MPEG, MOV, QT, RV, WMV)
– Animation  (formati  animated  GIF,  dynamic  HTML,  FLASH,  DIRECTOR 
SHOCKWAVE ecc.)
– Virtual Reality Worlds, 3D animation (Formato VRML)
– Software simulation and programming files (formati VB, C++, Java, PHP ecc.)
Il termine multimedialità deriva dal latino medium, “mezzo”, qui inteso come mezzo di 
comunicazione e indica il metodo per fornire informazioni mediante la combinazione di 
differenti tipi di dati: testi, grafici, suoni, immagini ecc.
Come lo spettatore interpreta questi dati dipende da come ha percepito le informazioni. La 
differenza più rilevante si ha mettendo a confronto televisione e computer. Mentre per la 
9
prima il messaggio è trasmesso a senso unico e l'utente non ha la possibilità di interagire,  
con il secondo l'utente ha la possibilità di essere coinvolto e di interagire.. Ha cioè ora il 
controllo sul flusso dei dati.
TRASMISSIONE IN STREAMING
Internet ha avuto una crescita miracolosa dalla sua apparizione. La navigazione Web e 
il trasferimento dei file sono i servizi dominanti forniti attraverso Internet. Tuttavia questi 
tipi di servizi che forniscono informazioni su testo immagini e scambio di documenti non 
soddisfano più la domanda degli utenti. Con i recenti progressi nelle tecnologie digitali, 
come  l'alta  velocità  delle  reti,  tecnologie  di  compressione  e  maggior  potenza  di 
elaborazione dei computer, sempre più applicazioni multimediali che coinvolgono audio e 
video digitali sono entrate a far parte di Internet.
Con il termine streaming si descrive la trasmissione di vari oggetti multimediali da un 
media server a più utenti via satellite, su reti a banda larga, tramite internet o su intranet 
aziendali. Con questa tecnologia il client è in grado di riprodurre i contenuti multimediali 
anche senza dover attendere il completo scaricamento del file. E' bene ricordare però che 
internet fornisce solo servizi best-effort e non da garanzie sulla qualità del servizio per la  
trasmissione di dati multimediali. 
STREAMING PROCESS
Uno streaming process può essere suddiviso in tre fasi che si sovrappongono nel tempo. 
Una prima fase di acquisizione dei dati, che è la fase che determina come il contenuto 
streaming è acquisito, pacchettizzato e distribuito per lo streming. Una seconda fase di 
trasporto dei dati rappresentata dal processo in cui lo stream di dati è trasportato dalla 
sorgente  alla  destionazione  ed  infine  una  terza  fase  di  presentazione  dei  dati  che 
rappresenta  il  modo  in  cui  i  dati  ricevuti  devono  essere  bufferizzati,  assemblati  e 
renderizzati. Vediamo ora in dettaglio le varie fasi:
    
 Acquisizione e presentazione dei dati
Alla sorgente dello streaming il contenuto è preparato per la distribuzione. Se i dati si 
riferiscono ad un evento video o audio già avvenuto e quindi già disponibile su file questo 
viene definito streaming on demand. Se invece i dati sono acquisiti  in real time viene 
definito live streming.  I contenuti per lo streaming on demand sono preregistrati e resi 
disponibili al nodo sorgente, in genere anche molto prima che la prima richiesta venga 
effettuata. 
10
Quando un utente richiede al server di inviargli dei contenuti audio/video non è necessario 
scaricarli  per  intero  sul  PC  per  poterli  riprodurre,  ma  essi  vengono  decompressi  e 
riprodotti pochi secondi dopo l'inizio della loro ricezione. Questo ritardo serve per creare 
una “scorta” per rimediare a ritardi o microinterruzioni della rete. 
I  contenuti  live sono molto simili  a  quelli  on demand a parte il  fatto che i  dati  sono 
generati da un dispositivo quale ad esempio la videocamera e la loro trasmissione avviene 
in modalità broadcast. 
 Compressione
Data l'elevata dimensione dei file multimediali grezzi che impongono requisiti di banda 
restrittivi, viene usata la compressione per raggiungere un'efficienza di trasmissione. Dal 
momento che il video ha requisiti di banda maggiore rispetto all'audio e che la perdita di  
qualità audio è più fastidiosa percettivamente rispetto al video, all'audio viene data una 
priorità maggiore nell'ambito di un sistema streaming multimediale. Quindi solo il video 
sarà  utilizzato  al  fine  di  soddisfare   i  requisiti  QoS,  quindi  ci  si  concentrerà  sulla  
compressione video.
Gli schemi di compressione video si dividono in due categorie , scalabili e non scalabili. 
Nel  primo,  flussi  di  rate  differenti  possono essere  estratti  da  un  unico  flusso quando 
richiesto. Un unico flusso può quindi  adattarsi alle esigenze di diversi client in una rete 
eterogenea. D'altra parte però il decoder non può essere in grado di decodificare tutti i dati  
ricevuti abbastanza velocemente per la ricostruzione. Pertanto l'obiettivo della codifica 
video per lo streaming multimediale è quello di ottimizzare la qualità video su un dato 
range  di  bit-rate.  Per  soddisfare  queste  esigenze  un  nuovo  meccanismo  di  codifica 
scalabile, chiamato Fine Granularity Scalability (FGS) è stato proposto nell'MPEG-4.
Figura 1- Fonte Istituto Nazionale di Fisica Nucleare - Gruppo Multimediale
Trasporto dei dati
I  protocolli  di  streaming  forniscono  i  mezzi  al  client  e  al  server  per  servizi  di 
negoziazione, trasmissione dei dati e indirizzamento nella rete. Quando viene ricevuta una 
11
richiesta di servizio, il server deciderà se questa deve essere accettata o meno in base alle  
informazioni ricevute dal gestore di servizio. Se la domanda viene accettata le risorse 
vengono assegnate. I contenuti multimediali recuperati dal dispositivo di archiviazione 
sono pacchettizzati  con informazioni  sul  media,  come ad esempio il  timestamp e poi 
consegnati  la  client.  Il  pacchetto  giunto  al  client  viene  decompresso  e  suddiviso  in 
contenuto multimediale e informazioni sul media. QoS monitor utilizza le informazioni 
per analizzare le condizioni della rete ed invia un feedback al controllore del QoS sul 
server per adattare i requisiti della qualità. Dall'altra parte il contenuto del media viene 
decodificato  e  passato all’applicazione per la  riproduzione.  Per offrire continuità alla 
visualizzazione, i pacchetti sono bufferizzati in modo che un certo numero di essi venga 
scaricato prima della riproduzione. Non appena questi pacchetti bufferizzati o precaricati 
sono eseguiti, altri vengono scaricati e messi in coda per essere eseguiti. Se la velocità con 
cui arrivano i dati non è sufficientemente elevata il player non ha nulla da riprodurre e si 
ottiene il  tipico drop-out.   Lo streaming server  cerca  di  compensare  questo problema 
mantenendo la connessione costante.  Audio e video possono essere trasmessi su flussi 
separati. Per ottenere la sincronizzazione tra i vari flussi, sono  necessari meccanismi di 
sincronizzazione.
Figura 2- Fonte Istituto Nazionale di Fisica Nucleare - Gruppo Multimediale
    
Sincronizzazione dei media
A causa dei  differenti  instradamenti  ed imprevedibili  ritardi  durante la  trasmissione,  i 
flussi  multimediali  possono  perdere  la  sincronizzazione.  Pertanto,  un  meccanismo  di 
sincronizzazione  dei  media  si  rende  necessario  per  mantenere  la  relazione  temporale 
12
originale  all’interno  di  un  flusso  multimediale  o  tra  vari  flussi  in  modo  tale  che  il 
contenuto  multimediale possa essere presentato in modo corretto. Ci sono tre livelli di 
sincronizzazione:  intra-stream,  inter-srteam  e  inter-object.  La  sincronizzazione  intra-
stream si occupa di mantenere la continuità del flusso stesso
in modo che ogni frame audio/video ricevuto venga riprodotto nell’istante previsto; in 
caso contrario la presentazione sarà interrotta da pause o pezzi mancanti. La 
sincronizzazione inter-stream mira a mantenere la relazione temporale tra i vari flussi 
multimediali di modo che frame audio siano riprodotti all’interno del corrispondente 
frame video così come erano stati registrati originariamente. La sincronizzazione 
interobject è utilizzata per sincronizzare i flussi multimediali con dati indipendenti dal 
tempo come testo e immagini fisse.
PROTOCOLLI DI STREAMING
Prima di intraprendere il discorso sulla fase di sniffing vera e propria è necessario fare 
una breve spiegazione per quanto riguarda i protocolli di streaming, per cercare di capire 
quali sono i protocolli più utilizzati di delivery di contenuti multimediali. 
La grande svolta che ha permesso la rivoluzione dello streaming è stata l’adozione di 
un  nuovo  protocollo  chiamato  User  Datagram  Protocol  (UDP)  e  nuove  tecniche  di 
codifica che comprimono file audio in pacchetti di dati estremamente piccoli. UDP rende 
lo  streaming  realizzabile  trasmettendo  i  dati  molto  più  efficientemente,  rispetto  ai 
protocolli  precedenti,  dal  server  al  player  del  client  o  all’utente  finale.  Protocolli  più 
recenti, come il Real Time Streaming Protocol (RTSP),
hanno reso la trasmissione dei dati ancora più efficiente.
UDP e  RTSP sono  ideali  per  la  trasmissione  in  quanto  attribuiscono  una  più  alta 
priorità al flusso continuo piuttosto che alla sicurezza del documento. A differenza delle 
trasmissioni TCP e http, quando un pacchetto viene perso, il server continua ad inviare 
informazioni, causando solo un breve glitch invece di un grosso vuoto di silenzio. TCP, 
d’altro canto, continua a cercare di inviare il pacchetto andato perso prima di inviarne di 
nuovi, causando ritardi maggiori e vuoti nella trasmissione.
Prima  della  trasmissione  UDP  e  RTSP,  i  dati  sono  inviati  attraverso  il  Web 
principalmente  via  TCP e  HTTP.  Tuttavia,  dal  momento  che  la  trasmissione  HTTP è 
basata  su  TCP,  non  è  adatta  per  la  trasmissione  di  presentazioni  multimediali  che  si 
basano su operazioni dipendenti dal tempo.
Alcune tecnologie di streaming come Real Audio e Windows Media utilizzano server 
dedicati che supportano la trasmissioni UDP e RTSP. Altri formati come Shockwave, 
13
Flash, MIDI e Quicktime sono progettati per fare streaming usando principalmente un 
server http standard. Mentre questi formati sono meno costosi e spesso più facili da usare, 
perché non richiedono l’installazione di un server, non sono tipicamente utilizzati in 
situazioni di trasmissione professionale che richiedono la diffusione di centinaia o 
migliaia di flussi simultanei.
HTTP Streaming
HTTP streaming è un meccanismo per l’invio dei dati da un server Web ad un browser 
in risposta ad un evento. Con questo tipo di protocollo, il Server Web non interrompe la 
risposta al client dopo che i dati sono stati inviati. Questo si differenzia dal tipico ciclo 
http in cui la risposta è chiusa subito dopo la trasmissione dei dati. Il server Web lascia 
aperta la risposta in modo tale che, se viene ricevuto un evento, possa essere inviato 
immediatamente al client. In caso contrario, i dati dovrebbero essere messi in coda fino 
alla prossima richiesta del client al server. Il protocollo HTTP utilizza in genere la porta 
80 o 8080.
Real Time Streaming Protocol - RTSP
Il Real Time Streaming Protocol (RTSP) è un protocollo di livello applicazione, che 
fornisce un framework estensibile utile per implementare il controllo del trasporto di dati 
multimediali isocroni.
Il  protocollo RTSP inizializza e controlla flussi singoli o multipli  di media continui 
sincronizzati nel tempo. Esso non trasporta i dati costituenti questi flussi. RTSP funziona 
come  “un  controllo  remoto  su  rete”  per  server  multimediali.  L’insieme  dei  flussi  da 
controllare sono specificati tramite una descrizione della presentazione. Il funzionamento 
di  RTSP non  dipende  dallo  specifico  meccanismo  di  trasporto  utilizzato  per  i  dati 
multimediali come una connessione su TCP. Durante una sessione RTSP, un client RTSP, 
per  trasmettere le  sue richieste,  può utilizzare una connessione diversa per  ognuna di 
esse.. RTSP è stato progettato in modo che fosse simile al protocollo HTTP/1.1 in sintassi 
ed operazioni, affinché fosse possibile aggiungere i meccanismi di estensione dell’HTTP 
anche all’RTSP. Però RTSP differisce dall’HTTP per molti aspetti importanti:
o RTSP introduce un certo numero di metodi nuovi e utilizza differenti identificatori 
di protocollo.
o Un server RTSP ha la necessità di mantenere delle informazioni di stato, al contrario 
di HTTP che è privo di un concetto di stato.
o Sia il client che il server RTSP possono inviare richieste.
14
o  L’URI (Universal  Resource Identifier)  delle  richieste  è  sempre assoluto.  Mentre 
l’HTTP/1.1 pone nelle richieste solo un percorso assoluto, e inserisce il nome dell’host in 
un campo intestazione separato.
Le richieste RTSP possono essere gestite dai proxy, tunnel e cache come avviene per 
l’HTTP/1.1.  Per  riferire  le  risorse  di  rete  sono utilizzati  gli  schemi  rtsp  ed  rtspu.  La 
sintassi per gli URL è:
rtsp_URL  =("rtsp:"|"rtspu:")"//"  host[":"port][abs_path] 
host = A legal Internet host domain name of IP address (in 
dotted decimal form, as defined by Section 2.1 of RFC 1123 
port = *DIGIT abs_path is defined in RFC 2068/Par.3.2.1
Lo schema rtsp richiede che i comandi vengano trasmessi su un protocollo affidabile 
(per Internet si usa il TCP), mentre lo schema rtspu identifica un protocollo non affidabile 
(per Internet si usa l’UDP).
Una presentazione o uno stream è identificato tramite una stringa di testo, che ha il 
formato di un URL. Questi URL possono riferirsi ad un singolo stream, oppure ad un 
aggregato  di  stream.  Un  esempio  di  URL  di  RTSP  è: 
rtsp://lis3.deis.unical.it:554/Lecture1/Video
In questo caso si identifica lo stream audio all’interno della presentazione “Lecture1”, 
che può essere controllata tramite richieste RTSP inviate su di una connessione TCP alla 
porta 554 dell’host lis3.deis.unical.it.
Per quanto riguarda la richieste RTSP esse possono essere trasmesse in diversi modi:
o Connessioni persistenti usate per più transazioni request – response
o Una connessione per ogni transazione request – response
o Connectionless mode
Il tipo di connessione è definito dall’RTSP URI. A differenza di HTTP, RTSP permette 
al media server di inviare richieste al media client. Tuttavia, questo è solo supportato per 
connessioni persistenti. 
MMS streaming protocol 
MMS o Multi Media Server, è un protocollo di streaming sviluppato da Microsoft®. Il  
suo uso principale è quello di portare su Internet trasmissioni multimediali, video, tracce 
audio, live show ed un sacco di altro materiale in real time o preregistrato. Un utente,  
usando questo protocollo, può guardare un media file fornito da uno streaming server 
dedicato  sotto  forma  di  immagine  televisiva  o  traccia  audio  sul  proprio  computer. 
Microsoft ha sviluppato e fornito un media player gratuito (Media Player). MMS è stato 
15
progettato per trasmettere i media all’utente con meno glitch possibili attraverso una rete 
o Internet. MMS non deve essere confuso con i formati come ASF, AVI o MOV che sono 
il formato di codifica di cui MMS è il “vettore” che costituisce la tecnologia streaming. 
MMS  opera  su  TCP o  UDP sulla  porta  1755.  I  server  che  utilizzano  MMS per  lo 
streaming hanno come prefisso dell’URL mms:// o mmst://, per i siti che utilizzano TCP, e 
mmsu://  per quelli  che usano UDP.  Il  protocollo di  trasporto da utilizzare  è  scelto  in 
automatico dal server e dall’utente per
ottenere le prestazioni migliori. La scelta è fatta in automatico usando un metodo di 
selezione del protocollo automatico. L’utente, però, può anche configurare manualmente il 
metodo di trasporto.
Il protocollo MMS è trasmesso dal server all’utente in forma di pacchetti, in blocchi di 
dati  inviati  da Internet direttamente al client.  Un media file  mantenuto sul server può 
essere in formato ASF o WMV. Anche le trasmissioni live sono trasferite in pacchetti di  
dati. Un pacchetto può essere formato da più flussi, nel caso di video o TV, o da un solo 
flusso  come  nel  caso  di  trasmissioni  radiofoniche.  I  flussi  inviati  all’interno  di  un 
pacchetto dipendono dal tipo di contenuto del media. Esistono due tipi di pacchetti:
Command packets e Media packets.
Real Time Messaging Protocol - RTMP
Il  Real Time Messaging Protocol  è un protocollo proprietario sviluppato da Adobe 
Systems usato principalmente con Adobe Flash Media Server  per  lo streaming audio, 
video e di  dati  su Internet  al  client  Adobe Flash Player.  RTMP può essere  usato per 
Remote  Procedure  Calls;  mantiene  una  connessione  persistente  con  un  endpoint  e 
permette la comunicazione in real time. I servizi RPC sono realizzati in modo asincrono 
usando il modello client/server request/response. Il protocollo è il contenitore di pacchetti 
di  dati  che possono essere AMF o dati  audio/video grezzi  come in FLV. Una singola  
connessione è in grado di multiplex are molti flussi utilizzando diversi canali. All’interno 
di questi canali i pacchetti sono divisi in dimensioni fisse. Dal momento che i firewall di 
molte reti aziendali e abitazioni bloccano le connessioni attraverso porte e protocolli che 
non riconoscono, esistono varianti del protocollo che possono essere usate con successo in 
ambienti in cui le misure di sicurezza bloccherebbero l’RTMP. 
o  RTMP: di  default  l’Adobe Flash  Player  utilizza  il  protocollo RTMP sulla  porta 
1935.  Se  fallisce,  prova  nuovamente  sulla  porta  443  (RTMPS)  e  80  (RTMPT)  nel 
tentativo di aggirare le impostazioni dei firewall; questo evita di connessioni TCP/IP su 
porte non standard. La porta di amministrazione di default è la 1111.
16