Sei sulla pagina 1di 76

Facoltà di Ingegneria

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

Relatore

Maurizio Patrignani

Anno Accademico 2003/2004

Laureando

Claudio Di Vita

115787/98

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.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

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

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.

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.

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

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

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.

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

trasmissioni

necessarie

alla

ricezione

delle

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

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

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

<type>=<value>, dove <type> è sempre un solo carattere minuscolo mentre

<value> è una stringa di testo il cui formato dipende da <type>. 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=

Indica

messaggio

la

o=

[Version]

versione

[Origin]

del

protocollo

utilizzata

nel

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

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

z=*

[ZoneAdjustment]

Specifica 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

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

[Bandwith]

[EncryptionKey]

[Attribute]

b= *

k= *

a=*

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

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.

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

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

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.

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

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

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

Individuazione dell'identificatore del campo SDP

Individuazione dell'identificatore del campo SDP
Individuazione dell'identificatore del campo SDP
Individuazione dell'identificatore del campo SDP
Individuazione dell'identificatore del campo SDP
SDP Individuazione dell'identificatore del campo SDP Valutazione del campo mediante un parser specializzato
Valutazione del campo mediante un parser specializzato

Valutazione del campo mediante un parser specializzato

Valutazione del campo mediante un parser specializzato
Valutazione del campo mediante un parser specializzato
SDP Valutazione del campo mediante un parser specializzato Informazioni estratte dal campo SDP Utilizzo di parser

Informazioni estratte dal campo SDP

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,

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.

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=

azione di un albero con la seguente struttura v= o= s= i= * u= * u=
i= *
i=
*
u= *
u=
*
u= * e= * e= * p= *
u=
*
e=
*
e=
*
p=
*

e=

* p= * p= * c= * p= * c= * c= * b= *
*
p=
*
p=
*
c=
*
p=
*
c=
*
c=
*
b=
*
* Campo opzionale

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 è

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

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

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

grammatica trattata

regolari

specificate

nella

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

immediatamente: questo non è possibile utilizzando l'approccio descritto in

precedenza.

diversamente

Per

ovviare

a

questo

alcune

responsabilità

inconveniente

è

possibile

assegnare

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,

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

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.

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

<campo>=<valore>, altri non è che la specializzazione del generico campo di

un messaggio

<campo>=<valore>

campo di un messaggio <campo>=<valore> v=<versione del protocollo> s=<nome della

v=<versione del protocollo>

s=<nome della sessione>

del protocollo> s=<nome della sessione> a=<proprietà del messaggio> =<valore>

a=<proprietà del messaggio>

=<valore>

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

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

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

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.

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

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,

agevolmente gli scopi prefissati.

6.4 Creazione di un messaggio

consentono

di

ottenere

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

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

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

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

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

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,

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

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

estremamen te semplice, quasi banale Occorrenze di campo SDP Nessuna occorrenza Una sola occorrenza Una o

Nessuna occorrenza

quasi banale Occorrenze di campo SDP Nessuna occorrenza Una sola occorrenza Una o più occorrenze Chiaramente

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 è

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,

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

che la linea n esima 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

L'ammissione

priori,

permettendo

di

queste

condizioni

di

selezionare

il

parser

appropriato.

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

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

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

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.

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= </description>

class=

occurrences=

/>

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

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

opportuna.

Facendo

un

passo

che, ovviamente, dovrà essere

specificata in maniera

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

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

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

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>

<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>

<description name="SessionDescription">

<element name="v" class="Version" occurrences="1"/>

<element name="o" class="Origin" occurrences="1"/>

<element name="s" class="SessionName" occurrences="1"/>

<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+"/>

</description>

</jsdp>

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