Progettazione e prototipazione di una infrastruttura Jini-enabled per lo streaming multimediale

Transcript

1 UNIVERSITÀ DEGLI STUDI DI ROMA LA SAPIENZA TESI DI LAUREA IN SCIENZE DELL INFORMAZIONE Progettazione e prototipazione di una infrastruttura Jini-enabled per lo streaming multimediale Relatore: Prof. Giancarlo Bongiovanni Candidato: Alessio Moltoni Correlatore: Matricola: Ing. Mauro Draoli Anno Accademico

2 Indice INDICE 1 Introduzione Scenario Obiettivi Struttura della tesi... 3 PARTE I Linguaggio Java Introduzione Sicurezza Serializzazione Java Remote Method Invocation (RMI) Architettura e protocolli Naming Service e Directory Service Operazioni di callback Caricamento dinamico delle classi Attivazione degli oggetti Comunicazioni RMI in presenza di firewall Distributed Garbage Collection Tecnologie e protocolli di supporto Multicast IP I

3 Indice Internet Group Management Protocol (IGMP) Real-time Transport Protocol (RTP) Introduzione Formato dei pacchetti RTP RTP Control Protocol (RTCP) Sicurezza Java Media Framework (JMF) Introduzione Descrizione Player Processor Sincronizzazione di più media stream Utilizzo del protocollo RTP Jini Introduzione Servizi Lookup service Comunicazioni tra le entità Affitto (lease) Sicurezza Gruppi di oggetti Entry Architettura dei dispositivi Discovery Join II

4 Indice 4.12 Lookup Sintassi delle URL Jini Eventi distribuiti Transazioni JavaSpaces PARTE II Descrizione del sistema Introduzione Specifiche Descrizione introduttiva Utilizzo dei linguaggi, tecnologie e protocolli descritti Descrizione dettagliata Inizializzazione del server Inizializzazione del client Interazione tra server e client Ambiente di utilizzo del sistema Prove del sistema Ambiente di prova Risultati delle prove Descrizione del codice sorgente III

5 Indice 7.1 Introduzione Package common Descrizione del package Interfaccia MultimediaStreaming Package server Descrizione del package Classe Destination Interfaccia Connection Classe ConnectionImpl Classe MultimediaStreamingProxy Classe Server Package client Descrizione del package Classe Client Classe WindowManager Manuale d uso Attivazione del sistema Attivazione del lookup service Attivazione del server Attivazione del client Utilizzo del server Utilizzo del client Conclusioni Considerazioni finali IV

6 Indice 9.2 Sviluppi futuri Appendice: Contenuto del CD-ROM allegato Indice delle definizioni Riferimenti V

7 Introduzione Scenario 1 Introduzione 1.1 Scenario La società attuale sta velocemente aumentando il proprio grado di informatizzazione. Ciò va di pari passo con l avanzamento della tecnologia e la nascita di nuovi metodi di comunicazione ed interazione tra persone e tra persone e macchine. L uomo nella vita quotidiana deve affrontare un numero sempre maggiore di impegni e per questo tenta di alleggerirsi dei compiti più banali o ripetitivi, quali shopping, pratiche burocratiche, faccende domestiche, eccetera. A questo scopo, sta cercando di automatizzare il più possibile queste attività ed avere così più tempo da dedicare a compiti mentalmente più impegnativi o al proprio tempo libero. Le distanze fisiche rappresentano da sempre un ostacolo per le attività umane. Le reti di comunicazione risolvono in gran parte questo problema, permettendo si scambiare informazioni in tempo reale in tutto il mondo. Un altro elemento che oggi riveste un importanza sempre maggiore è il concetto di servizio, inteso come risorsa a disposizione di un entità, essere umano o elaboratore. La nozione di servizio comprende le più svariate realtà, quali risorse fisiche, risorse computazionali, strumenti di comunicazione, informazioni, prestazioni professionali, eccetera. 1

8 Introduzione Obiettivi Sta diventando sempre più importante poter disporre di tali servizi in maniera facile e veloce. Per questo vanno semplificate le fasi necessarie alla fruizione di un servizio, ovvero la sua ricerca, l acquisizione della possibilità di usarlo, l utilizzo vero e proprio e l eventuale pagamento relativo. 1.2 Obiettivi Per venire incontro a tali esigenze, la Sun Microsystems ha creato il sistema Jini, che ha lo scopo di rendere i servizi facilmente reperibili ed utilizzabili. Gli obiettivi della presente tesi consistono nella valutazione dell innovativa tecnologia Jini, esplorandone le funzionalità e l applicabilità a situazioni reali. In questo lavoro viene realizzato un esempio di servizio ed un client che ne effettua la ricerca e quindi lo utilizza, secondo le metodologie ed i protocolli previsti da Jini. Il servizio realizzato consiste nella gestione di un flusso multimediale proveniente da periferiche di acquisizione o da file, presenti su un server. I client possono acquisire i flussi generati dai server e presentarli in output. In caso di utilizzo di periferiche di acquisizione, l infrastruttura risultante è adatta ad essere utilizzata per la telesorveglianza ed anche per la videoconferenza (in tal caso ogni partecipante deve utilizzare sia un server che un client). L utilizzo dei file permette l acquisizione di filmati in modo passivo, cioè senza controllo sul posizionamento all interno del file. 2

9 Introduzione Struttura della tesi Quest ultimo tipo di utilizzo è stato ideato per lo più a scopo dimostrativo delle potenzialità delle tecnologie utilizzate, ma può essere adoperato, ad esempio, in applicazioni streaming a scopo di intrattenimento. Oltre alla tecnologia Jini, sono stati utilizzati altri protocolli e tecnologie, ovvero Multicast IP, UDP, HTTP, Remote Method Invocation, Java Media Framework e Real-time Transport Protocol. La sperimentazione del sistema implementato è stata effettuata su più piattaforme, evidenziando un comportamento dell infrastruttura Jini conforme alle aspettative. 1.3 Struttura della tesi La presente tesi è suddivisa in due parti. Nella PARTE I vengono descritti i linguaggi, i protocolli e le tecnologie utilizzate nella progettazione ed implementazione dell infrastruttura creata. In tale descrizione, viene seguito un ordine logico, secondo il quale tutte le nozioni necessarie in un qualsiasi punto dell esposizione, sono già state trattate in una porzione precedente. Nel capitolo 2 sono esposti aspetti peculiari del linguaggio Java, con particolare attenzione alle caratteristiche di sicurezza ed alle funzionalità orientate all utilizzo delle reti di comunicazione. Nel capitolo 3 vengono descritte le tecnologie ed i protocolli utilizzati, ovvero il multicast IP, il Real-time Transport Protocol e la libreria Java Media Framework. 3

10 Introduzione Struttura della tesi Nel capitolo 4 viene descritto dettagliatamente il sistema Jini in tutte le sue caratteristiche e funzionalità. Nella PARTE II vengono trattate la progettazione e la prototipazione del sistema realizzato, discutendone le strategie, il funzionamento e le prove effettuate. Il capitolo 5 descrive le specifiche ed il funzionamento del sistema. Il capitolo 6 commenta le prove effettuate sull implementazione costruita. Il capitolo 7 descrive dettagliatamente il codice sorgente realizzato. Il capitolo 8 è un manuale per l attivazione e l utilizzo del sistema. 4

11 PARTE I Linguaggio Java Tecnologie e protocolli di supporto Jini

12 Linguaggio Java Introduzione 2 Linguaggio Java 2.1 Introduzione Java è un linguaggio ad oggetti, indipendente dalla piattaforma con avanzate caratteristiche di sicurezza. Queste peculiarità ed altri suoi aspetti lo rendono molto adatto ad applicazioni distribuite. Il codice Java viene eseguito all interno di un ambiente protetto, detto Java Virtual Machine (JVM). La distribuzione attuale è denominata Java 2 Software Development Kit (SDK) versione 1.4. Di seguito vengono descritte alcune rilevanti caratteristiche del linguaggio Java, importanti nella realizzazione del presente lavoro, con particolare attenzione alla programmazione in ambienti distribuiti. 2.2 Sicurezza Il linguaggio Java e la JVM sono stati concepiti ponendo particolare attenzione alla sicurezza. La sintassi del linguaggio Java è molto rigida per quanto riguarda i tipi dei dati, definiti sempre con chiarezza e senza possibilità di ambiguità. Per tutti i metodi è ben definito il numero degli argomenti, il tipo di questi ed il tipo del valore di ritorno. Il compilatore che genera il bytecode, ovvero il codice Java compilato, ovviamente controlla questi elementi, ma questo non è sufficiente per 6

13 Linguaggio Java Sicurezza avere sempre del codice corretto, in quanto il bytecode potrebbe essere generato per altre vie, non utilizzando il compilatore standard. Per impedire l esecuzione di codice errato o pericoloso, la JVM compie un elevato numero di controlli su di esso, prima di eseguirlo. Innanzi tutto, verifica l esattezza dei tipi di dato, degli argomenti e del risultato dei metodi. Vengono esaminate anche le clausole private, protected e public che definiscono i diritti di accesso da parte di altre porzioni di codice. Un entità denominata Class Loader si occupa del caricamento effettivo delle classi, assicurandosi della loro corretta provenienza mediante controlli sintattici sulla URL di origine. Quando incontra una classe presente sia in locale che in remoto, essa dà precedenza alla prima, evitando che il codice remoto prenda il posto di quello locale (ritenuto più sicuro). Essa assicura, inoltre, che le classi caricate siano memorizzate in una cache evitando che possano essere caricate due volte. Questo porterebbe alla duplicazione delle variabili statiche (cioè le variabili uniche per la classe, condivise da tutte le sue istanze). Un applicazione può utilizzare più Class Loader, ad esempio uno per ogni URL di origine delle classi. Il Security Manager ha la funzione di gestire l utilizzo delle librerie native. Le istruzioni Java non hanno accesso diretto alla memoria ed all I/O, mantenendo così un indipendenza dalla piattaforma. Questi accessi sono effettuati dalle librerie native. Esse sono scritte in altri linguaggi (attualmente sono supportati solamente i linguaggi C e 7

14 Linguaggio Java Sicurezza C++, però questi possono richiamare, a loro volta, programmi scritti in altri linguaggi). Il Security Manager permette o meno l utilizzo diretto o indiretto di metodi nativi, in base alla politica di sicurezza configurata. Tipicamente, il codice locale viene considerato più sicuro del codice proveniente da macchine remote. La stessa distinzione viene fatta tra il codice firmato da un entità sicura ed il codice non firmato. Ovviamente, di solito, al codice ritenuto più sicuro vengono concessi maggiori permessi. Inoltre, il Security Manager rifiuta l utilizzo di una classe nativa se questa è stata richiesta da una classe non appartenente al sistema locale. In genere, i metodi nativi vengono definiti con la clausola private per restringerne l accesso alla sola classe di appartenenza, assicurandone un utilizzo sicuro e controllato. Il Security Manager permette il caricamento delle classi soltanto da parte di sottoclassi della classe ClassLoader (la quale utilizza metodi nativi), evitando così che il Class Loader venga aggirato, il che comporterebbe notevoli rischi per la sicurezza. Inoltre, il Class Loader utilizza il Security Manager per proteggere package molto importanti come quelli che contengono le classi di base del linguaggio Java. Il meccanismo di sicurezza utilizza i file di security policy che specificano i permessi concessi. 8

15 Linguaggio Java Sicurezza All interno di tali file è presente una serie di permessi, suddivisi in base al dominio di protezione, costituito dall insieme delle classi provenienti dalla stessa sorgente e firmate dallo stesso soggetto. Quando non viene specificato il firmatario, i permessi si intendono riferiti a codice non firmato o firmato da chiunque. Analogamente, quando non viene indicata l origine delle classi, si intende che i permessi valgono per qualsiasi origine. Tutto il codice esterno alla directory di installazione del Java 2 SDK è soggetto a verifica del rispetto dei permessi. Ogni permesso è concesso soltanto se esplicitamente dichiarato. I permessi sono relativi al file system, alle connessioni di rete, alle proprietà di sistema ed all ambiente runtime. Per quanto riguarda il file system, sono specificati i file o le porzioni del file system sui quali è permessa la lettura, la scrittura o l esecuzione. Per le connessioni di rete, vengono elencati gli host (ed eventualmente le porte) verso i quali si può aprire, o dai quali si può accettare, una connessione. Questa struttura degli elenchi dei permessi consente quindi un controllo molto particolareggiato. I permessi possono anche essere letti e modificati da un applicazione in esecuzione mediante metodi presenti nelle API Java, sempre che a questa venga consentito. 9

16 Linguaggio Java Serializzazione 2.3 Serializzazione La serializzazione consiste nella scrittura della rappresentazione di un istanza di oggetto su di uno stream. In questa operazione vengono scritti sullo stream i valori delle variabili di istanza dell oggetto (non le variabili statiche). Se una variabile è referenziata da un altro oggetto, anche quest ultimo viene serializzato. Questo può portare anche ad una complessa struttura ad albero. Specularmente, dall altra parte dello stream avviene la deserializzazione, ovvero il ripristino dei dati dell oggetto, partendo dalla sequenza letta dallo stream. Perché un oggetto possa essere serializzato, deve implementare l interfaccia Serializable o l interfaccia Externalizable. L interfaccia Serializable non possiede alcun metodo. Per una classe, implementare tale interfaccia significa quindi soltanto dichiarare che si sta partecipando al protocollo di serializzazione. L interfaccia Externalizable possiede i metodi writeexternal e readexternal che hanno rispettivamente lo scopo di definire la rappresentazione dell oggetto da immettere nello stream e da prelevare dallo stream. Una variabile che non deve essere serializzata (ad esempio perché relativa a dati legati alla specifica JVM) deve essere contrassegnata con la parola chiave transient. Gli oggetti serializzati, quando si trovano sullo stream, sono esposti ad attacchi esterni. E opportuno non ricorrere alla serializzazione per i dati che vanno tenuti nascosti da attacchi. 10

17 Linguaggio Java Java Remote Method Invocation (RMI) Una tecnica di protezione da attacchi, anche se di efficacia limitata, consiste nell impostare dei dati non variabili tra le variabili di istanza il cui valore viene ispezionato dopo la deserializzazione alla ricerca di valori inaspettati che ne indicherebbero la corruzione. 2.4 Java Remote Method Invocation (RMI) Questa caratteristica del linguaggio Java permette ad un programma in esecuzione su una JVM di effettuare chiamate a metodi di oggetti presenti su un altra JVM, anche se questa si trova su una macchina remota. Un client può invocare metodi di oggetti remoti con la stessa sintassi utilizzata per invocare i metodi di oggetti locali. L API RMI fornisce classi e metodi che gestiscono tutte le comunicazioni ed i parametri sottostanti, occupandosi degli accessi ai metodi di oggetti remoti. Quando viene effettuata una chiamata ad un metodo remoto, i parametri del metodo devono essere passati al server, mentre l eventuale valore di ritorno deve essere trasmesso indietro al client. Per queste trasmissioni viene utilizzata la serializzazione, quindi gli oggetti che transitano da una JVM all altra devono soddisfare i vincoli della serializzazione, ovvero devono implementare l interfaccia Serializable o Externalizable. 11

18 Linguaggio Java Java Remote Method Invocation (RMI) Architettura e protocolli L RMI è costituito da un architettura a livelli. In un architettura di questo tipo, l implementazione di ogni livello è indipendente da quella degli altri. Applicazione Client RMI Applicazione Server RMI Stub Skeleton Livello di riferimento remoto Connessione virtuale Livello di riferimento remoto Livello di trasporto Connessione di rete Livello di trasporto Figura 2.1 Architettura RMI Lo stub è il proxy sul lato client che rappresenta l oggetto remoto. Gli stub definiscono le interfacce implementate dall oggetto remoto e sono trattati come qualsiasi altro oggetto locale. Lo stub serializza i parametri di chiamata al metodo e deserializza i valori ritornati. 12

19 Linguaggio Java Java Remote Method Invocation (RMI) Il metodo viene eseguito in remoto, utilizzando quindi le risorse della macchina remota. Lo skeleton risiede nel lato server ed ha la funzione di accettare e deserializzare le richieste di chiamata a metodi remoti e di effettuare la chiamata all implementazione dell oggetto sul lato server, quindi ne riceve i valori di ritorno e li trasmette, dopo averli serializzati, verso il client attraverso i livelli sottostanti. Lo skeleton non è più necessario per comunicazioni client-server che utilizzano versioni uguali o superiori alla 1.2 del Java 2 SDK. Gli stub e gli skeleton vengono generati mediante il compilatore rmic fornito con la distribuzione Java. Il livello di riferimento remoto (RRL) opera con l interfaccia di trasporto di basso livello e fornisce uno stream agli stub ed agli skeleton. Esso si occupa di gestire i riferimenti tra client e server. RRL utilizza un componente sul lato server ed uno sul lato client che comunicano tra loro per mezzo del livello di trasporto. La connessione tra i due componenti è di tipo uno a uno. Nel Java 2 SDK versione 1.2 livello RRL è stato migliorato per fornire la possibilità di risvegliare server inattivi attraverso la Remote Object Activation. Il livello transport si occupa di effettuare la connessione tra le JVM coinvolte nella comunicazione, utilizzando i protocolli TCP/IP anche quando queste risiedono sulla stessa macchina. Dalla versione 1.2 del Java 2 SDK è possibile definire un protocollo socket personalizzato. 13

20 Linguaggio Java Java Remote Method Invocation (RMI) Derivando la classe RMISocketFactory è possibile modificare o creare propri protocolli di rete oppure utilizzare protocolli di rete sicuri come il Secure Socket Layer (SSL). Nel Java 2 SDK versione 1.2, sopra i protocolli TCP/IP si pone il protocollo proprietario Java Remote Method Protocol (JRMP). Tale protocollo prevede due stream, uno dal client al server e l altro dal server al client. Sullo stream in uscita dal client viene inviato un header di protocollo seguito da uno o più messaggi. Questi messaggi possono essere un ping per testare se la connessione è ancora viva, un acknowledgement per un server di garbage collection o una chiamata a metodo remoto. Sullo stream in uscita dal server c è la risposta al ping o il valore di ritorno della chiamata. In caso di chiamata a metodo remoto, il messaggio è costituito dall identificatore dell oggetto al quale è indirizzata la chiamata, un campo non più usato (il cui valore è posto uguale a 1), un valore hash che (nella versione più recente del protocollo) rappresenta il metodo da chiamare e l eventuale lista degli argomenti della chiamata. La risposta contiene il valore di ritorno del metodo o l eccezione da esso generata ed un relativo valore di etichetta che può essere utilizzato anche per inviare un acknowledgement ad un garbage collector. I dati che transitano tra due JVM sono passati per valore. In caso di tipi di dato primitivi, vengono trasmessi senza trasformazioni, mentre se si tratta di oggetti viene usato il meccanismo della serializzazione. Però, quando viene trasmesso un oggetto di tipo remoto, ciò che viene passato è un proxy per l oggetto, cioè un riferimento remoto ad esso. 14

21 Linguaggio Java Java Remote Method Invocation (RMI) Nel Java 2 SDK versione 1.3, al JRMP è stata aggiunta una versione di RMI denominata RMI-IIOP che si appoggia al protocollo Internet Inter-ORB Protocol (IIOP) definito dall Object Management Group (OMG). L OMG è il gruppo creatore dell architettura distribuita object-oriented indipendente dalla piattaforma e multilinguaggio Common Object Request Broker Architecture (CORBA). Il protocollo IIOP è utilizzato dai client e dai server CORBA Object Request Broker (ORB) per le loro comunicazioni. L RMI-IIOP permette a Java l interazione con l architettura CORBA e quindi con le applicazioni distribuite multipiattaforma sviluppabili in vari linguaggi, permesse da tale importante architettura Naming Service e Directory Service Per consentire ai client di rintracciare dei servizi remoti vengono utilizzati i Naming Service oppure i Directory Service. L RMI Registry fornisce un servizio di naming lookup. L applicazione RMI registry fornita con il Java 2 SDK si chiama rmiregistry. Può essere eseguito come applicazione indipendente o essere chiamato all interno di codice Java. La sua funzione è quella di mantenere una lista di associazioni tra oggetti di tipo remoto e relativi nomi logici ed ascoltare le richieste di tali oggetti provenienti dai client. L RMI Registry deve essere attivo su ogni macchina su cui ci sono servizi da esportare. Il nome di un oggetto remoto è una stringa di tipo URL nel formato [protocol:]//[host][:port][/[service_name]] oppure 15

22 Linguaggio Java Java Remote Method Invocation (RMI) [protocol:][/][service_name], dove protocol è la parola rmi, host e port sono il nome (localhost per default) e la porta (1099 per default) di ascolto dell RMI registry e service_name è il nome del servizio. Al posto dell RMI Registry possono essere utilizzati altri servizi, tra cui, quelli basati su Lightweight Directory Access Protocol (LDAP). LDAP è un modello per Directory Service basato su entry organizzate gerarchicamente, ognuna contenente un insieme di attributi che hanno un tipo (di solito costituito da una stringa mnemonica) ed uno o più valori. I Directory Service sono dei sistemi di immagazzinamento di informazioni, organizzate e ricercate in base ad attributi. Nel tipo di contesto in cui vengono utilizzati, le informazioni vengono lette molto frequentemente e scritte raramente. Per questo, si adottano tecniche che permettono di effettuare letture in quantità notevole e con elevata velocità di accesso. Le scritture, poiché poco frequenti, non si svolgono all interno di transazioni e non utilizzano meccanismi di roll-back come avviene nei database. Un architettura denominata Java Naming and Directory Interface (JNDI) è inserita nella distribuzione Java. E composta di una Service Provider Interface (SPI) per collegare dei Naming Service e Directory Service ad applicazioni Java e di una API per il loro utilizzo. Nella distribuzione Java sono presenti anche un LDAP Service Provider, un Common Object Service (COS) Naming Service Provider ed un RMI Registry Service Provider. 16

23 Linguaggio Java Java Remote Method Invocation (RMI) Quest ultimo permette ad un applicazione JNDI di accedere ad oggetti remoti registrati in un RMI registry. In questo modo un client non ha bisogno di conoscere l indirizzo di questo. Analogamente, un COS Naming Service Provider invece serve per accedere tramite JNDI ai COS Name Service che sono utilizzati per memorizzare riferimenti ad oggetti CORBA. Un LDAP Service Provider infine serve allo stesso scopo per gli LDAP server. Impiegando il sistema Jini descritto più avanti, Naming Service e Directory Service non vengono utilizzati Operazioni di callback In alcune applicazioni, il server può aver bisogno di effettuare chiamate remote al client. Per questo scopo, un client deve agire come un RMI server, ma ciò non comporta nessuna particolare strategia poiché l RMI funziona senza fare distinzioni tra i ruoli che rivestono i componenti di un applicazione distribuita Caricamento dinamico delle classi Quando un istanza di un oggetto viene trasferita da una JVM all altra, la JVM ricevente deve caricare la classe relativa all oggetto e le classi in esso richiamate. 17

24 Linguaggio Java Java Remote Method Invocation (RMI) A questo scopo, nella JVM che invia un oggetto ad un altra, viene impostata la proprietà java.rmi.server.codebase per impostare la URL dove reperire le classi necessarie. Tale URL può avere come protocollo file, http o ftp. Per i protocolli http e ftp sono necessari dei server che forniscano le classi. Quando un oggetto viene passato ad un altra JVM mediante serializzazione, anche la URL viene trasportata insieme all oggetto, così la JVM di destinazione sa come caricare le classi necessarie Attivazione degli oggetti Nella versione 1.2 del Java 2 SDK, è stata introdotta la possibiltà di risvegliare oggetti inattivi. Questa strategia permette di non occupare inutilmente delle risorse per un oggetto che viene utilizzato raramente oppure permette di risparmiare il tempo di inizializzazione di tale oggetto perché tale operazione viene eseguita una sola volta ed il suo stato viene salvato per le attivazioni successive. Per poter usufruire di questa tecnica, un oggetto deve estendere la classe Activatable e deve essere inserito in un registro RMI per essere attivato solo quando è referenziato attraverso tale registro. L oggetto presente nel registro contiene un riferimento all RMI Activation System Daemon, il processo che si occupa dell attivazione. L applicazione fornita si chiama rmid e la sua porta di default è la

25 Linguaggio Java Java Remote Method Invocation (RMI) Comunicazioni RMI in presenza di firewall I firewall solitamente bloccano il traffico di rete, ad esclusione di alcuni protocolli e/o numeri di porta ben definiti. Poiché il livello di trasporto RMI può aprire connessioni tra client e server su porte non prefissate, molto probabilmente il traffico del protocollo JRMP viene bloccato in presenza di firewall. Per porre rimedio a questo problema, l RMI usa il tunneling http, incapsulando chiamate RMI all interno di comandi post HTTP. Questa strategia viene eseguita automaticamente dal livello transport quando si accorge che i tentativi di connessione vengono bloccati. Quando il client è dietro un firewall, viene usato un comando post nella forma In tale situazione va anche impostata in modo adatto la proprietà di sistema http.proxyhost per indicare l indirizzo del proxy. Anche il server risponde a richieste in questo formato utilizzando il tunneling HTTP. Se è il server a trovarsi dietro un firewall (o il proxy del client può inoltrare richieste solo sulla porta 80), il client non può connettersi ad un numero di porta arbitrario, come invece accadeva nella situazione precedente. In questo caso, il client invia le chiamate JRMP incapsulate verso la porta 80, di default per l HTTP. L header del comando post ora assume la forma Questo causa l esecuzione dello script CGI java-rmi.cgi, incluso nella distribuzione Java, che va preventivamente posto nella directory cgi-bin del server e configurato con il percorso dell interprete Java. 19

26 Linguaggio Java Java Remote Method Invocation (RMI) Tale script invoca una JVM locale che inoltra il comando JRMP estratto al processo server sulla porta indicata. La risposta viene restituita al client, ancora all interno di un comando reply HTTP. L RMI sul lato client estrae il contenuto del pacchetto HTTP e lo invia all appropriato stub. Comunque, questa tecnica di tunneling ha degli svantaggi, tra i quali, un degradamento delle prestazioni, l impossibilità di effettuare operazioni di callback (data la presenza del proxy, l indirezione rende l indirizzo del client non rintracciabile) ed una riduzione della sicurezza in caso di utilizzo dello script cgi, poiché si permette di raggiungere qualsiasi porta, aggirando la protezione del firewall. Il tunneling può in ogni caso essere disabilitato impostando a true la proprietà java.rmi.server.disablehttp Distributed Garbage Collection La garbage collection, oltre che localmente alla singola JVM, può essere compiuta anche in applicazioni distribuite e viene chiamata Distributed Garbage Collection (DGC). In quest ultimo caso, le operazioni di garbage collection sono gestite dall RMI nel livello degli stub e skeleton. Le JVM mantengono un contatore per tenere traccia del numero di reference possedute per ogni oggetto, sia locale che remoto. Un client, quando fa riferimento ad un oggetto remoto per la prima volta, invia una notifica alla JVM sul lato server, che in tal modo inserisce la JVM sul lato client in un apposito elenco relativo all oggetto. 20

27 Linguaggio Java Java Remote Method Invocation (RMI) Analogamente, quando una JVM sul lato client rilascia tutte le reference dell oggetto, essa notifica la JVM sul lato server che così la toglie dall elenco. Quando nessun client mantiene più un riferimento ad un oggetto (ovvero quando l elenco è vuoto), esso può essere sottoposto a garbage collection. Inoltre, un riferimento ad un oggetto remoto posseduto da un client, ha una scadenza temporale. Se tale riferimento non viene rinnovato, si considera rilasciato. Il tempo di durata del riferimento è specificato in millisecondi dalla proprietà java.rmi.dgc.leasevalue e per default vale 10 minuti (cioè ). Per questo motivo, un client può trovarsi in mancanza di un riferimento di cui necessita e dovrebbe essere implementato con la capacità di gestire questa evenienza. 21

28 Tecnologie e protocolli di supporto Multicast IP 3 Tecnologie e protocolli di supporto 3.1 Multicast IP Il Multicast IP è l estensione del protocollo IP per la trasmissione di pacchetti IP ad un host group, identificato da un singolo indirizzo IP. Un host può entrare o uscire da un gruppo multicast IP in qualsiasi momento e non c è limite al numero di host nel gruppo. Un host può appartenere a più gruppi multicast. Un host può trasmettere ad un gruppo senza appartenervi. Un gruppo multicast può essere permanente o transitorio. E permanente se ha un indirizzo ben noto che viene assegnato dalla Internet Architecture and Naming Authority (IANA) e reso pubblico. Un gruppo transitorio invece esiste solo finché ha degli host membri ed ha un indirizzo scelto tra quelli non riservati ai gruppi permanenti. Appositi router sono necessari per il supporto della trasmissione multicast. Esistono tre livelli di conformità al protocollo multicast IP, relativi agli host: Livello 0: l host non supporta il protocollo; Livello 1: l host può inviare pacchetti multicast ma non può riceverli (in tal caso non può entrare a far parte di un gruppo multicast); Livello 2: l host supporta pienamente il protocollo. 22

29 Tecnologie e protocolli di supporto Multicast IP In IPv4, gli indirizzi multicast sono quelli di classe D, ovvero quelli che hanno 1110 nei 4 bit di ordine più alto. Questo significa che in dotted decimal notation, gli indirizzi multicast validi vanno da a L indirizzo non è utilizzato. L indirizzo è usato per indirizzare tutti gli host multicast sulla intranet locale. L indirizzo identifica tutti i router in una intranet. Gli indirizzi da a si utilizzano per identificare un gruppo privato con estensione limitata all organizzazione alla quale appartiene. Il valore del campo time-to-live (ttl) di un pacchetto IP assume in questo protocollo un significato diverso da quello usuale. Qui, un valore 0 significa che il pacchetto rimane confinato nell host locale. Con il valore 1, il pacchetto viene trasmesso soltanto sulla rete locale e non viene inoltrato dai router. Un valore minore di 64 indica che il pacchetto deve essere inoltrato solo all interno dell organizzazione in cui viene generato. Valori maggiori ne consentono l inoltro senza restrizioni. Il nuovo protocollo IPv6 tratta il multicast in maniera più completa e funzionale. 23

30 Tecnologie e protocolli di supporto Multicast IP Internet Group Management Protocol (IGMP) Un router non mantiene una lista degli host appartenenti ai vari gruppi, ma memorizza soltanto gli indirizzi dei gruppi che hanno host presenti nelle sottoreti direttamente connesse. Per conoscere tali gruppi, i router utilizzano l Internet Group Management Protocol (IGMP). Questo protocollo deve essere implementato da tutti gli host di livello 2. I suoi messaggi sono incapsulati in pacchetti IP, in cui il campo che indica la versione di protocollo è posto a 2 ed il campo time-to-live è impostato ad 1 (poiché il pacchetto deve rimanere all interno della sottorete). Il messaggio IGMP inizia con il numero di protocollo, attualmente 1, seguito da un campo che vale 1 se si tratta di un messaggio di richiesta o 2 se si tratta di una risposta. Poi c è un campo non utilizzato posto a 0, seguito da un campo di checksum. Infine c è il campo che contiene l indirizzo di gruppo in un messaggio di risposta. Vale 0 se si tratta di una richiesta. Quando un host riceve una richiesta, non risponde subito ma attende un tempo casuale che va da 0 ad un limite prefissato di secondi. Se durante tale attesa, l host riceve un messaggio di risposta inviato da un altro host ed in tale messaggio è indicato un gruppo a cui esso stesso appartiene, allora non risponde poiché al router basta un solo messaggio di risposta (quello inviato dall altro host) per sapere che in quella sottorete ci sono host appartenenti a tale gruppo. 24

31 Tecnologie e protocolli di supporto Real- messaggio di risposta sull intera sottorete, evitando così la generazione di numerose risposte pressoché contemporanee. Ovviamente, tale risposta viene spedita dall host con il minore Se un host riceve ulteriori richieste prima della scadenza del tempo di avanzare normalmente. nviano richieste IGMP ad intervalli regolari per tenere aggiornato lo stato della sottorete. La frequenza di invio di tali overhead agli host ed alla rete. 3.2 Real- l (RTP) Introduzione Il Real time Transport Protocol ( ) è un protocollo di livello transport adatto per la trasmissione di dati in tempo reale, come audio st o multicast. del servizio per servizi in tempo reale. RTP Control Protocol RTCP) rollo e l identificazione dei dati dell RTP. 25

32 Tecnol Real time Transport Protocol (RTP) I protocolli RTP ed RTCP sono indipendenti dai protocolli di livello network e transport sottostanti. L RTP fornisce un servizio di trasferimento di dati di tipo end- -end, ayload, numerazione delle sequenze, timestamping e monitoraggio. In questo contesto, un profilo payload e codici di identificazione degli stessi e nell eventuale estensione o modifica dell RTP per partic L RTP, solitamente, si appoggia al protocollo di livello transport che fornisce servizi di multiplexing e checksum, ma può essere utilizzato anche insieme ad altri protocolli di livello transport. Il protocollo UDP non garantisce l integrità dei dati in arrivo né il loro corretto ordinamento, privilegiando così la velocità. Per questo, è adatto a flussi audio e video in tempo reale, per i quali il rispetto degli stretti vincoli temporali è più importante dell assoluta integrità dei dati. Il corretto ordinamento dei dati deve essere ricostruito dal ricevente. Se è necessaria un elevata qualità del servizio, possono essere utilizzati protocolli connection-oriented. La figura seguente mostra i livelli di un architettura di protocolli di rete in presenza dell RTP. 26

33 Tecnologie e protocolli di supporto Real-time Transport Protocol (RTP) Applicazione RTP RTCP UDP IP Altro protocollo di livello transport Altro protocollo di livello network Figura 2.1 Architettura a livelli dei protocolli di rete in presenza dell RTP Se viene impiegato il protocollo UDP, un flusso RTP utilizza un numero di porta pari ed il relativo stream RTCP usa il numero di porta dispari successivo. L RTP non garantisce la tempestività nella consegna dei dati, affidandola completamente ai protocolli sottostanti. L RTP permette il trasferimento di dati in modalità multicast, purché i protocolli di rete sottostanti lo permettano. Una sessione RTP è la connessione tra un insieme di partecipanti ad una comunicazione RTP. Per ogni partecipante, la sessione è definita da una coppia di indirizzi di livello transport (costituiti da un unico indirizzo di livello network ed una coppia di porte, una per l RTP e l altra per l RTCP). Nel caso di comunicazione multicast, la coppia di indirizzi è la stessa per tutti i partecipanti. Una comunicazione con più tipi di media (ad esempio, video ed audio) si svolge in una sessione 27

34 Tecnologie e protocolli di supporto Real- ricevere solo i tipi di media desiderati. synchronization source ( ) è l entità che ta da un valore numerico. Tale entità genera pacchetti con identificatori di tempo e di sequenza Il protocollo prevede un entità allo stesso livello dell RTP chiamata, che prende in ingresso stream provenienti da più sorgenti, li rete. Questa funzionalità è molto utile per diminuire il traffico di rete. C è però lo svantaggio per il ricevente di non poter decidere quali Un provenienti da varie fonti, ma può anche essere utilizzato con un payload video per costruire una sorta di mosaico su schermo, affiancate. Una contributing source CSRC) pacchetti in ingresso ad un mixer. contiene la lista delle CSRC che hanno contribuito alla sua creazione. Un altro oggetto che processa pacchetti RTP è il translator eseguire conversioni di formato, operazioni di tunneling o instradamenti unicast di pacchetti multicast. Un translator non modifica il valore SSRC che rimane, quindi, quello 28

35 Tecnologie e protocolli di supporto Real-time Transport Protocol (RTP) Formato dei pacchetti RTP Un pacchetto RTP è costituito dall header e dal payload. L header è composto dai seguenti campi: version (2 bit): è la versione del protocollo RTP. Attualmente vale 2; padding (1 bit): è posto ad 1 se dopo il payload sono presenti dei byte di riempimento (ovvero privi di informazioni). Questi possono essere necessari ad alcuni algoritmi di compressione che agiscono su blocchi di lunghezza fissa o possono essere utilizzati per inserire più pacchetti RTP in un solo pacchetto di un protocollo di livello inferiore; extension (1 bit): se impostato ad 1, l header è seguito da un estensione dello stesso; CSRC count (4 bit): conta il numero di identificatori CSRC che seguono la parte a lunghezza fissa dell header; marker (1 bit): ha un significato dipendente dallo specifico profilo utilizzato. Possono anche esservi più campi di questo tipo, creati sottraendo dei bit al campo successivo; payload type (7 bit): identifica il formato del payload. Tipi di payload addizionali possono anche essere specificati mediante meccanismi e protocolli esterni all RTP; sequence number (16 bit): numero di sequenza del pacchetto. Viene incrementato in passi di 1 ed è utilizzabile dal ricevente per ricostruire l esatta sequenza degli stessi e per scoprire perdite di pacchetti. Il numero di sequenza iniziale è scelto a caso per rendere più difficile l attacco di dati eventualmente criptati; 29

36 Real time Transport Protocol (RTP) (32 bit): indica l istante di campionamento del primo dal tipo di payload e deve essere abbastanza elevata da permettere la sincronizzazione del flusso di dati. Anche in precedente, assume un valore casuale nel primo pacchetto; (32 bit): identifica la synchronization source. Ha un valore casuale che deve essere diverso da quello di ogni altra CSRC (da 0 a 15 eleme contributing source per il pacchetto. Solo le prime 15 possono essere inserite. Ulteriori eventuali contributing source non dai mixer e sono i valori SSRC di ogni contributing source. Le eventuali estensioni dell header hanno il seguente formato: all estensione. Il contenuto di questo campo dipende dal particolare profilo; ifica la lunghezza del resto dell estensione in parole di 32 bit; di un profilo, utili per il trattamento del payload. L header è seguito dal payload, il cui contenuto dipende dal formato uti 30

37 Tecnologie e protocolli di supporto Real-time Transport Protocol (RTP) RTP Control Protocol (RTCP) L RTCP è basato sulla trasmissione, ad intervalli periodici, di pacchetti di controllo a tutti i partecipanti di una sessione RTP. Questo protocollo compie quattro funzioni: 1. effettua un controllo continuo sulla qualità della comunicazione; 2. trasporta un identificatore persistente relativo ad ogni sorgente, detto canonical name (CNAME). Poiché gli identificatori SSRC possono variare per la risoluzione di un conflitto (cioè quando si hanno più identificatori SSRC uguali) o per il riavvio di un applicazione, i riceventi utilizzano il CNAME per tenere traccia dei vari partecipanti. I riceventi impiegano il CNAME anche per riconoscere i vari stream che appartengono ad una stessa sorgente in sessioni RTP correlate (ad esempio, audio e video); 3. valuta il numero di partecipanti ad una sessione RTP. Poiché tutti i partecipanti inviano pacchetti RTCP, ogni partecipante riceve tali pacchetti da tutti gli altri. In questo modo, esso è in grado di calcolare il numero di partecipanti. Questo numero è utilizzato per stabilire il ritmo in base al quale i pacchetti RTCP devono essere inviati. Maggiore è il numero di partecipanti, minore è il ritmo di invio di pacchetti RTCP. In questo modo si evita un impiego della banda di trasmissione troppo elevato da parte di tali pacchetti; 4. opzionalmente, trasporta informazioni di controllo della sessione, come, ad esempio, informazioni aggiuntive sull identità di un partecipante. 31

38 Real time Transport Protocol (RTP) Esistono vari tipi di pacchetti RTCP con funzioni diverse: (Sender report generate da partecipanti che sono trasmittenti attive; RR Receiver report): è utilizzato per la comunicazione di attive; (Source description come CNAME, NAME (user name), (indirizzo e- BYE ( ): indica la fine della partecipazione ad una sessione da parte di una so APP ( -defined dipendenti dall applicazione. I mixer ed i translator processano anche i pacchetti RTCP. tipo SR o RR, ma ne crea di propri. I pacchetti SR si riferiscono ai dati esso. Tutti gli altri tipi di pacchetti RTCP ricevuti dal mixer, vengono noltrati inalterati sulla rete. I translator ricevono i pacchetti RTCP, in alcuni casi vi effettuano 32

39 Tecnologie e protocolli di supporto Real-time Transport Protocol (RTP) Sicurezza L utilizzo di meccanismi di sicurezza in RTP è molto importante, perché le comunicazioni possono essere attaccate in vari modi: possono essere falsificati gli indirizzi di livello network relativi a sorgenti o destinazioni; possono essere alterati header e payload dei pacchetti; possono essere forniti falsi dati identificativi, quali, ad esempio, CNAME e NAME, eventualmente allo scopo di impersonare un altro partecipante; in una comunicazione multicast, una sorgente non sa chi riceve la trasmissione e quindi non può garantire la privacy dei dati. Il protocollo RTP non fissa criteri per assicurare integrità, autenticità e segretezza di una trasmissione RTP. Queste funzionalità possono essere gestite da protocolli di livello inferiore e superiore. Un modo di garantire la segretezza dei dati è quello di definire dei tipi di payload criptati. Un profilo può definire dei servizi e degli algoritmi di sicurezza che un applicazione deve fornire. 33

40 Java Media Framework (JMF) 3.3 Java Media Framework (JMF) Java Media Framework ( ) è una API in linguaggio Java per la gestione dei media. La versione attuale è la 2.1.1a. JMF gestisce varie possibili origini di sequenze dati, ovvero file, videocamere, microfoni o trasmissioni in diretta da fonti esterne. Ad una sequenza possono essere applicati degli effetti. Una sequenza può venire compressa e decompressa e può esserne convertito il formato. Dopo essere processata, una sequenza può essere memorizzata su file, trasmessa su rete o presentata tramite periferiche di output come monitor e diffusori acustici. L astrazione di una periferica di presentazione viene detta renderer. La destinazione di uno stream viene chiamata data sink. Il flusso dati viene detto media stream. Ognuno di essi può contenere più canali dati, detti track. Il tipo della track specifica se essa è audio o video. Il formato dei dati di uno stream viene chiamato content type. Uno stream può essere identificato dalla sua locazione e dal protocollo utilizzato per accedervi (FILE, HTTP, eccetera). Anche gli stream acquisiti da periferiche di acquisizione hanno dei loro specifici nomi di protocollo.

41 Tecnologie e protocolli di supporto Java Media Framework (JMF) Descrizione Le API JMF creano un astrazione rispetto al sistema operativo ed ai driver delle periferiche di acquisizione. Gli stream possono essere distinti a seconda del modo in cui sono trasmessi: pull, se la trasmissione è avviata e gestita dal client. Sono protocolli di questo tipo, ad esempio, il protocollo FILE ed il protocollo HTTP; push, se invece è il server ad iniziare e controllare la trasmissione. E di questo tipo, ad esempio, il protocollo RTP. Entrambi i tipi di stream possono essere bufferizzati per ottimizzare il flusso di trasmissione. Un data source incapsula il media stream, fornendo un semplice protocollo di connessione. Anche il data source si distingue a seconda che sia di tipo pull o push, buferrizzato o meno. Un CloneableDataSource serve per creare cloni di un data source. Un MergingDataSource è utilizzato per contenere l unione di più data source. La sequenza di dati deve osservare dei vincoli temporali, ovvero deve essere acquisita, manipolata e presentata (o trasmessa) cercando di minimizzare ritardi o perdite di dati. Ad ogni flusso di dati è associato un media-time che indica la posizione corrente all interno del flusso. Vale 0 all inizio del flusso. 35

42 Tecnologie e protocolli di supporto Java Media Framework (JMF) Uno stream può essere presentato a vari fattori di rate. Questa quantità indica la velocità di output rispetto alla velocità normale (che quindi equivale ad un rate di 1). Valori negativi indicano una presentazione dello stream in senso inverso, dalla fine verso l inizio. Soprattutto se acquisito da rete, uno stream non può essere presentato istantaneamente, ma è soggetto ad un certo tempo di ritardo, chiamato start latency. La qualità della presentazione di un media stream dipende dallo schema di compressione utilizzato, dalle capacità di elaborazione della macchina che fornisce l output e, per stream acquisiti da rete, dalla larghezza di banda disponibile rispetto a quella richiesta. Più media stream possono essere fusi in un unico media stream. Lo stream risultante viene detto multiplexed o complex. L oggetto che compie questa operazione viene detto multiplexer. Viceversa, da uno stream multiplexed possono essere estratti i singoli stream. Questa operazione è svolta da un demultiplexer. Un flusso può essere compresso e decompresso da un codec. Tipicamente, viene compresso per essere trasmesso o memorizzato, mentre viene decompresso per effettuarne la presentazione o la manipolazione. Un codec accetta dei dati in ingresso in un certo numero di formati e produce dati in uscita secondo un altro numero di formati. In alcune situazioni può essere utile porre dei codec in serie, facendo corrispondere l uscita di un codec all ingresso del codec successivo. 36

43 Tecnologie e protocolli di supporto Java Media Framework (JMF) Vari effetti possono essere applicati ad un flusso di dati per modificarne il contenuto. Ad esempio, ad un file audio può essere applicato un effetto che ne produce un eco. Solitamente gli effetti vengono applicati ai dati non compressi. Le API definiscono delle interfacce da implementare per aggiungere dei componenti detti plug-in, che possono essere multiplexer, demultiplexer, codec, effetti e renderer. La presentazione di un media stream viene effettuata tramite un player. Quest oggetto fornisce metodi per ottenere i componenti visuali ed i componenti di controllo utilizzati per la gestione della presentazione. Simile al player è il processor, che ha però funzionalità più estese e permette un maggiore controllo sul media stream. Il package JMF fa ampio uso di eventi per gestire i vari stati degli oggetti, comprese le situazioni di errore. Esistono vari tipi di controlli per gestire i molteplici aspetti di un media stream. Sono definiti controlli per i formati delle tracce audio e video, per il buffering, per il data rate, per la qualità, per il volume, per il posizionamento in un punto dello stream, eccetera. Molti di questi controlli forniscono componenti visuali mediante i quali gestire i loro parametri. Un programmatore può anche creare componenti visuali personalizzati il cui stato può essere aggiornato mediante l ascolto degli eventi generati dai controlli. 37

44 Tecnologie e protocolli di supporto Java Media Framework (JMF) Nel JMF sono definiti quattro tipi di manager, utilizzati per gestire vari tipi di funzionalità: Manager: gestisce la creazione di player, processor, data source e data sink; PackageManager: mantiene un registro dei package che contengono player, processor, data source e data sink personalizzati; CaptureDeviceManager: mantiene un registro delle periferiche di acquisizione disponibili; PlugInManager: mantiene un registro di componenti plug-in di elaborazione, quali multiplexer, demultiplexer, codec, effetti e renderer Player Un player processa un media stream in ingresso fornito da un DataSource e lo presenta in output su periferiche adatte, come monitor e diffusori acustici. Un player non fornisce un controllo sull elaborazione che effettua o sul modo in cui crea la presentazione dello stream. Un player attraversa sei stati: Unrealized, Realizing, Realized, Prefetching, Prefetched e Started. Ad ogni transizione di stato, un player lancia un evento. Quando viene creato, un player si trova nello stato Unrealized e non ha alcuna informazione riguardo il media stream che deve presentare. 38