Progetto E Realizzazione Di Una Libreria Per La Gestione Di Un Protocollo Per Le Trasmissioni Multicast

Università degli Studi “Roma Tre” Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica

Progetto e realizzazione di una libreria per la gestione di un protocollo per le trasmissioni multicast

Relatore

Laureando

Maurizio Patrignani

Claudio Di Vita 115787/98

Anno Accademico 2003/2004

Indice degli argomenti 1 Introduzione..........................................................................1 2 Le trasmissioni ed i protocolli multicast......................................4 2.1 Le trasmissioni multicast....................................................4 2.2 I protocolli multicast..........................................................5 2.2.1 SIP: Session Initiation Protocol.....................................5 2.2.2 SAP: Session Announcement Protocol............................6 2.2.3 RTSP: Real Time Streaming Protocol..............................7 3 Il protocollo SDP: Session Description Protocol............................8 3.1 Caratteristiche del protocollo SDP........................................8 3.2 Struttura di un messaggio SDP..........................................10 3.3 Il futuro di SDP...............................................................14 4 Stato dell'arte delle librerie SDP..............................................15 4.1 La JSR 141 ed il progetto JAIN-SIP del NIST........................15 4.2 La libreria SDP sviluppata dalla Columbia University.............16 5 Alternative software per la gestione di un protocollo...................18 5.1 Requisiti della libreria.......................................................18 5.2 Utilizzo di parser specializzati............................................20 5.3 Costruzione di un albero rappresentante il messaggio...........22 5.4 Specifica di una grammatica context-free............................25 5.5 Considerazioni sulle tecniche proposte................................28 6 La libreria jSDP.....................................................................31 6.1 Architettura preliminare della libreria.................................31

6.2 L'introduzione delle espressioni regolari..............................33 6.3 Il parsing di un campo SDP...............................................35 6.4 Creazione di un messaggio...............................................37 6.5 Rappresentazione delle descrizioni.....................................39 6.6 Valutazione del messaggio................................................42 6.7 Specifica della sintassi dell'annuncio...................................50 6.8 Generazione automatica del parser e delle descrizioni...........52 7 Analisi comparativa di librerie SDP...........................................60 7.1 La libreria sviluppata dal NIST...........................................60 7.1.1 Parsing dei campi SDP...............................................60 7.1.2 Valutazione sintattica e creazione di un annuncio..........65 7.1.3 Giudizio sulla libreria..................................................68 7.2 La libreria della Columbia University...................................69 7.3 I risultati ottenuti dalla libreria jSDP...................................70 8 Conclusioni...........................................................................71 9 Bibliografia...........................................................................73

1 Introduzione

Ogni giorno milioni di persone usufruiscono dei servizi messi a disposizione dalla rete delle reti, Internet. Il continuo scambio di informazioni rappresenta il meccanismo alla base delle trasmissioni, e nella rete questo avviene mediante l'utilizzo di diversi protocolli, intendendo per protocollo un insieme di convenzioni che permettono la comunicazione, specificando così un linguaggio comune. Ovviamente esistono molteplici gruppi di protocolli ognuno dei quali, magari con l'ausilio di altri, si occupa della gestione di un particolare servizio o di una certa tipologia di trasmissione. Recentemente nell'ambito della comunità Internet è notevolmente aumentato l'interesse per una serie di servizi, come la videoconferenza, basati sulla trasmissione simultanea delle informazioni verso differenti destinazioni. Questo particolare metodo trasmissivo prende il nome di multicast, e rappresenta un componente determinante, sia attualmente che nel prossimo futuro, dei servizi disponibili su Internet. Nelle macchine capaci di trattare trasmissioni multicast, esistono degli appositi strati software in grado di gestire i protocolli necessari all'utilizzo di questa tecnologia. Questi strati sono talvolta molto complessi, quindi risulta conveniente suddividerli in diversi moduli, ovvero un insieme di elementi con funzionalità specifiche. Lo sviluppo dei componenti preposti alla gestione di un protocollo, avviene spesso mediante la creazione di librerie scritte in Java, un linguaggio di programmazione piuttosto recente ma ampiamente diffuso che risulta particolarmente indicato

Introduzione

1

nella realizzazione di applicazioni di rete. Il panorama nel quale opera il protocollo SDP, Session Description Protocol, coinvolge un largo numero di trasmissioni multicast, in quanto offre supporto a molti protocolli. La realizzazione di una libreria in grado di gestire SDP, rappresenta quindi un valido esempio delle problematiche che devono essere affrontate nello sviluppo di un pacchetto software capace di gestire un protocollo per le trasmissioni multicast. Questa tesi definisce i requisiti funzionali richiesti ad una libreria per la gestione del protocollo SDP, ed analizza le diverse strade percorribili per soddisfarli. Queste valutazioni dimostrano che l'utilizzo di tecniche molto sofisticate, come la generazione automatica, a partire dalla specifica dell'insieme delle regole sintattiche e grammaticali che definiscono un linguaggio, di un componente in grado di interpretare un protocollo, non sono, per diversi motivi, sufficienti a raggiungere gli obiettivi richiesti. In questa trattazione si passano in rassegna le differenti architetture e metodologie software che possono essere utilizzate per risolvere il problema,

e si mostra come combinando sapientemente alcune

caratteristiche proprie di ciascuna tecnica, si possa ottenere una soluzione efficiente. Il pacchetto software realizzato è stato confrontato con le librerie SDP attualmente disponibili, in modo tale da poter giudicare la bontà del lavoro svolto, mettendolo in relazione con i risultati ottenuti da prodotti già collaudati. Questi test documentano la validità delle scelte effettuate per la realizzazione di una libreria per la gestione del protocollo SDP, e permettono di affermare che il

Introduzione

2

pacchetto sviluppato, che è stato denominato jSDP, Java Session Description Protocol, è in grado soddisfare efficacemente tutti i requisiti individuati durante la fase di progettazione. Nei primi capitoli di questo documento vengono illustrate con maggiore chiarezza le caratteristiche delle trasmissioni multicast e di alcuni dei protocolli utilizzati in questa tipologia di comunicazione, dedicando un'attenzione particolare ad SDP. Successivamente si menzionano le funzionalità offerte dalle librerie SDP esistenti, in modo tale da favorire l'identificazione dei requisiti ed introdurre le diverse tecniche proposte per soddisfarli. In seguito vengono illustrate ed analizzate, passo dopo passo, le scelte prese nella realizzazione della libreria jSDP. La tesi si conclude rendendo noto l'esito dei test che sono stati effettuati sulla libreria jSDP e sugli altri pacchetti software disponibili per la gestione del protocollo, evidenziando i buoni risultati ottenuti mediante la strategia proposta.

Introduzione

3

2 Le trasmissioni ed i protocolli multicast

In questo capitolo vengono approfondite le tematiche relative alle trasmissioni multicast ed ai protocolli che permettono questo tipo di comunicazioni, soffermandosi in modo particolare sui protocolli che collaborano con SDP.

2.1 Le trasmissioni multicast Le trasmissioni multicast permettono lo scambio simultaneo delle informazioni tra destinazioni differenti. In queste trasmissioni la consegna dei messaggi avviene in maniera piuttosto particolare, cercando di evitare, per quanto possibile, la duplicazione dei dati: ogni pacchetto viene inoltrato su un link della rete solamente una volta, e ne viene effettuata una copia esclusivamente nel caso in cui i collegamenti verso la destinazione si dividono. La maggior parte di questi trasmissioni avviene, a livello di rete, sfruttando l'IP multicast che, nonostante sia molto efficiente dal punto di vista concettuale, richiede la presenza di particolari apparecchiature sulla rete nella quale viene utilizzato, situazione che in passato è stata oggetto di parecchie critiche. I normali router infatti non sono in grado di gestire i pacchetti IP multicast. Pertanto

quando

un

multicast

router

(mrouter)

intende

inviare

delle

informazioni attraverso un tratto di rete che non supporta le trasmissioni multicast, è costretto ad incapsulare i dati in modo tale che sembrino dei comuni pacchetti unicast per i router e le sottoreti coinvolte nella trasmissione.

Le trasmissioni multicast

4

Un mrouter in questa situazione genererà, per ogni pacchetto, una nuova intestazione IP, nella quale metterà l'indirizzo di destinazione dell'mrouter che si trova al di là del tunnel. Il multicast router che riceve il pacchetto toglie questa intestazione, e se sulla rete locale ci sono dei destinatari lo invia con l'header multicast oppure se ha altri tunnel in uscita ripete il procedimento di incapsulamento. Nella rete Internet esiste una dorsale multicast, detta Multicast Backbone, che provvede alla trasmissione audio e video in tempo reale utilizzando il protocollo IP multicast e sfruttando, ovviamente, l'incapsulamento dei pacchetti.

2.2 I protocolli multicast Il livello di applicazione nelle trasmissioni multicast è caratterizzato da un'incredibile quantità di protocolli, ognuno dei quali è specializzato per una particolare tipologia di applicazioni. Nelle prossime pagine verrano presentati i protocolli che interagiscono maggiormente con SDP.

2.2.1 SIP: Session Initiation Protocol Il protocollo SIP, Session Initiation Protocol, è stato definito per la prima volta nel marzo del 1999 dalla RFC 2543. Il suo scopo è quello di creare, modificare e terminare delle sessioni, ovvero delle comunicazioni, con uno o più partecipanti. Queste sessioni includono le videoconferenze, le chiamate telefoniche via Internet e la distribuzione di contenuti multimediali. I partecipanti ad una

SIP: Session Initiation Protocol

5

sessione possono comunicare principalmente mediante trasmissioni multicast, anche se sono ammesse anche particolari combinazioni di trasmissioni unicast. I cosiddetti “inviti” SIP utilizzati per creare le sessioni, trasportano al loro interno uno o più messaggi SDP che permettono ai partecipanti alla trasmissione di prendervi parte. Attualmente il protocollo SIP viene utilizzato per stabilire e gestire le connessioni necessarie all'utilizzo della tecnologia Voice Over IP, ed in questo ruolo sta sostituendo, anche se gradualmente, il protocollo H.323.

2.2.2 SAP: Session Announcement Protocol Il protocollo SAP, Session Announcement Protocol, è un protocollo utilizzato per assistere l'annuncio di videoconferenze oppure di altri media, trasmessi in multicast, comunicando le informazioni necessarie all'instaurazione di una connessione agli eventuali partecipanti. Ovviamente questi dati sono specificati mediante una intestazione SDP, anche se, diversamente dal protocollo SIP, in un annuncio SAP può esser presente al massimo un messaggio SDP. Un server preposto alla creazione di pacchetti SAP, trasmette periodicamente un pacchetto di avviso ad un insieme noto di indirizzi multicast, prevedendo che i ricevitori del messaggio SAP siano anche i potenziali partecipanti alla sessione annunciata. Di conseguenza un client in attesa di un pacchetto SAP, una volta venuto a conoscenza degli indirizzi multicast e delle porte che deve tenere sotto controllo (questo avviene mediante altri protocolli che non riguardano direttamente le tematiche trattate in questa tesi), si mette in ascolto per poter

SAP: Session Announcement Protocol

6

così ricevere i messaggi SAP a lui destinati, avendo così la possibilità di prendere parte alle sessioni annunciate.

2.2.3 RTSP: Real Time Streaming Protocol Lo streaming è il termine che viene associato alla distribuzione in tempo reale di informazioni multimediali. Il protocollo RTSP, Real Time Streaming Protocol, appartiene, così come UDP, alla categoria di protocolli di rete utilizzata per lo streaming, e permette una rapida distribuzione dei dati dalla sorgente alla destinazione. L'architettura alla base di questo protocolli riserva maggiore importanza alla continuità del flusso delle informazioni trasmesse, senza ricorrere alla ritrasmissione dei pacchetti in caso di errori: in questo modo anche se alcuni dati non giungono a destinazione lo streaming può continuare, senza grosse ripercussioni sulla qualità del servizio. RTSP permette di instaurare e controllare uno o più flussi multimediali sincronizzati, sia per le trasmissioni audio che per quelle video. In pratica offre al client la possibilità di controllare da remoto lo streaming del server, come se questo fosse un comune videoregistratore, anche se, solitamente, il protocollo RTSP non provvede autonomamente alla consegna delle informazioni.

RTSP: Real Time Streaming Protocol

7

3 Il protocollo SDP: Session Description Protocol

Nelle pagine che seguono si provvede alla presentazione di SDP, un protocollo che offre supporto alle trasmissioni multicast e che rappresenta un valido esempio delle problematiche che devono essere affrontate nella trattazione di questa tipologia di protocolli.

3.1 Caratteristiche del protocollo SDP Nell'RFC 2327 viene specificato il protocollo SDP, Session Description Protocol, il cui scopo è quello di trasportare informazioni relative alla trasmissione di uno o più media nelle sessioni multimediali, permettendo a chi riceve un messaggio SDP di prendere parte ad una sessione. Una sessione multimediale è definita come un insieme di trasmissioni, perlopiù audio e video, che sono attive in determinati lassi di tempo. I dati trasportati da un annuncio SDP sono

•

Il nome della sessione ed il suo scopo

•

I tempi in cui la sessione è attiva

•

I media contenuti nella sessione

•

Le

informazioni

necessarie

alla

ricezione

delle

trasmissioni

Inoltre possono essere specificate delle notizie extra, come la larghezza di

Caratteristiche del protocollo SDP

8

banda disponibile e la persona responsabile della sessione. Un'intestazione SDP fornisce quindi tutte le informazioni necessarie per prendere parte ad una sessione. Naturalmente la descrizione dei media è molto particolareggiata e comprende

•

La tipologia del media (video, audio...)

•

Il protocollo di trasporto utilizzato (RTP, H.320...)

•

Il formato del media (H.261 video, MPEG...)

•

Gli indirizzi e le porte ai quali è possibile reperire i media

Il formato degli indirizzi varia a seconda della sua tipologia, in quanto possono essere specificati indistintamente sia indirizzi multicast che unicast, sebbene questi ultimi vengano raramente utilizzati. La descrizione dei tempi di attività è resa necessaria dall'eventualità che le risorse comprese in una sessione non siano sempre disponibili. Per questo motivo in un annuncio SDP è obbligatorio indicare dei parametri che permettano di stabilire quando una sessione è attiva, quindi fruibile. Come detto in precedenza in un messaggio SDP è possibile specificare delle informazioni extra, che possono fare riferimento a diverse parti dell'intestazione. Questi dati supplementari possono rilevarsi utili per i destinatari di un messaggio, aiutandoli a determinare se e come possono prendere parte ad una sessione. Appare quindi evidente che il protocollo SDP fornisce un formato standard per Caratteristiche del protocollo SDP

9

la rappresentazione delle informazioni che descrivono sessioni multimediali, ma non incorpora un protocollo di trasporto.

3.2 Struttura di un messaggio SDP Un messaggio SDP è composto da una serie di linee di testo nella forma

=, dove è sempre un solo carattere minuscolo mentre è una stringa di testo il cui formato dipende da . Queste linee prendono il nome di campi. Una descrizione è un particolare insieme di campi. Un annuncio consiste in una sezione che descrive la sessione, che può essere seguita da una o più descrizioni dei media. Alcuni campi in ogni descrizione sono richiesti ed altri sono opzionali, ma tutti devono apparire nell'ordine indicato

Descrizione della sessione •

v=

[Version]

Indica la versione del protocollo utilizzata nel messaggio •

o=

[Origin]

Contiene delle informazioni sull'autore della sessione e comprende alcuni dati che servono ad identificare univocamente la sessione. Tra questi ci sono l'id della sessione e la sua versione, oltre all'indirizzo della macchina che ha generato il messaggio •

s=

[SessionName]

Il nome della sessione Struttura di un messaggio SDP

10

•

i= *

[Information]

Contiene dei dati che sono utili a determinare gli scopi della sessione •

u= *

[Uri]

Contiene un URI che punta ad una risorsa fornisce maggiori informazioni sulla sessione. Può avere diverse occorrenze •

e= *

[Email]

Un indirizzo di posta elettronica da contattare per avere maggiori ragguagli sulla trasmissione. Può avere diverse occorrenze •

p= *

[Phone]

Un numero telefonico, che deve includere il prefisso internazionale, con il quale è possibile contattare il creatore della sessione. Può avere diverse occorrenze •

c=

[Connection]

Uno dei campi più importanti, in quanto specifica i dati necessari alla connessione. Indica la tipologia della rete, e l'indirizzo delle risorse specificando se si tratta di un indirizzo IP4 oppure IP6. Se è presente a questo livello è valido per tutti i media trasmessi, a meno che una particolare descrizione dei media non specifici parametri differenti •

b= *

[Bandwith]

Propone larghezza di banda da utilizzare per

una

specifica applicazione. Può avere più occorrenze •

Descrizione dei tempi di attività Contiene le informazioni relative ai tempi di attività della sessione sessione, utilizzando due diverse tipologie di campo Struttura di un messaggio SDP

11

•

z=* Specifica

[ZoneAdjustment] come

interpretare

correttamente

le

informazioni fornite nella descrizione dei tempi di attività. Questo campo può essere necessario per ovviare ai problemi causati dai differenti fusi orari in uso •

k= *

[EncryptionKey]

Viene utilizzato per trasportare delle chiavi per decodificare

i

contenuti

delle

trasmissioni.

Indispensabile per creare delle sessioni private •

a= *

[Attribute]

Serve a specificare alcune proprietà della sessione. Si tratta di un campo molto flessibile, in quanto, se sfruttato opportunamente, permette di arricchire l'insieme delle informazioni trasportate •

Descrizione dei media * Si occupa di definire le proprietà relative alla trasmissione di un particolare media. La sua struttura verrà mostrata in seguito. Può avere diverse occorrenze, anche se non si tratta di un campo obbligatorio

Descrizione dei tempi di attività •

t=

[Time]

Specifica “l'orario” in cui è disponibile una sessione, indicandone l'inizio e la fine. La rappresentazione di questi dati deve avvenire utilizzando dei timestamp NTP, Network Time Protocol. Se la sessione è sempre attiva il suo valore del campo è t=0 0

Struttura di un messaggio SDP

12

•

R= *

[RepeatTime]

Poiché una sessione può essere disponibile ad intervalli di tempi regolari, questo campo permette di specificare questi intervalli Descrizione dei media •

m=

[Media]

Indica la tipologia ed il formato utilizzato nella trasmissione di un media •

i= *

[Information]

•

c=

[Connection]

Specifica i parametri necessari per accedere al media, ovvero gli indirizzi (oppure l'indirizzo) al quale è reperibile. Questo campo può anche non essere specificato, a patto però che sia stato definito un campo Connection nella descrizione della sessione •

b= *

[Bandwith]

•

k= *

[EncryptionKey]

•

a=*

[Attribute]

Mediante questo campo è possibile specificare le proprietà, anche quelle caratteristiche, di un media

I campi opzionali sono stati indicati con il simbolo *, ed il nome dei campi è stato racchiuso tra parentesi quadre. Ovviamente ognuno dei campi definiti dal protocollo presenta una diversa organizzazione delle informazioni, anche a causa delle differenti tipologie di dati trasportati. La presentazione delle regole sintattiche e grammaticali di ogni campo si rivelerebbe un tedioso elenco di

Struttura di un messaggio SDP

13

vincoli e proprietà, e per questo motivo non viene affrontato in questo documento. Alcune di queste regole verranno rese note quando opportuno, per giustificare, e capire, le scelte progettuali adottate nella realizzazione di una libreria per la gestione del protocollo SDP. Per ottenere maggiori informazioni riguardo alla definizione di SDP, è possibile consultare la RFC 2327.

3.3 Il futuro di SDP Attualmente il protocollo SDP viene utilizzato in molti scenari applicativi, nonostante il più delle volte venga sfruttato per definire dei parametri non strettamente inerenti alla descrizione delle sessioni multimediali. Infatti SDP viene spesso utilizzato per descrivere le capacità di un sistema, provvedendo a fornire delle scelte tra un certo numero di alternative. Come noto SDP non è stato progettato per questo motivo, e per permettere la specifica di queste informazioni vengono utilizzati dei particolari accorgimenti che complicano la struttura di un messaggio. Per ovviare a questa problematica è allo studio la definizione di un nuovo protocollo, detto SDPng, Session Description and Capabilty Negotiation, per avere a disposizione uno strumento dedicato. Negli annunci di questo nuovo protocollo, la definizione delle informazioni avviene mediante dei tag XML, i quali permettono una maggiore estendibilità della tipologia dei dati trattati. Attualmente lo sviluppo della definizione di SDPng è in una fase di stallo, tant'è che non è possibile prevedere se un giorno sarà completata.

Il futuro di SDP

14

4 Stato dell'arte delle librerie SDP

In questo capitolo vengono presentate le funzionalità offerte dalle librerie SDP attualmente esistenti, per capire come venga trattata la gestione del protocollo SDP, al fine di facilitare la successiva individuazione dei requisiti della libreria jSDP.

4.1 La JSR 141 ed il progetto JAIN-SIP del NIST Poiché il protocollo SDP fornisce supporto a molte delle tecnologie alla base delle trasmissioni multicast, ed anche ai recenti tentativi di utilizzare le reti IP per la telefonia, nel Luglio del 2001 al Java Community Process è stata presentata la JSR 141, la quale pone le basi per una standardizzazione del supporto al protocollo SDP. A causa dello stretto legame tra il protocollo SIP e SDP, il NIST (National Institute of Standards and Technology) ha deciso di implementare le API proposte dalla JSR 141 nell'ambito del progetto JAIN-SIP. Osservando la documentazione delle API della JSR 141 appare subito evidente l'importanza l'interfaccia SdpFactory, la quale fornisce al programmatore tutti i metodi necessari alla codifica ed alla decodifica di un messaggio SDP. In questo modo si vuole rendere l'utente capace di sfruttare le potenzialità della libreria senza averne approfondito lo studio. Inoltre gli oggetti che permettono di gestire i singoli aspetti di un annuncio sono delle interfacce, ovvero indicano quali sono le funzionalità che devono essere offerte per poter rappresentare

La JSR 141 ed il progetto JAIN-SIP del NIST

15

correttamente un campo oppure una descrizione. Questa scelta ovviamente favorisce l'integrazione con altre implementazioni, ognuna delle quali può avere una differente struttura interna. Infatti le primitive di basso livello della libreria sviluppata dal NIST presentano delle specifiche caratteristiche, anche a causa dell'integrazione con il pacchetto software per la gestione del protocollo SIP, ma, nel contempo, garantiscono la presenza delle caratteristiche specificate dalla JSR 141. Comunque, a parte alcune scelte opinabili, le API proposte sono estremamente valide, in quanto riflettono in maniera speculare la struttura di una intestazione SDP, rendendo semplice l'utilizzo della libreria.

4.2 La libreria SDP sviluppata dalla Columbia University Il protocollo SIP, con il quale SDP collabora, è stato definito da alcuni membri della Columbia University. Per questo motivo questo ateneo è il principale produttore di componenti software per la gestione del protocollo SIP. La libreria CU JSIP è un'implementazione Java del protocollo SIP e, ovviamente, al suo interno comprende un package per la gestione del protocollo SDP. Rispetto alla JSR 141 le API di questo pacchetto risultano meno complete, poiché sembra non venga offerto in nessun modo il supporto ad alcuni campi, seppure opzionali, previsti da SDP, come il campo Phone od il campo

Information. Si ha come l'impressione che le scelte fatte in fase di progettazione abbiano favorito la creazione di una libreria che potesse risultare utile ai fini

La libreria SDP sviluppata dalla Columbia University

16

esclusivi del protocollo SIP, limitando la gestione del protocollo SDP che viene considerato come un semplice strumento, di cui non è necessario sfruttare tutte le potenzialità. Ovviamente si tratta di scelte tecniche che possono suscitare pochi consensi, ma vanno viste sotto un'ottica più ampia nella quale il protocollo SDP è, per quanto necessario, un contorno.

La libreria SDP sviluppata dalla Columbia University

17

5 Alternative software per la gestione di un protocollo

Qui vengono individuati i requisiti della libreria e vengono presentate le diverse metodologie utilizzabili per soddisfare tali requisiti.

5.1 Requisiti della libreria I requisiti funzionali di un pacchetto software per la gestione di un protocollo di rete sono molteplici, ed alcuni di essi, in particolare, influenzano fortemente svariati aspetti dello sviluppo. Questi sono

•

Affidabilità

•

Semplicità di utilizzo

•

Scalabilità

•

Modularità

e sono motivati dal delicato contesto nel quale opera il protocollo SDP. Un pacchetto software per la gestione del protocollo SDP deve essere affidabile in quanto non è ammissibile tollerare ritrasmissioni dei messaggi SDP. Simili errori possono essere causati da messaggi SDP nei quali le informazioni non sono codificate correttamente, oppure dall'errata interpretazione dei dati pervenuti. D'altra parte la libreria deve offrire al programmatore delle funzioni ad alto livello, che gli permettano di sfruttare le potenzialità del protocollo SDP senza

Requisiti della libreria

18

dover essere necessariamente a conoscenza di tutti i particolari del suo funzionamento. Queste caratteristiche devono essere integrate in un software duttile, che consenta l'interoperabilità con altri prodotti, capace di essere parte integrante di un ipotetico framework che sfrutti le tecnologie di trasmissione multicast. I requisiti tecnici sono invece dettati dalle caratteristiche necessarie ad un pacchetto software per la gestione del protocollo SDP, e vanno individuati all'interno del contesto nel quale opera il protocollo. Appare immediatamente evidente l'analogia con altri protocolli di rete, dove è indispensabile esaminare il flusso delle informazioni scambiate per decidere il comportamento da adottare. Le funzionalità che la libreria dovrà offrire sono

•

Generazione di messaggi SDP sintatticamente corretti

•

Estrapolazione di informazioni da messaggi SDP

Una volta definiti gli obiettivi resta da comprendere come arrivare al traguardo, compito non troppo arduo vista la particolare natura del problema: i risultati desiderati possono essere raggiunti mediante un'analisi lessicale e sintattica degli elementi che intervengono in un messaggio SDP. A questo punto è possibile dedicarsi alla progettazione del software, per determinare i metodi da utilizzare per soddisfare i requisiti individuati. Nel seguito verranno dunque analizzati i paradigmi che offrono delle soluzioni ai

Requisiti della libreria

19

problemi sollevati dalla specifica delle caratteristiche della libreria, mettendo in evidenza vantaggi e svantaggi di ciascuna di queste tecniche.

5.2 Utilizzo di parser specializzati La struttura lineare di un messaggio SDP fornisce immediatamente una serie di spunti per effettuare il parsing. Infatti poiché un'intestazione SDP è composta da una serie di linee, ognuna delle quali rappresenta un campo, si potrebbe suddividere l'operazione di parsing in diverse procedure, tante quanti sono gli identificatori di un campo SDP. Questo equivale a realizzare un insieme di parser specializzati, ognuno dei quali è in grado di controllare la regolarità delle informazioni contenute in uno specifico campo SDP Linea di un messaggio SDP

Individuazione dell'identificatore del campo SDP

Valutazione del campo mediante un parser specializzato

Informazioni estratte dal campo SDP Utilizzo di parser specializzati

20

Apparentemente questa soluzione sembra essere semplice ma efficace allo stesso tempo. In realtà purtroppo un sistema di questo tipo non svolge adeguatamente il suo compito, in quanto non è in grado di verificare la correttezza sintattica di un messaggio SDP. La validità delle singole informazioni contenute in uno o più campi non è infatti sufficiente per poter affermare che un messaggio SDP è privo di errori : affinché le informazioni trasportate da un'intestazione SDP siano utilizzabili, queste devono essere fornite secondo i criteri specificati dal protocollo. Osserviamo il seguente messaggio SDP

v=0 o=alice 2890844526 2890844526 IN IP4 host.example.com s=SDP message example t=0 0 m=audio 49170 RTP/AVP 0 8 97 c=IN IP4 source.example.com m=video 51372 RTP/AVP 31 32

È chiaro che si tratto di un messaggio non corretto, in quanto l'assenza di un campo Connection nella descrizione della sessione implica la presenza di questo campo in ognuna delle descrizioni dei media. Utilizzando il metodo descritto in precedenza questo messaggio verrebbe considerato valido, perché tutti i campi presenti sono corretti dal punto di visto grammaticale e sintattico, anche se nell'insieme il messaggio non lo è perché fornisce delle informazioni non utilizzabili : non è possibile identificare la sorgente del secondo flusso di dati,

Utilizzo di parser specializzati

21

quello video. Quindi sebbene l'introduzione di un parser specializzato per ognuno dei campi specificati dal protocollo SDP favorisca la modularità dei componenti software, mediante una ben definita assegnazione delle responsabilità, non è possibile utilizzare un simile approccio, in quanto verrebbe meno l'affidabilità della libreria. Inoltre per fornire supporto alla generazione dei messaggi SDP, al momento della creazione di un campo SDP bisognerebbe utilizzare il parser corrispondente per testarne la correttezza. Un'ipotesi sicuramente plausibile ma di scarsa efficacia, poiché ad ogni modifica delle informazioni contenute nel campo si avrebbe l'esigenza di validare nuovamente l'intero campo, con rilevanti conseguenze dal punto di vista dell'efficienza. Inoltre anche in questo caso si ripresenterebbe il problema della correttezza sintattica dell'annuncio, poiché adottando questa tecnica non è possibile verificarla in alcun modo.

5.3 Costruzione di un albero rappresentante il messaggio La valutazione della correttezza di un messaggio SDP, può essere affrontata come la necessità di generare un albero contenente le informazioni incapsulate nell'intestazione SDP. In questo caso ogni campo viene rappresentato univocamente da un nodo dell'albero, la cui radice corrisponde al primo campo presente nell'annuncio, e, nel caso in cui le informazioni siano valide, per ricostruire il messaggio basterà seguire il percorso che va dalla radice sino alla foglia di profondità massima.

Costruzione di un albero rappresentante il messaggio

22

Il rigore sintattico è garantito dall'introduzione di alcuni vincoli, che sono realizzati imponendo la presenza di determinati campi in particolari sequenze oppure solo ad alcuni livelli. Di conseguenza l'analisi lessicale e sintattica di un messaggio SDP avviene mediante l'esplorazione di un albero con la seguente struttura

v=.......

o=.......

s=.......

i=.....*

u=.....*

e=.....*

u=.....*

e=.....*

p=.....*

p=.....*

c=.....*

e=.....*

p=.....*

c=.....*

p=.....*

c=.....*

b=.....*

* Campo opzionale

Costruzione di un albero rappresentante il messaggio

23

Nonostante l'albero rappresentato sia largamente incompleto, appare evidente il principale motivo per il quale questa tecnica non è utilizzabile. Sono stati sviluppati solamente 6 livelli, mentre un messaggio SDP può generare un albero di oltre 20 livelli poiché la profondità dell'albero dipende dalla quantità di informazioni trasportate dall'intestazione SDP. Tralasciando momentaneamente le difficoltà causate dall'esigenza di dover elaborare una simile mole di dati, è interessante notare che un simile dispendio computazionale non è giustificato in alcun modo. Un albero di questo tipo è composto da elevatissimo numero di sottoalberi uguali, e riflette una situazione reale: esistono infiniti messaggi SDP rappresentati dalla stessa sequenza di campi, e la probabilità che due messaggi differiscano di un solo campo è elevatissima. Affinché una struttura del genere sia utilizzabile per ottenere risultati soddisfacenti, bisognerebbe essere in grado di effettuare delle potature a determinati livelli dell'albero in modo tale da escludere alcuni nodi e, di conseguenza, i sottoalberi da essi generati. Purtroppo questo non è possibile a causa della natura stessa del protocollo SDP, che prevede diversi campi opzionali dando così luogo un insieme piuttosto vasto di sintassi corrette per un messaggio SDP. Bisogna inoltre considerare la complessità dovuta alla eventuale presenza di una serie di campi della stessa tipologia, evento piuttosto frequente soprattutto con il campo Attribute nella descrizione dei media, che introduce dei cicli all'interno dell'albero. Naturalmente anche in questo caso la generazione di un messaggio SDP non è

Costruzione di un albero rappresentante il messaggio

24

supportata adeguatamente: prima bisogna creare un annuncio SDP ed in seguito deve esserne verificata la correttezza, un'operazione che deve essere ripetuta ad ogni modifica effettuata nel messaggio. Infine bisogna aggiungere che questa tecnica risulta proibitiva anche dal punto di vista implementativo, in quanto la sua realizzazione richiederebbe migliaia di righe di codice, senza avere la benché minima possibilità di automatizzare il processo. Quindi, sebbene dal punto di vista teorico la metodologia presentata garantisce la correttezza dell'analisi lessicale e sintattica di un messaggio SDP, non è possibile applicare tale soluzione.

5.4 Specifica di una grammatica context-free Un compilatore è lo strumento attraverso il quale si stabilisce se una frase di un linguaggio di programmazione sia corretta o meno, e se è corretta, qual è il suo significato, ovvero la sua semantica. Pertanto è possibile affermare che un compilatore implementa la definizione di un linguaggio di programmazione. Per realizzare tale caratteristica, la ricerca sui compilatori ha dovuto dotarsi di diversi strumenti, i quali sono stati trovati all'interno della teoria dei linguaggi formali e del parsing. Se si esclude l'analisi semantica che, nel caso del protocollo SDP, poiché non si tratta di un linguaggio di programmazione, non è necessaria, per effettuare il parsing di un'intestazione SDP è possibile utilizzare parte delle tecniche adottate dai compilatori. Infatti tra un linguaggio di programmazione ed i principi lessicali

Specifica di una grammatica context-free

25

e sintattici definiti dal protocollo SDP intercorre una forte analogia: ambedue possono essere formalizzati come grammatiche context-free. Nel passato l'espressività di questa tipologia di grammatica si è rivelata molto utile nella descrizione dei linguaggi formali, una caratteristica che l'ha resa un valido strumento di supporto nella realizzazione di software per la valutazione lessicale, sintattica e, talvolta, semantica di questi linguaggi. Per questo motivo sono stati effettuati diversi studi per mettere a punto dei tool che generassero automaticamente un parser per un determinato linguaggio, sulla base delle regole espresse mediante una grammatica context-free. Attualmente esistono diversi strumenti di questo genere, che vengono spesso denominati “compilatori di compilatori”, ognuno dei quali, utilizzando tecniche più o meno raffinate, produce un parser per uno specifico linguaggio. Per quanto riguarda la tecnologia Java, lo strumento più avanzato ed efficiente è senza dubbio JavaCC, acronimo di Java Compiler Compiler, il quale è in grado di generare dei parser top-down permettendo all'utente di modificare una serie di parametri per influenzare alcune proprietà del codice generato, come ad esempio il comportamento da adottare nel caso vengano riscontrate delle ambiguità. Sulla base delle istruzioni indicate JavaCC produce alcuni oggetti, tra cui

•

Il parser per la grammatica specificata

•

Un analizzatore lessicale, detto anche gestore dei token. Il gestore dei token analizza il flusso dei caratteri

Specifica di una grammatica context-free

26

in ingresso e li suddivide in spezzoni chiamati token, assegnando ad ognuno di essi una tipologia. La sequenza di token prodotti dall'analizzatore lessicale si basa

sulle

espressioni

regolari

specificate

nella

grammatica trattata •

Una tabella dei simboli che mette in relazione i token con le costanti e le espressioni della grammatica

Una volta presa coscienza della possibilità di utilizzare le peculiarità di JavaCC, rimane da capire come queste possano risultare utili per sviluppare una libreria per la gestione del protocollo SDP. Dal punto di vista dei risultati questo metodo è senza dubbio il migliore tra quelli visti sinora: specificando correttamente le regole grammaticali si ottiene un parser che in grado di valutare efficacemente un messaggio SDP, per poi, mediante alcuni accorgimenti, rendere disponibili le informazioni estrapolate. Purtroppo anche sfruttando le potenzialità di JavaCC il problema della generazione degli annunci SDP rimane di difficile soluzione. Il parser generato infatti è in grado di analizzare un'intestazione SDP completa, mentre non è in grado di prendere in considerazione un singolo campo SDP oppure un singolo elemento di quest'ultimo. Per ottenere delle prestazioni elevate, la creazione di un messaggio SDP deve essere controllata passo per passo, in modo tale da facilitare la gestione degli errori. L'inserimento e la modifica di ogni elemento di un annuncio SDP devono poter essere valutati

Specifica di una grammatica context-free

27

immediatamente: questo non è possibile utilizzando l'approccio descritto in precedenza. Per ovviare a questo inconveniente è possibile assegnare diversamente alcune responsabilità software, spostando il controllo delle informazioni inserite all'interno degli oggetti che dovranno incapsulare i dati relativi ad un campo SDP. Ma una simile operazione comporta degli effetti collaterali notevoli, a causa della ridondanza di controlli che viene effettuata sugli elementi che compongono un messaggio SDP. Infatti, nel corso dell'analisi lessicale e sintattica dell'annuncio SDP, quando il parser identifica una produzione come appartenente alla grammatica passa le informazioni che ha estrapolato all'oggetto che rappresenta il campo SDP che è stato individuato. Durante la creazione di questo oggetto però, i dati che sono stati estratti dal parser vengono analizzati nuovamente, a causa dei metodi che sono stati introdotti per ottimizzare la creazione di un annuncio SDP. Ovviamente questa situazione si verifica per ogni campo presente nel messaggio, e raddoppia il tempo necessario ad effettuare il parsing. In conclusione l'utilizzo di uno strumento per la generazione automatica di un parser, corredato da accorgimenti tecnici più o meno validi, rappresenta senza dubbio un'alternativa plausibile per la realizzazione di una libreria per la gestione del protocollo SDP, nonostante risulti deficitaria sotto alcuni aspetti.

5.5 Considerazioni sulle tecniche proposte Nessuna delle tecniche viste in precedenza è completamente soddisfacente,

Considerazioni sulle tecniche proposte

28

ognuna di esse presenta dei limiti, più o meno gravi. Alcune riescono a garantire solamente alcune delle funzionalità richieste, altre sono difficilmente realizzabili oppure scarsamente efficienti. Nella tabella sottostante sono riassunti brevemente i pregi ed i difetti di ciascuna delle metodologie illustrate

Tecnica

Vantaggi

Svantaggi

Utilizzo di parser specializzati

Modularità, Correttezza sintattica di ogni singolo campo

Analisi sintattica del messaggio non realizzabile

Costruzione di un albero rappresentate il messaggio

Correttezza sintattica di un messaggio

Costi computazionali elevatissimi

Specifica di una grammatica context-free

Generazione automatica del parser, corretta valutazione di un messaggio SDP

Scarsa efficienza nella costruzione di un messaggio

Ciascuna di esse presenta diverse caratteristiche che enfatizzano un particolare aspetto delle funzionalità che deve offrire la libreria, ed offre spunti interessanti per delle riflessioni. L'utilizzo di parser specializzati garantisce una suddivisione delle responsabilità profondamente radicata e riduce la complessità dell'analisi lessicale sezionando la grammatica del protocollo SDP in piccole parti, ognuna delle quali può essere valutata da componenti ottimizzati per ogni sottoinsieme. D'altra parte immaginare che le possibili combinazioni di un messaggio SDP siano rappresentabili mediante un albero binario, assicura il rigore necessario per Considerazioni sulle tecniche proposte

29

effettuare una valutazione sintattica priva di qualunque ambiguità, nonostante l'impossibilità di intuire la possibile struttura dell'annuncio SDP in modo tale da potare i rami dell'albero che non rappresentano una soluzione. Questi aspetti, insieme alla possibilità di generare automaticamente il parser per la grammatica del protocollo SDP grazie all'utilizzo di JavaCC, aiutano a delineare alcune delle tecnologie di cui deve essere in possesso un pacchetto software per una gestione efficace del protocollo SDP. Nel prossimo capitolo verrà discusso come sfruttare al meglio i risultati acquisiti, in modo tale da raggiungere gli obiettivi prefissati.

Considerazioni sulle tecniche proposte

30

6 La libreria jSDP

Nelle pagine che seguono vengono illustrate, passo dopo passo, le scelte che sono state fatte nella progettazione e nello sviluppo della libreria jSDP.

6.1 Architettura preliminare della libreria Per realizzare un pacchetto software capace di manipolare messaggi SDP, bisogna capire quali sono gli elementi alla base del protocollo. Come descritto in precedenza un messaggio SDP è formato da un insieme di campi, ciascuno dei quali è rappresentato da un identificatore, che contengono una serie di informazioni. Quindi un'architettura preposta alla gestione di questo protocollo deve associare ad ognuno dei campi SDP un oggetto software che lo rappresenta, tenendo conto che un qualunque campo, che ha la forma =, altri non è che la specializzazione del generico campo di un messaggio

=

v= a=<proprietà del messaggio>

s=<nome della sessione> ...=

Architettura preliminare della libreria

31

In questo modo da ogni campo sarà possibile ottenere tutte le informazioni trasportate, oppure solamente una porzione. Inoltre ogni campo deve essere in grado di formattare correttamente tutti i dati che incapsula, rendendoli così immediatamente fruibili, senza alcun passaggio intermedio. Espandendo questo concetto, si giunge alla conclusione che nota la sintassi di un'ipotetica sequenza di campi, la sua rappresentazione può essere facilmente generata in quanto

1. Ogni campo è formattato correttamente 2. È noto l'ordine con il quale i campi devono susseguirsi

Chiaramente essendo, come noto, un messaggio SDP una successione di campi, imponendo questi vincoli la creazione di un annuncio è rapida e corretta. La verifica delle informazioni trattate da un campo è quindi un punto cruciale per usufruire dei benefici descritti, e sarà descritta nel paragrafo successivo. Naturalmente non è conveniente rappresentare un messaggio SDP in una struttura monolitica, piuttosto è preferibile rispettare, almeno in parte, la gerarchia definita dalla RFC 2327. Di conseguenza bisogna considerare l'ipotesi di rappresentare anche le descrizioni come oggetti software, anche se per effettuare questa scelta è necessario che la progettazione raggiunga uno stato più avanzato. In questo momento non è ancora possibile capire con certezza quale approccio utilizzare per effettuare il parsing di un messaggio SDP, in quanto bisogna

Architettura preliminare della libreria

32

valutare l'impatto delle decisioni che verrano prese per permettere ai componenti software che gestiscono i campi SDP di valutare la correttezza delle informazioni trattate, ovvero bisogna determinare se e come questi metodi possono interagire tra di loro per rendere possibile l'analisi lessicale e sintattica di un messaggio.

6.2 L'introduzione delle espressioni regolari Per semplificare notevolmente la creazione di un messaggio SDP è di fondamentale importanza l'utilizzo di componenti specializzati, quindi ciascuno degli oggetti che gestisce un campo SDP deve essere in grado di valutare se una stringa di caratteri rappresenta un elemento ammissibile. Per capire esattamente quale deve essere il comportamento di tali oggetti, bisogna immaginare alcune situazioni potenziali, ad esempio

1. Specifica di un id della sessione nel campo Origin 2. Specifica di un indirizzo e-mail nel campo Email

Tenendo presente che il tentativo di inserire informazioni non valide, deve sollevare un'eccezione. Il primo caso è banale, in quanto l'id di una sessione è un numero intero e, anche se nella definizione del protocollo SDP viene consigliato di utilizzare un timestamp NTP (Network Time Protocol) per garantirne l'univocità, è sufficiente controllare che il numero specificato sia

L'introduzione delle espressioni regolari

33

maggiore od uguale a zero. Sfortunatamente però la quasi totalità dei dati trasportati da SDP è rappresentata da stringhe di caratteri, e non da numeri. Solitamente le circostanze sono simili a quelle che si presentano nel secondo caso, in cui le informazioni trasportate possono assumere diversi valori nonostante debbano rispettare rigide regole sintattiche ed alcune restrizioni sull'insieme dei caratteri utilizzabili. Quindi la complessità della grammatica della maggior parte dei dati che intervengono in un messaggio SDP, rappresenta il principale ostacolo alla loro valutazione. Ma poiché ciascuno di questi elementi deve, come detto, seguire precisi principi lessicali e sintattici, per analizzarli è possibile sfruttare delle espressioni regolari. L'utilizzo di queste espressioni permette di capire se una stringa verifica o meno determinate caratteristiche, utilizzando una maschera (detta anche pattern) che le descriva. Facendo attenzione alla sintassi da utilizzare per specificare un pattern è possibile valutarlo in maniera rapida ed efficace. Si supponga di voler controllare che una stringa sia composta esclusivamente dalle lettere dell'alfabeto

•

Il pattern da utilizzare è [a-zA-Z]

•

La stringa titto risponde alle caratteristiche specificate dalla maschera

•

La stringa Roma3 non soddisfa il pattern, perché contiene un numero

L'introduzione delle espressioni regolari

34

Chiaramente è possibile specificare anche pattern più complessi, in modo tale da soddisfare le proprie esigenze. Le espressioni regolari sono quindi uno strumento molto potente e versatile, che risulta fondamentale per implementare le scelte che sono state fatte. Quindi gli oggetti software che rappresentano i campi SDP, valuteranno la validità delle informazioni trattate mediante delle espressioni regolari, che risulteranno più o meno articolate a seconda della loro complessità.

6.3 Il parsing di un campo SDP L'introduzione delle espressioni regolari fornisce notevoli potenzialità agli oggetti che memorizzano le informazioni trasportate da un campo SDP, permettendogli di valutare se determinate stringhe sono ammissibili per un particolare elemento. Nonostante questo però non sono in grado di effettuare il parsing di un campo SDP, perché non ne conoscono la sintassi: una situazione simile a quella ipotizzata nell'illustrare una tecnica per la valutazione di un messaggio SDP utilizzando dei parser specializzati per ogni campo. Il problema è quindi sceso ad un livello inferiore, perché nel caso precedente i parser potevano verificare la correttezza, sia lessicale che sintattica, di un singolo campo, ma non erano capaci di trattare un messaggio SDP, mentre le scelte effettuate nel precedente paragrafo permettono ad un oggetto che rappresenta un campo SDP di valutare solamente l'ammissibilità degli elementi che intervengono all'interno del campo stesso.

Il parsing di un campo SDP

35

Quindi per effettuare il parsing di un campo SDP è necessario introdurre un componente che sia a conoscenza della sua sintassi: ogni campo avrà un proprio parser. Rimane però da individuare lo schema secondo il quale procederà la valutazione di un campo. Ovviamente il primo elemento ad essere analizzato sarà l'identificatore del campo. Se questo risulterà differente da quello richiesto, la procedura di parsing verrà interrotta perché la stringa analizzata non rappresenta il campo atteso. Diversa è invece la valutazione delle informazioni trasportate dal campo, che deve prevedere l'utilizzo delle capacità in possesso agli oggetti software che rappresentano i campi. Riprendendo in parte il concetto dell'analizzatore lessicale visto nel capitolo precedente, il parser di un campo SDP deve essere in grado di analizzare il flusso delle informazioni in ingresso, sfruttando le nozioni sintattiche di cui è a conoscenza. Andiamo ad analizzare il comportamento che dovrà adottare il parser del campo Origin nell'analizzare la seguente stringa

•

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

L'identificatore è corretto quindi il parser può procedere con l'analisi dei dati trasportati dal campo. Il parser non è in grado di stabilire se il primo elemento estratto rappresenta un valore ammissibile, ma sa che dovrebbe rappresentare il nome dell'utente che ha creato il messaggio, quindi fornisce questa informazione all'oggetto che gestisce il campo Origin. La medesima situazione si verifica per ognuno degli elementi estrapolati: il parser determina la tipologia Il parsing di un campo SDP

36

dell'informazione (nome della sessione, sorgente della trasmissione, ecc.) e la fornisce al componente software che gestisce il campo, il quale ne valuta l'ammissibilità. Se questa è verificata per tutte le stringhe estratte viene creato l'oggetto che rappresenta il campo, che naturalmente conterrà al suo interno i dati individuati. Ovviamente in caso contrario la procedura di parsing fallirà e verrà sollevata una eccezione. Chiaramente in questo modo è possibile costruire un parser efficiente per ognuno dei campi SDP, senza introdurre alcuna ridondanza nei controlli effettuati per assicurare la correttezza delle informazioni. Questa scelta però sembra presentare gli stessi limiti della tecnica che prevede l'utilizzo di parser specializzati, in quanto tra le due soluzioni esistono diverse analogie. Nei prossimi paragrafi verrà dimostrato come le caratteristiche appena introdotte, se supportate da alcuni accorgimenti tecnici, consentono di ottenere agevolmente gli scopi prefissati.

6.4 Creazione di un messaggio Le decisioni prese durante le precedenti fasi della progettazione, permettono di effettuare correttamente sia la creazione che l'analisi lessicale e sintattica di un campo SDP. Il prossimo passo servirà a specificare come sfruttare le caratteristiche introdotte sinora per generare dei messaggi SDP validi, ricordando

le motivazioni che hanno suggerito la realizzazione di tali

funzionalità. Un annuncio SDP è composto da una serie di campi: avere la

Creazione di un messaggio

37

certezza che ognuno di questi è corretto, sia grammaticalmente che sintatticamente, semplifica notevolmente la costruzione di un messaggio. Per creare una intestazione SDP è possibile prevedere l'utilizzo di un particolare oggetto, in grado di contenere al suo interno i campi che dovranno essere presenti nel messaggio da generare. Di conseguenza questo oggetto deve essere capace di organizzare i campi che racchiude, in modo tale da disporre correttamente le informazioni che devono essere trasportate da un messaggio. Immaginiamo il susseguirsi delle operazioni per generare il seguente annuncio SDP

v=0 o=test 2108874561 2108874562 IN IP4 source.example.com s=SDP test c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49172 RTP/AVP 0

Ovviamente per prima cosa verranno creati i campi SDP che intervengono nel messaggio, per poi passare all'inserimento di quest'ultimi all'interno dell'oggetto che dovrà rappresentare l'intestazione. In seguito, alla richiesta della creazione del messaggio, questo particolare contenitore fornirà i dati immagazzinati seguendo la sintassi definita dal protocollo SDP. Sebbene i risultati conseguiti mediante questa scelta tecnica sembrino soddisfacenti, nel prossimo paragrafo verrà considerata l'ipotesi di suddividere ulteriormente le responsabilità, così come avviene nella RFC 2327 nella quale Creazione di un messaggio

38

un annuncio SDP viene ripartito in tre elementi. L'analisi di situazioni differenti da quella appena vista servirà a confrontare le due implementazioni, al fine di determinare quale di esse è maggiormente performante.

6.5 Rappresentazione delle descrizioni Se l'annuncio SDP da creare è particolarmente articolato, situazione, tra l'altro, molto frequente, l'utilizzo di un solo oggetto dedicato alla rappresentazione del messaggio può rappresentare un serio problema. È il caso di una intestazione che prevede la descrizione di due o più media, nel quale l'oggetto ipotizzato non è in grado di determinare a quale elemento si riferiscono determinate informazioni. Si supponga di dover tratta il messaggio sottostante

v=0 o=test 2308874151 2308874522 IN IP4 source.example.com s=Another SDP test t=0 0 m=audio 49172 RTP/AVP 0 m=audio 49170 RTP/AVP 98

Chiaramente questi dati non permettono ai destinatari dell'annuncio di prendere parte alla sessione multimediale, perché non specificano la fonte delle trasmissioni. Deve quindi essere aggiunto almeno un campo Connection, ma questo comporta delle difficoltà nell'inserimento. Supponendo che la sorgente delle comunicazioni sia univoca, basterà aggiungere il campo Connection nella

Rappresentazione delle descrizioni

39

descrizione della sessione, ma l'oggetto che rappresenta il messaggio SDP non è capace di portare a termine questa operazione in quanto non effettua alcuna distinzione tra le varie parti di un annuncio. Una distinzione che non sarebbe necessaria se la descrizione dei media fosse un semplice campo, anziché un insieme nel quale ne intervengono diversi. In prima analisi si potrebbe pensare alla specifica di un metodo apposito per l'inserimento del campo Connection nel livello di sessione, in modo tale da poter comunque indicare la fonte delle trasmissioni condivisa da tutti i media annunciati nel messaggio. In realtà questo accorgimento non porta nessun beneficio reale, in quanto se le sorgenti delle comunicazioni sono differenti il campo Connection deve essere specificato per ognuno dei media trasmessi. Questo porterebbe all'introduzione di un ulteriore metodo per inserire un campo

Connection in una particolare descrizione dei media, con serie ripercussioni sull'usabilità del componente, anche a causa delle difficoltà di determinare il media al quale si fa riferimento. Osservando un messaggio seguente è facile intuire che un approccio simile darebbe luogo ad una serie di scatole cinesi

v=0 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49172 RTP/AVP 97 b=AS:12 a=rtpmap:97 iLBC Rappresentazione delle descrizioni

40

a=sendonly m=audio 49174 RTP/AVP 98 c=IN IP4 audio.source.example.com b=AS:60 a=rtpmap:98 telephone-event a=recvonly m=application 32416 udp wb k=prompt b=AS:48

Il problema esposto poc'anzi per il campo Connection, che in questo messaggio si trova a livello di sessione quindi è sufficiente ad identificare tutte le sorgenti di trasmissione, si ripresenta per ognuno dei campi SDP che compaiono sia nella descrizione della sessione che nelle descrizioni dei media. A questo punto appare evidente la pochezza tecnologica di una soluzione che rappresenta un messaggio SDP mediante un singolo oggetto. Per garantire la semplicità d'uso della libreria, è indispensabile che ognuna delle descrizioni definite dal protocollo SDP (descrizione della sessione, dell'attività e dei media) venga gestita da un oggetto distinto. La rappresentazione di un annuncio avverrà mediante la descrizione di una sessione, la quale dovrà essere corredata dalla descrizione dell'attività: l'eventuale presenza di uno o più media nella trasmissione verrà formalizzata mediante l'introduzione della sua descrizione all'interno del messaggio. In questo modo è possibile interagire con ciascuno degli elementi di una intestazione, manipolandoli agevolmente senza possibilità di equivoco. Naturalmente la creazione di un messaggio seguirà il

Rappresentazione delle descrizioni

41

principio proposto precedentemente, per cui ciascuna delle descrizioni si occuperà autonomamente di fornire, seguendo la sintassi appropriata, le informazioni che gestisce. La modularizzazione di questi componenti favorisce quindi la separazione degli interessi, lasciando però inalterata l'efficienza della procedura di creazione di una intestazione SDP.

6.6 Valutazione del messaggio Avendo definito con chiarezza le strutture preposte alla rappresentazione di un messaggio SDP, rimane da chiarire come sfruttarle per specificare la tecnica da utilizzare per effettuare la valutazione di un annuncio. Le scelte illustrate in precedenza seguono alcune delle principali indicazioni della RFC 2327, ma, soprattutto, garantiscono un supporto estremamente efficiente ad alcune delle funzionalità prioritarie della libreria

•

Parsing di un campo SDP

•

Creazione di un messaggio SDP sintatticamente corretto

Il percorso che ha portato a questi risultati prende spunto da alcuni concetti alla base della metodologia che prevede l'impiego di parser specializzati, idee che sono state poi ampliate e modificate in modo tale da creare delle situazioni favorevoli al loro utilizzo. Infatti le problematiche legate all'efficienza causate dalla necessità di dover analizzare interamente il campo dopo ogni modifica,

Valutazione del messaggio

42

seppure minima, sono state aggirate mediante l'introduzione delle espressioni regolari che consentono di valutare agevolmente solamente le porzioni modificate del campo, grazie alla specifica del lessico per ognuno degli elementi coinvolti. Quindi sfruttando i esclusivamente i punti di forza di una tecnica imperfetta, è stato possibile realizzare alcune delle peculiarità richieste alla libreria. Ora è indispensabile che la progettazione prosegua ulteriormente, fornendo le indicazioni necessarie a realizzare l'ultima, ma non per questo meno importante, caratteristica individuata dai requisiti specificati durante le prime considerazioni, ovvero la valutazione di un messaggio SDP. Per la realizzazione di questo strumento, verranno utilizzati, anche in questo caso, le qualità migliori di un metodo che, nel complesso, non è completo. Il tentativo di descrivere un messaggio SDP mediante una struttura ad albero si è dimostrata una possibilità prettamente teorica, in quanto la sua complessità computazionale risulta elevatissima. Questo però non deve porre in secondo piano le potenzialità di tale metodo, la cui efficacia permetterebbe di valutare con semplicità e rigore la sintassi di un messaggio, seguendo fedelmente le specifiche imposte dal protocollo SDP. Se si vogliono sfruttare in qualche modo esclusivamente i vantaggi di questo approccio, è necessario introdurre degli accorgimenti per ridurre, tra l'altro anche notevolmente, la ramificazione e la profondità di questo albero. L'esplorazione di questa struttura è infatti resa proibitiva dall'altissimo numero di nodi di cui è composta, e, tra l'altro, al suo interno contiene diversi sottoalberi equivalenti. Purtroppo mantenendo una

Valutazione del messaggio

43

visione che prevede i campi SDP come nodi non è possibile semplificare in alcun maniera l'albero, perché non è possibile predire la sequenza dei campi che compongono un annuncio. Risulta quindi necessario stravolgere completamente questa struttura, modificandone radicalmente il punto di vista. Per questo motivo occorre imperniare il discorso sulle occorrenze di un campo, piuttosto che sulla sua tipologia. In questo modo, per ogni campo SDP, si avrebbe un'architettura estremamente semplice, quasi banale

Occorrenze di campo SDP

Nessuna occorrenza

Una sola occorrenza

Una o più occorrenze

Chiaramente trattare una struttura del genere non comporta nessuna difficoltà, solo che allo stato attuale, senza l'integrazione di qualche altro procedimento, questo sistema è completamente inutile in quanto non offre nessuna reale funzionalità. Prima di tutto è indispensabile capire quali sono i vantaggi che potrebbe portare un simile approccio, quindi è necessario specificare che non si è fatto riferimento alle effettive occorrenze di un campo in un messaggio SDP, ma al numero possibile, inteso come ammesso dal protocollo, di elementi con lo stesso identificatore. Naturalmente questo serve a determinare se un campo è

Valutazione del messaggio

44

richiesto o meno, oppure se prevede più occorrenze. Ad esempio il campo

Version deve essere presente solamente una volta, per cui è obbligatorio, mentre il campo Information può anche non far parte di un messaggio (ma può comparire al massimo una volta). Le occorrenze sono uno dei vincoli sintattici alla base del protocollo SDP, ed in questo modo è possibile esprimerle e valutarle. Introdotte in una procedura di parsing, aiutano a stabilire se la presenza, oppure la mancanza, di uno specifico campo rappresenta o meno una violazione delle regole del protocollo e, di conseguenza, un errore, come nel caso seguente

v=0 o=claire 2105842594 2105842597 IN IP4 host.example.com s=SDP protocol test i=Some information about this message i=Extra info about this message t=0 0

Il campo Information è opzionale, quindi i dati che trasporta non sono assolutamente indispensabili, ma, tuttavia, si tratta di informazioni che possono aiutare a comprendere lo scopo della sessione multimediale. Le indicazioni fornite dalla conoscenza delle occorrenze di un campo, aiutano ad individuare immediatamente l'errore dell'annuncio: il campo Information, come detto, può essere presente al più una volta. La valutazione delle occorrenze di un campo è dunque un mezzo molto potente,

Valutazione del messaggio

45

che però, per poter essere fruibile, deve essere utilizzato parallelamente ad una tecnica che permette di valutare altri aspetti sintattici del protocollo SDP. Infatti rimane da stabilire come testare la sequenza dei campi che intervengono in un messaggio, in modo tale da poter portare a termine il parsing di un annuncio. Sicuramente il metodo maggiormente efficace per valutare la sequenza dei campi presenti in una intestazione SDP, consiste nell'inserimento del controllo delle occorrenze di un campo all'interno di un ciclo. Naturalmente questo ciclo deve prevedere altre operazioni, perché oltre alla sintassi del messaggio deve essere verificata la validità dei campi. Di conseguenza si avrà la seguente successione delle operazioni

1. Estrazione di una linea dal messaggio SDP 2. Identificazione del campo 3. Parsing del campo 4. Valutazione delle occorrenze

A dire il vero neanche questa procedura consente di valutare la correttezza di un messaggio, perché effettuare l'identificazione del campo, per poi eseguirne il parsing, non garantisce affatto che la sequenza dei campi sia ammissibile. L'unica soluzione possibile è quella di delineare rigidamente il percorso che deve essere seguito da un annuncio SDP, affinché possa essere definito corretto. Occorre quindi specificare in precedenza la successione dei campi, in modo tale

Valutazione del messaggio

46

che la linea nesima rappresenti il campo previsto nella sequenza: se queste corrispondenze sono verificate, allora il messaggio è corretto. Non sarà più necessario identificare la tipologia del campo per analizzarlo, in quanto questa sarà nota a priori, permettendo di selezionare il parser appropriato. L'ammissione di queste condizioni consente l'immediata rilevazione degli eventuali errori, ed una efficace valutazione del messaggio. Illustriamo brevemente come avviene la valutazione di un annuncio. La linea estratta viene sottoposta all'analisi del parser del campo atteso, che ovviamente può dare esito negativo oppure positivo. A questo punto entra in gioco il controllo delle occorrenze: se il parsing è fallito ma il campo risulta essere opzionale, non viene sollevata alcuna eccezione. Invece se il campo è richiesto ed il parsing è stato interrotto viene riscontrato un errore, in quanto non è stata rispetta la sintassi del protocollo SDP. Se il parsing di un campo procede senza problemi, è possibile affermare con certezza che, per quanto riguarda la porzione sinora esaminata, il messaggio non contiene errori. Naturalmente tutto questo è possibile grazie alla conoscenza delle occorrenze di un campo, che permette di determinare il numero di linee che devono essere analizzate dal medesimo parser. Prendiamo come esempio l'analisi di un campo RepeatTime, il quale è opzionale ma prevede un numero imprecisato di occorrenze, immaginando di averne appena individuato uno durante la valutazione dell'annuncio. Anche la prossima linea estratta verrà analizzata dal medesimo parser: se verrà individuato un campo differente da quello atteso la procedura

Valutazione del messaggio

47

di parsing del campo fallirà, e la linea verrà analizzata dal parser del campo successivo. Viceversa anche la linea successiva sarà processata dal parser del campo RepeatTime, sino a quando non si verificheranno errori. Appare chiaro che questo metodo permette di effettuare senza alcun problema una efficace valutazione lessicale e sintattica di una intestazione SDP, completando le funzionalità della libreria così come richiesto dalle specifiche, nonostante alcuni aspetti siano ancora da definire. In particolare rimangono oscuri dei dettagli relativi alla specifica della sequenza dei campi. Un annuncio SDP è una successione di campi, ma alcuni di essi possono intervenire in disparate parti di un messaggio, e ciascuna di queste parti può prevedere diverse occorrenze. È il caso della descrizione dei media che è definita come successione di diversi campi, la maggior parte dei quali può essere presente anche nella descrizione della sessione. Indicando solamente la sequenza dei campi, non è possibile gestire messaggi con più di una descrizione dei media. Infatti dopo aver analizzato l'ultimo campo Attribute della prima descrizione dei media, viene sollevata una eccezione in quanto il campo Media della seconda descrizione non può essere validato dal parser del campo Attribute. Questo accade perché, con la metodologia illustrata, non è possibile fare backtracking nella ricorsione. Per aggirare questo fastidioso ostacolo bisogna introdurre una astrazione software, che ovviamente non è presente nella RFC 2327. È necessario immaginare che un messaggio SDP sia composto da una successione di diverse tipologie di un generico elemento, e che ognuno di questi elementi

Valutazione del messaggio

48

possa avere un determinato numero di occorrenze. Sia i campi che le descrizioni (che sono un insieme di campi), devono derivare entrambi da questo generico elemento. Questo consente di mantenere immutata la struttura del ciclo (basata, come noto, sul numero di occorrenze), ma permette di trattare una descrizione come se fosse un normale campo. A questo punto potendo diversificare il comportamento da adottare, a seconda della descrizione è possibile specificare una differente sequenza dei campi. Chiaramente la successione degli elementi in un descrizione, può comprendere, oltre ai campi, un'altra descrizione. È per questo motivo che è possibile valutare la correttezza di un messaggio SDP: la sequenza che verifica la descrizione della sessione, comprende, tra le altre cose, la descrizione delle attività (con una sola occorrenza, seppure obbligatoria) e la descrizione dei media, che non è richiesta ma può essere presente un numero indefinito di volte. Quando l'analisi della descrizione della sessione prevede la presenza di una descrizione delle attività, il processo entra in una particolare ramificazione nella quale la serie dei campi attesi è differente. Una volta terminata questa fase, se non si sono verificati errori, la valutazione del messaggio riprende il flusso precedente. Nell'ultima fase dell'analisi lessicale e sintattica dell'intestazione, avviene una cosa analoga: se ci sono ancora dei campi da estrarre, questi devono essere raggruppati in modo tale da soddisfare la sequenza richiesta dalla descrizione dei media. Si può dunque affermare che il parsing di un messaggio SDP viene suddiviso in tre fasi, e le informazioni raccolte da ognuna di esse permettono di individuare con

Valutazione del messaggio

49

estrema facilità qualunque tipologia di errore. Naturalmente se l'annuncio è privo di irregolarità, i dati estratti vengono forniti all'utente utilizzando gli oggetti software definiti in precedenza. A questo punto non rimane che definire il modello secondo il quale specificare le sequenze degli elementi attesi in un messaggio SDP, ovvero la sintassi di un annuncio.

6.7 Specifica della sintassi dell'annuncio La definizione della sintassi di un messaggio SDP rappresenta un punto cruciale nella gestione della procedura di parsing, la quale è possibile solamente se ha a disposizione alcune informazioni. Le nozioni che devono essere fornite al parser sono due: la sequenza degli elementi di un'intestazione ed il numero di occorrenze di ognuno di essi. Per rendere disponibili queste informazioni bisogna mettere a punto delle strutture adeguate. Senza dubbio è necessario avere un oggetto software che indichi

•

La tipologia dell'elemento (campo oppure sequenza)

•

Il numero delle occorrenze (una, al più una, molteplici)

•

Un riferimento che permetta di identificare l'elemento (ad esempio il suo nome)

Inserendo questi oggetti in una coda, è possibile specificare la successione degli elementi all'interno di una descrizione, e, di conseguenza, di un messaggio.

Specifica della sintassi dell'annuncio

50

Durante la procedura di parsing, un particolare puntatore indica l'elemento da estrarre dalla coda, e grazie ai dati ottenuti il parser è in grado di selezionare il comportamento da adottare. Se il componente atteso è un campo, la stringa da valutare viene passata allo strumento preposto alla sua valutazione. A seconda del numero di occorrenze attese per un campo, il relativo parser verrà chiamato in causa più volte. Terminata questa fase un nuovo oggetto viene estratto dalla coda. Diversamente se l'elemento previsto è una descrizione, il flusso delle istruzioni cambia, per cui si entra in una sotto procedura di parsing nella quale la sequenza attesa è differente, ma nella quale si verificano le stesse situazioni descritte inizialmente. Naturalmente una volta terminato questo passaggio alternativo, la procedura principale riprende dal punto in cui è stata interrotta. Il metodo più flessibile per definire le informazioni che devono essere contenute dagli oggetti presenti nella coda consiste nella specifica di un file di configurazione esterno. Ovviamente si tratterà di un file XML mediante il quale la libreria sarà in grado di generare automaticamente gli oggetti necessari al riempimento delle code. Una sintassi plausibile per gli elementi di un messaggio SDP è la seguente

<description name=.....> <element name=..... class=..... occurrences=..... /> <element name=..... class=..... occurrences=..... /> ............................................................................. <element name=..... class=..... occurrences=..... />

Specifica della sintassi dell'annuncio

51

L'idea generale è una sequenza di elementi rappresenta una descrizione, all'interno della quale è possibile trovare campi oppure altre descrizioni. Per ogni elemento deve essere specificato, mediante l'attributo class, l'oggetto software in grado di gestirlo ed il numero di occorrenze richieste, indicato dall'attributo occurrences. La libreria, una volta acquisite le informazioni necessarie dal file di configurazione, provvederà a creare gli oggetti necessari alla rappresentazione della sintassi di un messaggio. Naturalmente si tratta di una versione preliminare che verrà modificata sulla base delle indicazioni fornite da altre fasi dello sviluppo, in particolare quella relativa all'implementazione del parser.

6.8 Generazione automatica del parser e delle descrizioni L'introduzione di un file di configurazione esterno, offre parecchi spunti per delle riflessioni sull'implementazione del parser. Il suo ruolo principale è quello di suddividere un messaggio SDP in una serie di linee, ognuna delle quali dovrebbe rappresentare un campo. Mediante le informazioni apprese dal file di configurazione, è in grado di valutare se la successione dei campi rilevata in un annuncio è ammissibile o meno: inoltre può variare il suo comportamento a seconda della sequenza specificata. Si tratta quindi di un componente che per portare a termine il suo compito, sfrutta abilmente le caratteristiche messegli a disposizione da altri oggetti. Come detto più volte, il procedimento con il quale esegue la valutazione lessicale e sintattica di un messaggio è indipendente dalla

Generazione automatica del parser e delle descrizioni

52

tipologia dell'elemento analizzato, per cui si tratta di un oggetto molto flessibile. Così flessibile da poter essere generato in maniera automatica, sulla base dei dati memorizzati nel file di configurazione. È infatti possibile prevedere uno strumento che generi il parser per il protocollo SDP, a partire dalla descrizione della sua sintassi che, ovviamente, dovrà essere specificata in maniera opportuna. Facendo un passo indietro si nota che nel definire la sequenza delle informazioni attese in un messaggio, vengono specificati minuziosamente tutte le caratteristiche delle descrizioni previste dal protocollo. Gli oggetti software che rappresentano le descrizioni, così come sono stati definiti nei precedenti paragrafi, non sono altro che dei semplici raccoglitori di informazioni, con delle funzionalità estremamente ridotte: i metodi che mettono a disposizione possiedono una logica applicativa che prevede al massimo delle istruzioni condizionali, rivelandosi facilmente riproducibile. Quindi, utilizzando i parametri specificati per la generazione automatica del parser, è possibile creare, senza dover scrivere nessuna riga di codice, le descrizioni presenti all'interno di un annuncio. Questa particolare situazione rende ancora più duttile il pacchetto software progettato, in quanto, pur rimanendo fedele ai vincoli imposti dalla RFC 2327, modificando alcuni parametri del file di configurazione è addirittura possibile personalizzare la gestione dei messaggi SDP. Ad esempio se si vogliono trattare esclusivamente delle intestazioni che annunciano trasmissioni criptate, basterà specificare che almeno un campo EncryptionKey deve essere

Generazione automatica del parser e delle descrizioni

53

presente all'interno del messaggio. Naturalmente possono essere considerate diverse varianti del protocollo originale, ma prima bisogna ampliare la quantità e la varietà delle informazioni che possono essere inserite nel file di configurazione. Per prima cosa bisogna indicare qual è la descrizione principale tra quelle definite, ovvero quella che contiene al suo interno altre descrizioni, in modo tale da determinare la struttura principale del messaggio. Questa distinzione serve ad individuare la prima sequenza attesa nell'annuncio, e per effettuarla è necessario utilizzare il seguente tag

•

<main name=Nome della descrizione />

Le modalità per descrivere una descrizione sono le stesse viste poc'anzi, ma prevedono l'aggiunta di alcuni attributi nel tag element

•

generateHas Indica se

l'oggetto software che

rappresenta la

descrizione deve avere un metodo per testare la presenza di un campo

•

key Presente nei campi che hanno più occorrenze e prevedono delle informazioni suddivise in vari valori. Serve ad indicare quale valore utilizzare come chiave per memorizzare i campi Generazione automatica del parser e delle descrizioni

54

L'introduzione dell'attributo key è necessaria per gestire efficacemente i campi che prevedono più occorrenze e che sono classificati secondo alcuni parametri. È il caso del campo Bandwith: questo può essere presente più volte all'interno di un messaggio SDP, ma solo se questi non contengono informazioni tra loro contraddittorie. Ad esempio i campi

•

b=AS:80

•

b=AS:64

non permettono di determinare qual è la larghezza di banda destinata alla trasmissione. Bisogna quindi prevenire, soprattutto in fase di creazione di un messaggio, l'inserimento di dati contrastanti. Per fare questo però è necessario capire quando due campi dello stesso tipo sono uguali, oppure specifica valori diversi per le stesse proprietà. Effettuare questa distinzione per il campo

Bandwith significa controllare il valore che indica il contesto nel quale è disponibile una certa larghezza di banda. Di conseguenza i campi

•

b=CT:128

•

b=AS:64

Sono esprimono informazioni riguardanti contesti differenti, pertanto sono entrambi ammissibili. Naturalmente questa tipologia di distinzione deve essere

Generazione automatica del parser e delle descrizioni

55

adottata anche nella trattazione dei campi Attribute, anche se in questo frangente la situazione è più complessa in quanto le possibili varianti del campo sono moltissime, pressoché infinite. Il file di configurazione che descrive correttamente la sintassi del protocollo SDP, e permette di generare automaticamente il parser e le descrizioni che fanno parte di un annuncio è il seguente

<jsdp xsi:schemaLocation="jSDP"> <main name="SessionDescription"/> <description name="TimeDescription"> <element name="t" class="Time" occurrences="1"/> <element name="repeatTimes" class="RepeatTime" occurrences="0+"/> <description name="MediaDescription"> <element name="m" class="Media" occurrences="1"/> <element name="i" class="Information" occurrences="0"/> <element name="c" class="Connection" occurrences="0" generateHas="true"/> <element name="bandwiths" class="Bandwith" occurrences="0+" key="modifier"/> <element name="k" class="Key" occurrences="0"/> <element name="attributes" class="Attribute" occurrences="0+"/> <description name="SessionDescription"> <element name="v" class="Version" occurrences="1"/> <element name="o" class="Origin" occurrences="1"/> <element name="s" class="SessionName" occurrences="1"/> Generazione automatica del parser e delle descrizioni

56

<element name="i" class="Information" occurrences="0"/> <element name="u" class="Uri" occurrences="0"/> <element name="emails" class="Email" occurrences="0+"/> <element name="phones" class="Phone" occurrences="0+"/> <element name="c" class="Connection" occurrences="0" generateHas="true"/> <element name="bandwiths" class="Bandwith" occurrences="0+" key="modifier"/> <element name="timeDescriptions" class="TimeDescription" occurrences="1+"/> <element name="z" class="TimeZone" occurrences="0"/> <element name="k" class="Key" occurrences="0"/> <element name="attributes" class="Attribute" occurrences="0+" key="name"/> <element name="mediaDescriptions" class="MediaDescription" occurrences="0+"/>

Nell'attributo class del tag element deve essere specificato anche il package al quale appartiene la classe, ma in queste pagine, per motivi di spazio, è stato omesso. Inoltre il significato dell'attributo name del medesimo tag non deve trarre in inganno: si tratta di un riferimento utile per la creazione degli attributi delle classi Java. Una volta definita la sintassi del protocollo, andiamo a vedere come questa viene processata per generare gli oggetti software capaci di gestirla. Il parsing del file XML avviene mediante Xerces, un parser DOM sviluppato dalla Apache Software Foundation, il quale fornisce le informazioni estratte mediante una struttura ad albero. Il codice generato dalla libreria jSDP rispecchia fedelmente le caratteristiche specificate, creando una classe per

Generazione automatica del parser e delle descrizioni

57

ognuna delle descrizioni definite. I campi che compongono una descrizione sono degli attributi d'istanza, ed ognuno di essi è rappresentato dall'oggetto software preposto alla sua rappresentazione. La parte più complessa della generazione del codice è sicuramente quella relativa alla gestione degli elementi con più occorrenze. Tali oggetti vengono infatti memorizzati utilizzando tecniche differenti, a seconda delle loro caratteristiche. Nella maggior parte dei casi vengono utilizzate delle semplici liste, in quanto non è necessario garantire l'univocità le informazioni inserite, poiché queste non possono dare luogo ad equivoci di nessun genere. I campi multipli che richiedono particolare attenzione sono quelli che, nel file di configurazione, sono descritti mediante l'ausilio dell'attributo key. In questo caso i dati vengono gestiti mediante delle mappe, utilizzando uno specifico valore come chiave: la logica applicativa è piuttosto articolata, dal momento che deve proibire l'inserimento di campi contenenti delle informazioni equivoche. La generazione del parser non presenta molte particolarità, in quanto il suo nucleo è il medesimo per ognuno dei suoi potenziali aspetti. Quello che cambia, a seconda dei parametri specificati, sono le code che vengono create per gestire le sequenze degli elementi da verificare. Naturalmente per ottimizzare lo sfruttamento della memoria, le code vengono inizializzate durante la creazione della prima istanza della classe. Ogni volta che viene richiesto un oggetto per effettuare il parsing di un messaggio, oppure di una descrizione, i puntatori delle code vengono resettati, in modo tale da puntare sul primo oggetto

Generazione automatica del parser e delle descrizioni

58

memorizzato. Per quanto riguarda i metodi messi a disposizione dell'utente, questi permettono di effettuare il parsing delle descrizioni indicate dal protocollo SDP, descrizione della sessione (che in certo modo rappresenta il messaggio) compresa. Ovviamente se l'analisi lessicale e sintattica della stringa sottomessa dovesse individuare degli errori, questi saranno riportati, con una breve ma chiara descrizione, mediante il sollevamento di un'eccezione. Viceversa se la valutazione del messaggio risulta positiva, le informazioni estratte vengono memorizzate mediante gli oggetti creati assieme al parser, i quali permettono di manipolarli con estrema semplicità.

Generazione automatica del parser e delle descrizioni

59

7 Analisi comparativa di librerie SDP

In queste pagine verrà illustrato l'esito di una serie di test condotti sugli esistenti pacchetti software per la gestione del protocollo SDP, confrontando questi risultati con quelli ottenuti dalla libreria jSDP.

7.1 La libreria sviluppata dal NIST Il pacchetto software sviluppato nell'ambito del progetto JAIN-SIP dal National Institute of Standards and Technology, rappresenta l'unica implementazione delle API proposte dalla JSR 141. Si tratta di un prodotto non ancora completamente perfetto ma valido, come verrà dimostrato dalle prove illustrate in questo paragrafo.

7.1.1 Parsing dei campi SDP Per valutare la capacità della libreria del NIST di valutare correttamente la sintassi ed il lessico dei campi SDP, verrà analizzato un messaggio che contiene, volutamente, alcuni errori

v=2 o=mhandley 2890844526 -2890842807 IN IP4 256.16.64.4 s=SDP Test i=session description protocol sample message u=http://jsdp.sourceforge.net/test e=Claudio Di Vita

Parsing dei campi SDP

60

p=+39 Prefisso telefonico-123456768 c=IN IP4 204.2.17.12/127 b=TT:64 t=2873397496 2873404696 r=604800 3600 0 90000 r=4d 3h 0 16h z=2882844516 -3h 2898848070 0 k=blowfish:5A7GH90ADM1 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb a=orient:portrait

Il valore del campo Version richiede delle considerazioni particolari. Sebbene nella RFC 2327 non venga indicato uno specifico numero di versione del protocollo, la convenzione che si è diffusa negli anni prevede che il campo

Version abbia la forma v=0. Bisogna però ricordare che il parser di questa libreria reputa corretti anche dei numeri interi negativi, ma solleva un'eccezione in presenza di caratteri non numerici. Lo stesso problema è riscontrabile nel campo Origin, nel quale i valori che rappresentano l'id della sessione e la sua versione (utile per ricostruire l'ordine con il quale sono stati inviati i messaggi) devono essere degli interi positivi. Un errore piuttosto grave si verifica nella valutazione degli indirizzi IP presenti nel messaggio, sia nel campo Origin che nel campo Connection. Il controllo che viene effettuato presenta molte lacune, dovute alle scelte implementative che sono state fatte dagli sviluppatori del NIST. Infatti nel protocollo SDP la Parsing dei campi SDP

61

rappresentazione delle risorse può avvenire indicando l'FQDN (Fully Qualified Domain Name), oppure l'indirizzo IP, delle fonti dei media trasmessi. Se non vengono prese delle particolari attenzioni nel trattare queste possibilità, la loro valutazione risulta estremamente difficoltosa. Questo avviene perché un dominio può contenere anche dei numeri, pertanto essendo poco scrupolosi nella definizione delle caratteristiche che individuano un nome di dominio, un indirizzo IP può essere trattato come un FQDN e di conseguenze non viene effettuato nessun controllo sulla sua ammissibilità. Il parsing del campo Email si rivela piuttosto efficiente, a condizione che questo comprenda delle informazioni extra, così come avviene nel messaggio preso come modello. Infatti se il campo Email ha la forma e=<user>@ il parsing non viene effettuato correttamente poiché viene estratto solamente il nome dell'utente, mentre il dominio di posta rimane indefinito. Il campo Phone invece può essere utilizzato per contenere informazioni di qualunque tipo, in quanto, stando alle valutazione effettuate dal parser, qualunque sequenza di caratteri sottomessa non presenta errori. La valutazione del campo Bandwith è invece più rigorosa, nonostante si limiti all'identificazione del modificatore e del valore della larghezza di banda. Infatti viene verificato che il campo abbia la forma b=<modificatore>:, ma la precisione dei test non è pienamente soddisfacente: esistono solamente quattro tipi di modificatore, mentre il parser accetta una qualunque combinazione di caratteri alfanumerici ed inoltre vengono accettate anche larghezze di banda con valori negativi,

Parsing dei campi SDP

62

quindi prive di significato. Come noto l'indicazione dei tempi in cui è attiva la sessione deve avvenire mediante l'utilizzo di timestamp NTP: pertanto i numeri negativi non sono ammissibili, mentre il valore t=0 0 indica una trasmissione sempre disponibile. L'analisi del campo Time risulta estremamente corretta, ed è in grado di verificare che entrambi gli estremi specificati rispondano ai requisiti indicati nella RFC 2327. Purtroppo però in nessuna delle prove effettuate è stato possibile valutare in alcun modo il campo RepeatTime, poiché la procedura di parsing ha sollevato delle continue eccezioni. La stessa situazione è stata riscontrata anche nel parsing del campo TimeZone, che serve ad indicare le modifiche e le correzioni dovute ai diversi fusi orari rispetto alle informazioni fornite nel campo RepeatTime. Probabilmente questo è dovuto ad un errore nella fase di rilascio del pacchetto, nel quale sono stati inclusi dei componenti non ancora completi. Per quanto riguarda il parsing del campo EncryptionKey, vale il discorso fatto per il campo Phone: è possibile specificare praticamente qualunque carattere rendendo inutile l'introduzione del campo, perché non viene considerata la distinzione che dovrebbe esistere tra metodo e chiave di criptazione. Il campo EncryptionKey però ricopre senza dubbio un'importanza maggiore rispetto al campo Phone, in quanto permette di specificare i parametri necessari alla decodifica dei media trasportati da una sessione privata. Non potendo sfruttare appieno le opportunità offerte dall'introduzione di questo campo all'interno di un messaggio SDP, il pacchetto software sviluppato dal

Parsing dei campi SDP

63

NIST non è in grado di supportare pienamente la creazione di annunci per le sessioni private. La valutazione lessicale e grammatica del campo Attribute offre lo spunto per muovere una critica alle convenzioni definite dal protocollo SDP. Nella RFC 2327 questo campo viene indicato come il principale metodo per estendere le funzionalità del protocollo, in modo particolare per adattarlo ai requisiti delle diverse tipologie di media che possono essere trasmessi. Per questo motivo può presentarsi sotto le forme a=<proprietà> e a=:, dando luogo a delle forti ambiguità: in pratica ogni combinazione di caratteri è ammissibile, rendendo arduo stabilire quando il contenuto del campo Attribute rappresenta una proprietà oppure la coppia attributo-valore. Questa confusione è inoltre alimentata da diversi draft che specificano diversi tipi di attributi per le applicazioni più svariate. Nonostante queste difficoltà il parsing del campo è molto

efficiente

e

riesce

quasi

sempre

a

determinare

la

corretta

rappresentazione delle informazioni. I rari casi in cui questo non avviene sono da imputare alla presenza di errori nel campo analizzato. Quindi fatta esclusione per i campi appena menzionati, la libreria del NIST è in grado di valutare correttamente tutti i campi che possono essere presenti all'interno di un annuncio SDP. Rimane però da migliorare il supporto al controllo dell'ammissibilità delle risorse specificate nel messaggio, che si rivela un problema non tanto nel parsing di un'intestazione ma nella sua creazione in quanto non permette di verificare la correttezza degli indirizzi forniti.

Parsing dei campi SDP

64

Ovviamente se non è possibile prendere parte ad una sessione, l'annuncio non ha raggiunto i suoi scopi.

7.1.2 Valutazione sintattica e creazione di un annuncio A causa della struttura della libreria, la valutazione della correttezza di un messaggio si riduce alla sola verifica della sintassi dell'intestazione. Infatti, così come accade per la libreria jSDP, esiste un oggetto software in grado di analizzare ognuno dei campi SDP. Nonostante le difficoltà incontrate nell'avere accesso a trasmissioni multicast che trasportassero messaggi SDP, a causa della penuria di fonti ed alla riservatezza di certe informazioni (il protocollo SDP interviene nell'annuncio di videoconferenze, che sono molto spesso a carattere privato), è stato comunque possibile collaudare in maniera soddisfacente il parser fornito dal NIST. Appare quasi superfluo evidenziare che fatta eccezione per alcuni messaggi che comprendevano i campi, perlopiù opzionali, che la libreria supporta con qualche mancanza (come è stato visto nel paragrafo precedente), la libreria è stata in grado di analizzare senza nessun problema i messaggi proposti, rendendo poi disponibili le informazioni estratte mediante gli oggetti software specificati dalla JSR 141. Questo è sicuramente un fatto positivo, ma per ottenere un quadro completo della situazione è stato necessario sottoporre al giudizio del parser anche dei messaggi non corretti dal punto di vista sintattico. Sono stati utilizzate diverse tipologie di messaggi, ognuna delle quali presentava delle particolari

Valutazione sintattica e creazione di un annuncio

65

condizioni tali da evidenziare un determinato aspetto del comportamento del parser. Ad esempio il messaggio

v=0 o=alice 2890844526 2890844527 IN IP4 host.example.com s=SDP test a=sendonly t=0 0 c=IN IP4 host.example.com m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 a=rtpmap:31 H261/90000

non è del tutto corretto poiché la sintassi del protocollo SDP non viene rispettata, ma viene comunque considerato valido dal parser della libreria sviluppata dal NIST. Queste sono delle scelte implementative, che variano a seconda dei pacchetti software: la libreria jSDP è molto più rigida e valuta errato questo messaggio. È però importante notare che nonostante l'ordine dei campi sia errato, è facile capire a quale parte del messaggio fanno riferimento: infatti l'oggetto software che rappresenta le informazioni estratte è in grado di rielaborarle per costruire questo annuncio

v=0 o=alice 2890844526 2890844527 IN IP4 host.example.com s=SDP test c=IN IP4 host.example.com

Valutazione sintattica e creazione di un annuncio

66

t=0 0 a=sendonly m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 a=rtpmap:31 H261/90000

Quindi anche da messaggi non formattati perfettamente è possibile ricavare dei dati utilizzabili. Una situazione analoga si verifica nell'analisi di questa intestazione

v=0 o=alice 2890844526 2890844527 IN IP4 source.example.com s=SDP test t=3034123619 3042462419 r=1d 8h 0 12h m=audio 51372 RTP/AVP 0 c=IN IP4 chicago.example.com m=audio 49170 RTP/AVP 0 8 97 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 m=video 51372 RTP/AVP 31 32 a=rtpmap:31 H261/90000 a=rtpmap:32 MPV/90000

Purtroppo anche questo messaggio viene considerato corretto, mentre in realtà non lo è. Infatti poiché il campo Connection non è specificato a livello di sessione, questo deve essere presente in ognuna delle descrizioni dei media Valutazione sintattica e creazione di un annuncio

67

affinché possa essere individuata la sorgente della trasmissione. Si tratta quindi di un errore piuttosto evidente che da un lato può sembrare di poca importanza: è possibile prendere parte alla trasmissione di cui è nota la fonte, le altre non sono raggiungibili per motivi indipendenti dall'analisi del messaggio in quanto è l'annuncio stesso ad essere incompleto. Chiaramente poteva essere fatte delle scelte diverse, come quelle che sono state fatte durante lo sviluppo della libreria jSDP, che richiedendo un maggiore rigore sintattico avrebbe ritenuto inaccettabile questo messaggio. Sfortunatamente il comportamento del parser riflette quello degli altri componenti della libreria durante la creazione di una intestazione. Infatti quando viene aggiunta una descrizione dei media ad un messaggio, non viene verificato se le informazioni messe a disposizione sono sufficienti a raggiungere tutti i media presentati nell'annuncio. Quindi la libreria sviluppata dal NIST, se non viene utilizzata con la necessaria attenzione, potrebbe generare dei messaggi SDP non corretti. Naturalmente si tratta di considerazioni estremamente critiche, in quanto non si può pretendere che un pacchetto software riesca ad evitare gli errori degli utenti. Certamente si può fare il possibile per limitarli, ma è impossibile eliminarli del tutto.

7.1.3 Giudizio sulla libreria Nonostante non abbia ancora raggiunto la piena maturità, la libreria sviluppata dal NIST costituisce senza dubbio alcuno un valido strumento per la gestione

Giudizio sulla libreria

68

del protocollo SDP. Le principali mancanze si rilevano nel supporto ad alcuni campi opzionali del protocollo, che non trasportano informazioni fondamentali per prendere parte alla sessione. L'aspetto che deve essere assolutamente migliorato è il controllo dell'ammissibilità degli indirizzi delle fonti della trasmissione, sia che queste siano indicate mediante il loro FQDN che con il loro indirizzo IP: specificare delle sorgenti non corrette, e di conseguenza non raggiungibili, rende inutile il messaggio. La procedura di parsing di un annuncio potrebbe essere maggiormente rigorosa, ma la soluzione adottata dagli sviluppatori del NIST è comunque efficiente. Bisogna però ricordare che questo prodotto fa parte di un parte di un progetto di più ampio respiro, volto alla realizzazione di una libreria per la gestione del protocollo SIP. Di conseguenza per porre una base comune ad entrambe le librerie, e per condividere quanto più codice possibile, alcune scelte implementative, seppure obbligate, hanno penalizzato alcuni aspetti della libreria dedicata al protocollo SDP. Sicuramente con il rilascio delle prossime versioni del pacchetto gli attuali problemi che, in generale, sono trascurabili, verranno risolti.

7.2 La libreria della Columbia University Attualmente la libreria CU JSIP, che supporta, tra l'altro, il protocollo SDP, non è stata ancora resa disponibile dalla Columbia University, pertanto non è stato possibile effettuare un confronto con la libreria jSDP. Molto probabilmente nella progettazione della libreria è stato preso come modello un altro pacchetto

La libreria della Columbia University

69

software dedicato alla gestione del protocollo SDP, sempre messo a punto dalla Columbia University, che però è sviluppato in C/C++. Lo sviluppo di quest'ultima libreria va avanti da alcuni anni, ed ha raggiunto dei livelli piuttosto elevati, pertanto è lecito attendere delle forti analogie tra i due prodotti dell'università americana.

7.3 I risultati ottenuti dalla libreria jSDP Come anticipato durante il commento dell'esito dei test svolti sul pacchetto software sviluppato dal NIST, e come era possibile prevedere dalle scelte effettuate durante la fase di progettazione, la libreria jSDP è caratterizzata da un rigore sintattico molto marcato. Essendo, in un certo senso, maggiormente specializzata rispetto ad altre librerie, grazie all'utilizzo delle espressioni regolari è in grado di trattare correttamente qualunque tipologia di campo SDP. Rispetto al software sviluppato dal NIST può apparire meno flessibile durante la valutazione di un messaggio, in quanto pretende che la sintassi sia rispettata fedelmente in ogni caso. Talvolta questa scrupolosità può risultare eccessiva causando il rifiuto di messaggi che, seppure confusi, sono comunque comprensibili, ma da una parte garantisce la totale correttezza degli annunci generati. I test effettuati permettono di affermare che la libreria jSDP assolve pienamente i requisiti funzionali richiesti, in quanto è in grado di analizzare lessicalmente e sintatticamente un messaggio SDP e di generare intestazioni SDP corrette.

I risultati ottenuti dalla libreria jSDP

70

8 Conclusioni

In questa tesi sono state trattate le problematiche relative alla progettazione ed alla realizzazione di una libreria per la gestione di un protocollo per le trasmissioni multicast. Il protocollo scelto per questa trattazione è SDP, Session Description Protocol, il quale, trovandosi coinvolto in un gran numero di trasmissioni multicast, rappresenta un valido esempio delle difficoltà tipiche di queste situazioni. È stato evidenziato che la valutazione dei messaggi di un protocollo non è gestibile mediante l'utilizzo di strumenti per la generazione automatica di parser, in quanto questi introducono della ridondanza nel codice prodotto, dovuta alla necessità di verificare la correttezza delle informazioni anche durante la creazione di un annuncio. Di conseguenza per soddisfare i requisiti richiesti, è stato necessario adottare una tecnica frutto della combinazione di alcune caratteristiche delle differenti architetture presentate, ognuna delle quali presentava, per diversi motivi, dei difetti tali da non poter essere presa in considerazione. Questa scelta ha permesso di mettere a punto un sistema per la creazione di un parser per il protocollo, a partire dalla definizione di quest'ultimo mediante delle strutture sintattiche adeguate, aumentando notevolmente la flessibilità della libreria. I test effettuati sul pacchetto software sviluppato utilizzando la strategia illustrata ne hanno dimostrato la validità, ponendo questa libreria agli stessi livelli di altri prodotti maggiormente collaudati, come la Conclusioni

71

libreria sviluppata dal NIST. Naturalmente questo non è sufficiente ad affermare che la soluzione proposta sia la più efficiente, in quanto si tratta di una valutazione figlia del contesto nel quale viene adoperata una libreria software per la gestione del protocollo SDP, ma ne sottolinea il valore.

Conclusioni

72

9 Bibliografia •

M. Handley e V. Jacobson, "RFC 2327, SDP: Session Description Protocol", Aprile 1998 http://www.ietf.org/rfc/rfc2327.txt

•

S. Olson, G. Camarillo e A. B. Roach, “RFC 3266, Support for IPv6 in Session Description Protocol (SDP)”, Giugno 2002 http://www.ietf.org/rfc/rfc3266.txt

•

M. Handley, V. Jacobson, e C. Perkins, "Internet Draft, SDP: Session Description Protocol", Giugno 2004 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-18.txt

•

A. Johnston e R. Sparks, “Internet Draft, Session Description Protocol Offer Answer Examples”, Agosto 2004 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-answer-examples05.txt

•

K. Porter, et. al, "SDP API Overview", Java Community Process http://www.jcp.org/en/jsr/detail?id=141

•

M. Handley, C. Perkins ed E. Whelan, “RFC 2974, Session Announcement Protocol”, Ottobre 2000 http://www.ietf.org/rfc/rfc2974.txt

•

M. Handley, H. Schulzrinne, E. Schooler, e J. Rosenberg, “RFC 2543, SIP: Session Initiation Protocol”, Marzo 1999 http://www.ietf.org/rfc/rfc2543.txt

•

Alfred V. Aho, Ravi Sethi e Jeffrey D. Ullman, “Compilers: Principles, Techniques, and Tools”, Addison-Wesley, 1986

•

Steven John Metsker, “Building parsers with Java”, Addison-Wesley, 2001

•

Jeffrey E.F. Friedl, “Mastering Regular Expressions, 2nd Edition”, O'Reilly

•

Andrew S. Tanenbaum, “Computer Networks, 4th Edition”, Prentice Hall

Bibliografia

73