Modellazione del protocollo IDM attraverso il simulatore Omnet++

Università degli Studi di Bari Aldo Moro
FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI
Corso di Laurea in Informatica e tecnologie per la produzione del
software
Modellazione del protocollo IDM
attraverso il simulatore
Omnet++
Tesi di Laurea in Reti di calcolatori
Relatore:
Prof.
Nicola Di Mauro
Laureando:
Francesco Sportelli
Sessione
Anno Accademico 2009-2010
Indice
1 Introduzione
1.1 Panoramica sulla storia delle reti di calcolatori . . . .
1.2 Definizione del problema affrontato . . . . . . . . . .
1.3 Altri approcci usati in letteratura . . . . . . . . . . .
1.4 La soluzione: IDM come protocollo multilivello object
1.5 Un possibile scenario d’uso . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
oriented
. . . . .
2 Concetti generali
2.1 Rete di calcolatori . . . . . .
2.2 Nodo di rete . . . . . . . . .
2.3 Protocollo di rete . . . . . .
2.4 Inter-rete . . . . . . . . . .
2.5 Paradigma Object-Oriented
2.6 Routing . . . . . . . . . . .
2.7 Tos e Qos . . . . . . . . . .
2.8 Pacchetto . . . . . . . . . .
2.9 Latenza . . . . . . . . . . .
2.10 Throughput . . . . . . . . .
2.11 Rete di sensori . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 IDM per l’integrazione di reti eterogenee
3.1 Il protocollo IDM . . . . . . . . . . . . . . . .
3.1.1 Introduzione al protocollo IDM . . . .
3.1.2 Inter-Reti . . . . . . . . . . . . . . . .
3.1.3 Routing omogeneo . . . . . . . . . . .
3.2 Instradamento . . . . . . . . . . . . . . . . . .
3.2.1 Identità dell’oggetto . . . . . . . . . .
3.2.2 Un esempio di instradamento . . . . .
3.3 Endpoints . . . . . . . . . . . . . . . . . . . .
3.4 Le politiche del TOS e QOS . . . . . . . . . .
3.4.1 Quality of service . . . . . . . . . . . .
3.4.2 Type of service . . . . . . . . . . . . .
3.4.3 Class queueing discipline . . . . . . .
3.4.4 Pfifo fast queueing discipline . . . . . .
3.4.5 Token bucket filter queueing discipline
3.4.6 Stochastic fairness queueing discipline .
3.4.7 Prio queueing discipline . . . . . . . .
3.5 Gestione della qualità di servizio . . . . . . .
3.6 Invio messaggi . . . . . . . . . . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
4
5
6
6
.
.
.
.
.
.
.
.
.
.
.
8
8
9
9
9
10
11
11
11
12
12
12
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
15
16
16
17
19
19
20
23
23
26
26
26
28
31
32
33
34
3.7
3.8
3.6.1 Invio diretto . . . . .
3.6.2 Invio indiretto . . . . .
Routing . . . . . . . . . . .
3.7.1 Routing dinamico . . .
3.7.2 Gestione della rete . .
Integrazione con il middleware
3.8.1 Prototipi e risultati . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 I simulatori, la simulazione ed Omnet
4.1 Simulazione ed emulazione . . . . . . . . . . . . .
4.2 Classificazione dei simulatori . . . . . . . . . . . .
4.3 I simulatori adottati . . . . . . . . . . . . . . . .
4.3.1 Ns-2 . . . . . . . . . . . . . . . . . . . . .
4.3.2 Omnet . . . . . . . . . . . . . . . . . . . .
4.4 Scelta di omnet . . . . . . . . . . . . . . . . . .
4.5 Il simulatore OMNeT++ . . . . . . . . . . . . . .
4.5.1 Il linguaggio NED . . . . . . . . . . . . . .
4.5.2 Il sistema di simulazione ad eventi discreti
4.5.3 La macchina a stati finiti . . . . . . . . . .
4.5.4 I messaggi . . . . . . . . . . . . . . . . . .
4.5.5 Architettura . . . . . . . . . . . . . . . . .
4.6 INET framework . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
35
37
37
38
38
41
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
44
45
46
46
47
47
49
51
52
53
53
55
5 Modellazione del protocollo IDM
su Omnet
58
5.1 Gli argomenti trattati nella simulazione . . . . . . . . . . . . . 58
5.2 La progettazione del network . . . . . . . . . . . . . . . . . . 58
5.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . 61
6 Analisi dei risultati
6.1 I risultati in Omnet . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Latenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
67
67
68
Conclusioni e sviluppi futuri
69
2
1
Introduzione
Il lavoro che segue è stato svolto nell’ambito del progetto IDM (Inter-Domain
Messaging)[1] del gruppo di ricerca spagnolo ARCO Research Group[10] dell’Università della Castilla-La Mancha con la collaborazione dell’Università
del Mayab, Mexico. Il lavoro svolto affronta la modellazione del protocollo
IDM usando il simulatore di rete Omnet. [2] L’esigenza dell’uso del modello
simulativo nasce dalla necessità di valutare il protocollo in vari ambiti, ma
anche perchè una simulazione su reti reali può divenire molto costosa. Omnet
è uno strumento opensource che permette tutto questo, offrendo inoltre molti vantaggi che economizzano il lavoro. Attraverso la simulazione è possibile
valutare le qualità e le prestazioni del protocollo in esame.
• Il primo capitolo sarà di carattere introduttivo, presentando i caratteri
generali del problema in rapporto con soluzioni presenti in letteratura,
mettendo in luce le innovazioni di IDM giustificando il perchè del suo
utilizzo;
• il secondo capitolo definisce alcuni dei concetti fondamentali che verrano ripresi più volte nel corso della tesi;
• il terzo capitolo focalizza l’attenzione sul protocollo IDM e su tutte le
sue caratteristiche;
• il quarto capitolo tratta della simulazione ed introduce l’uso del simulatore Omnet++;
• il quinto capitolo riguarda la modellazione del protocollo IDM attraverso Omnet++ ed infine il sesto ne presenta i risultati ottenuti dalla
simulazione.
3
1.1
Panoramica sulla storia delle reti di calcolatori
La storia delle reti di calcolatori affonda le sue radici agli inizi degli anni
Settanta. Il Governo degli Stati Uniti decise di creare un istituto di ricerca
denominato ARPA(Advanced Research Projects Agency), il quale scopo era
di costruire un nuova tecnologia innovativa per permettere di collegare i vari
computer delle università americane ed i laboratori di ricerca. Cosı̀ nacque
ARPAnet un sistema che consentiva ai computer host della rete di comunicare e condividere dati tra loro. Ciascun host viene identificato attraverso
un indirizzo univoco che consente l’instradamento verso il computer di destinazione dei pacchetti contenenti le informazioni. Per tutti gli anni Settanta
ARPAnet continuò a svilupparsi in ambito universitario e governativo, ma
dal 1974, con l’avvento dello standard di trasmissione TCP/IP (Transmission
Control Protocol/Internet Protocol), il progetto della rete prese ad essere denominato Internet. Negli stessi anni si affiancava un’altra grande rivoluzione
informatica: l’avvento del personal computer. Negli anni Ottanta cominciò
a propagarsi la diffusione su larga scala dei personal computer, permettendo
cosı̀ la possibile diffusione della rete al di fuori degli ambiti più istituzionali e
accademici, rendendo di fatto potenzialmente collegabili centinaia di migliaia
di utenti. Internet quindi era diventata un’area molto estesa che consentiva
lo scambio di informazioni a migliaia di utenti sparsi per il mondo. Attualmente Internet è diventata una rete estremamente complessa formata da reti
di reti, ciascuna delle quali ha al suo interno uno svariato numero di host. La
massima espansione di Internet si è avuta per mezzo del World-Wide-Web,
un servizio di Internet il quale consente la possibilità di navigare ed usufruire
di un insieme vastissimo di contenuti multimediali e di ulteriori servizi accessibili a tutti o ad una parte selezionata degli utenti di Internet. Col passare
del tempo, nuove tecnologie innovative hanno affiancato l’uso di Internet,
come le reti MANET e le reti di sensori, creando cosı̀ la necessità di creare
scenari che coinvolgono l’interconnessione di reti tra di loro eterogenee.
1.2
Definizione del problema affrontato
Il problema affrontato nella tesi riguarda appunto l’utilizzo di una possibile
soluzione per la comunicazione tra reti eterogenee, le quali usano tecnologie e protocolli differenti. Si necessita quindi di una soluzione in grado di
gestire questo tipo di comunicazione anche a partire da più livelli, dal livello di trasporto fino al livello fisico.Si dovrà quindi definire un protocollo
multilivello in grado di interfacciarsi sui vari livelli a seconda delle reti comunicanti. L’obiettivo ultimo sarà quello di garantire l’interoperabilità tra
le varie applicazioni che vengono eseguite da ciascun nodo di rete usando lo
4
stesso protocollo e quello di poter inviare messaggi da una rete a qualsiasi
altra rete che utilizzi una tecnologia o protocolli di rete incompatibili.
1.3
Altri approcci usati in letteratura
In letteratura ci sono vari esempi di come sia stata affrontata la tematica
fin’ora. Lo scenario ideale al quale applicare il protocollo modellato è proprio una rete di sensori di tipo WSAN. [3] Un primo approccio al problema è
dato dall’uso di un protocollo univoco per l’intera infrastruttura, solitamente TCP/IP, però questo da origine a vari problemi: implementare lo stack
TCP/IP è troppo oneroso per questo tipo di infrastruttura poichè richiede
delle risorse computazionali elevate, per cui spesso è necessario una radicale
modifica dell’intera rete per garantire il giusto adattamento(incapsulamento
degli header, compressione pacchetti, indirizzamento, etc. ). Il protocollo
TCP/IP sarebbe il meno adatto per un’infrastruttura simile, poichè le reti
wireless sono solite aggiungere informazioni ridondanti nella trasmissione e ritrasmissione dei pacchetti. Attraverso il protocollo TCP/IP si provocherebbe
facilmente un abbassamento del data rate, provocando il congestionamento
della rete.
Un approccio migliore è dato dall’uso di un protocollo più adatto alle
esigenze dell’infrastruttura presa in esame. Alla base del meccanismo c’è un
gateway o delle base stations che si interfacciano con ogni singolo nodo sensore. Quando il client con una connessione TCP/IP si interfaccia col gateway,
quest’ultimo invia la richiesta su un altro protocollo più specifico, al nodo
sensore di destinazione. Anche questo approccio presenta dei problemi: bisogna conoscere l’indirizzo del gateway piuttosto che conoscere solo l’indirizzo
del nodo di destinazione, inoltre c’è mancanza di autonomia in funzione del
fatto che i nodi di sensori non possono interagire con elementi esterni alla
rete SAN[4] direttamente, funzionano solo all’interno della propria rete. È
questo uno dei problemi fondamentali ossia la mancanza di eterogeneità della
rete quando protocolli diversi devono comunicare tra di loro.
Internet ad esempio è basata sul singolo protocollo IP. Questo si interfaccia con i due livelli sottostanti ossia datalink e livello fisico. Ciò permette la
interconnessione di reti ma solo se vengono rispettate certe condizioni:
• gli host devono comprendere lo schema logico di indirizzamento
• gli host devono saper creare datagrammi sapendosi interfacciare con i
livelli sottostanti
• è richiesto un router per l’instradamento di pacchetti
5
• quando c’è un mezzo di diffusione, deve concedere il mapping dagli
indirizzi logici al livello fisico.
Quando si attraversa questo tipo di network con protocolli o tecnologie
incompatibili, si usa il tunnelling. [5] Questo approccio però non consente
schemi di routing omogenei. Quindi il problema fondamentale è come mettere
in comunicazione un device con una data tecnologia differente con il livello
logico.
Multiprotocol Label Switching (MPLS, RFC3031) e Layer Two Tunneling
Protocol (L2TPv3, RFC3931) affrontano il problema diversamente. Permettono la comunicazione tra reti eterogenee, ma entrambi hanno la limitazione
di appoggiarsi su IP come livello più basso e questo è limitante soprattutto
per una rete di sensori.
Nello scenario contemporaneo, nessuno tra questi protocolli risolve definitivamente il problema della totale integrazione di reti eterogenee.
1.4
La soluzione: IDM come protocollo multilivello
object oriented
La soluzione proposta a fronte di queste problematiche è il protocollo IDM.
Attraverso la formula di un protocollo multilivello legato alla progettazione
object-oriented, IDM si propone di risolvere tutti i problemi sopracitati che
nella letteratura e nelle tecnologie esistenti, non sono stati ancora risolti,
garantendo cosı̀ l’eterogeneità tra reti differenti. [7]
1.5
Un possibile scenario d’uso
Considerando la figura 1, viene illustrato un tipico esempio di inter-rete,
composta da 4 differenti network IDM.
I protocolli usati in questa inter-rete sono l’ATM (Asynchronous Transfer
Mode), Zigbee, XBow ed infine IP. È facile notare che sono 4 protocolli
differenti tra loro ed incompatibili, poichè ciascuno ha determinate funzioni
in determinati contesti. Zigbee è indicato per una WPAN (Wireless Personal
Area Networks), XBow per una WSN (Wireless Sensor Network) ed ATM per
le telecomunicazioni. Il problema da risolvere è rendere compatibili tra loro
questi protocolli che usano dispositivi differenti a diversi livelli, permettendo
cosı̀ la comunicazione da qualsiasi nodo della rete verso un qualsiasi altro
nodo della stessa. Ad esempio IP è di livello 3 (rete) ed ATM è di livello
2 (datalink) e l’incompatibilità riguarda il livello, mentre i dispositivi che
formano una rete di sensori sono nettamente differenti dagli host della rete IP.
La soluzione proposta consiste nel porre almeno un router IDM sul confine
6
Figura 1: Una inter-rete IDM composta da 4 differenti network IDM
tra ogni coppia di network. Sarà quindi il router IDM a dover instradare
correttamente i pacchetti ad ogni destinatario di un’altra rete, garantendo
cosı̀ l’omogeneità delle informazioni tra reti eterogenee.
7
2
Concetti generali
Di seguito verrano introdotti alcuni concetti fondamentali usati nella scrittura della tesi, riguardanti le reti di calcolatori, considerati essenziali per la
sua comprensione.
2.1
Rete di calcolatori
Una rete di calcolatori è costituita da un insieme di computer collegati tra
loro mediante un’infrastruttura che permette lo scambio reciproco di informazioni. L’infrastruttura è costituita da componenti hardware (cablaggi,
ripetitori, hub) e componenti software (sistemi operativi di rete) che forniscono gli strumenti per la gestione della rete stessa. Esistono vari tipi di reti
a seconda dalla loro estensione geografica:
• rete personale o PAN (Personal Area Network) se la rete si estende
intorno all’utilizzatore con una estensione di alcuni metri
• rete locale o LAN (Local Area Network) se la rete si estende all’interno
di un edificio o di un comprensorio, con una estensione entro alcuni
chilometri
• rete senza fili o WLAN (Wireless Local Area Network), se la rete locale
è basata su una tecnologia in radio frequenza (RF), permettendo la mobilità all’interno dell’area di copertura, solitamente intorno al centinaio
di metri all’aperto
• rete universitaria o CAN (Campus Area Network), intendendo la rete
interna ad un campus universitario, o comunque ad un insieme di edifici
adiacenti, separati tipicamente da terreno di proprietà dello stesso ente,
che possono essere collegati con cavi propri senza far ricorso ai servizi di
operatori di telecomunicazioni. Tale condizione facilita la realizzazione
di una rete di interconnessione ad alte prestazioni ed a costi contenuti
• rete metropolitana o MAN (Metropolitan Area Network) se la rete si
estende all’interno di una città
• rete geografica o WAN (Wide Area Network) se la rete si estende oltre
i limiti indicati precedentemente.
Tutti i nodi presenti sulla rete comunicano tra di loro per mezzo di uno o più
protocolli di rete.
8
2.2
Nodo di rete
Per nodo di rete si intende un dispositivo presente fisicamente sulla rete,
quindi un dispositivo hardware. I più frequenti sono l’hub, bridge, switch,
router, server, firewall, modem, client pc. Tutti i nodi possono interagire tra
di loro per lo scambio di dati ed informazioni, ma tutti rigorosamente per farlo
devono seguire un protocollo di rete. Ad esempio la rete Internet è governata
dal protocollo IP(Internet Protocol). Ogni dispositivo avente un indirizzo
IP è considerato host, ossia nodo di rete. Attraverso questo protocollo ogni
macchina sulla rete avrà un proprio indirizzo logico univoco, che consentirà
ad altri nodi l’identificazione per la comunicazione ed il trasferimento dati.
2.3
Protocollo di rete
Un protocollo di rete è definito come l’insieme di regole o meccanismi che
hanno la finalità di mettere in comunicazione due o più nodi presenti in una
rete. I protocolli di rete spesso si basano sul paradigma client-server. Ossia
un server che fornisce dei servizi ed un client che ne usufruisce. I diversi
protocolli di una rete sono organizzati con un sistema detto ”a livelli”: a
ciascun livello viene usato uno specifico protocollo. L’insieme di più livelli
e relativi protocolli definisce un’architettura di rete a strati, che altro non è
che un’astrazione delle funzionalità logiche della rete stessa.
Nella figura 2 sono mostrati i vari protocolli di rete per ciascun livello
dello strato protocollare.
2.4
Inter-rete
Per inter-rete si intende una rete formata a sua volta da reti collegate tra
loro. Solitamente le reti che compongono una inter-rete hanno protocolli e
dispositivi differenti dando cosı̀ origine ad una rete eterogenea. Una inter-rete
è rappresentata nella figura 1
9
Figura 2: Elenco di protocolli di rete secondo ISO/OSI
2.5
Paradigma Object-Oriented
Il paradigma orientato agli oggetti si riferisce ad una serie di concetti introdotti dai linguaggi di programmazione orientati agli oggetti. Nella presente
tesi il paradigma va inteso in due modi differenti: l’implementazione del
protocollo usa un linguaggio orientado agli oggetti, ossia il C++ e la progettazione del protocollo stesso segue il paradigma orientado agli oggetti. Tra
le varie caratteristiche dell’Object Oriented si citano:
Classe una rappresentazione astratta di un concetto avente delle caratteristiche(attributi e metodi)
Oggetto un’istanza di una classe avente una propria identità, rappresentante l’oggetto della classe stessa
Campi di istanza gli attributi che ogni oggetto istanziato possiede
Metodi delle funzioni che hanno il compito di manipolare gli attributi dell’oggetto istanziato
Incapsulamento la tecnica di nascondere il funzionamento interno di un
programma, principio cardine della ingegneria del software
10
Ereditarietà consente di definire una classe come sottoclasse o classe derivata a partire da una classe preesistente detta superclasse o classe base
La sottoclasse eredita implicitamente tutte le caratteristiche (attributi
e operazioni) della classe base.
2.6
Routing
Nelle reti a commutazione di pacchetto, il routing è il processo di instradamento dei pacchetti lungo una rete. Attraverso i protocolli di routing, i
dispositivi sulla rete realizzano l’instradamento dei pacchetti per inoltrarli al
corretto destinatario, passando per tutti i nodi intermedi della rete.
2.7
Tos e Qos
Tos Type of service. È presente nell’header del protocollo IPV4 e descrive il
tipo di servizio e la priorità richiesta per le informazioni contenute nel
pacchetto stesso.
Qos Quality of service. È soltanto un parametro di misurazione delle prestazioni di un sistema di comunicazione, e prende in considerazione
principalmente tre valori essenziali: latenza, percentuale di pacchetti
persi, variazione di latenza. In base a questi valori il Qos valuta la
qualità del servizio.
2.8
Pacchetto
Per pacchetto si intende una sequenza finita di dati trasmessi su una rete di
calcolatori. Il pacchetto viene creato da un nodo della rete come sorgente e
viaggiando per altri nodi della rete giunge al nodo di destinazione. La forma
del pacchetto è strettamente collegata al protocollo in uso, però solitamente
ogni pacchetto ha 3 componenti fondamentali:
Header l’intestazione che contiene tutte le informazioni necessarie alla trasmssione del pacchetto, affinchè arrivi a destinazione
Data o anche payload, contiene i dati utili trasmessi ossia il contenuto
dell’informazione
Checksum un codice di controllo utilizzato per controllare la corretta ricezione dei dati ovvero l’eventuale presenza di errori
11
2.9
Latenza
Nell’ambito delle reti di calcolatori si parla di latenza di trasmissione. Consiste nel tempo impiegato da un pacchetto per raggiungere un altro host della
rete. A seconda di alcuni fattori che influenzano la propagazione del segnale,
quali router, switch, cavi, la latenza ha un intervallo che va dalla latenza
minima a quella massima.
2.10
Throughput
Il throughput di un canale di comunicazione è la sua capacità di trasmissione
effettivamente utilizzata. Non è da confondersi con la capacità del canale:
sia la capacità che il throughput si esprimono in bit/s, ma mentre la prima
esprime la frequenza trasmissiva massima alla quale i dati possono viaggiare,
il throughput è un indice dell’effettivo utilizzo della capacità del link. Il
throughput è la quantità di dati trasmessi in una unità di tempo(in bit/s)
e dipende esclusivamente da quanta informazione è immessa sul canale nella
trasmissione.
2.11
Rete di sensori
Una rete di sensori è formata da un insieme di dispositivi elettronici chiamati sensori, in grado di rilevare grandezze fisiche dall’ambiente esterno come
temperatura, umidità, pressione, luce, ma anche capaci di rilevare il movimento di veicoli, la composizione del terreno, livello di rumore e molte altre
grandezze. È possibile classificare le applicazioni in cui si possono usare le
reti di sensori in militari, ambientali, sanitarie, casalinghe e commerciali. [6]
12
3
IDM per l’integrazione di reti eterogenee
3.1
Il protocollo IDM
Nell’introduzione al protocollo IDM verranno soltanto citati alcuni aspetti
generici, quali il funzionamento e l’ambito applicativo nel quale è stato pensato, descrivendo in linee generali la sua architettura. Questo capitolo tratta
del contesto e l’uso finale del protocollo IDM nell’ambito di reti eterogenee.
Verrà descritto in dettaglio il protocollo IDM con tutte le sue caratteristiche
e funzionalità. La vasta diversità di protocolli e tecnologie esistenti al giorno
d’oggi, rende difficile lo sviluppo di meccanismi per ottenere l’interoperabilità tra le varie applicazioni che vengono eseguite nei più disparati nodi delle
reti, perciò non è sempre possibile utilizzare lo stesso protocollo di rete. Un
esempio di questo problema è dato dall’accesso ai nodi di una rete di sensori.
Ad esempio questa tecnologia usa Bluetooth o Zigbee che sebbene possano
adoperare la pila TCP/IP, l’uso spesso richiedo uno sforzo considerabile e
non sempre si ottengono soluzioni ottimali, in termini di prestazioni. Soluzioni alternative possono essere l’utilizzo di hardware proprietario oppure di
protocolli specializzati. Per affrontare il problema, bisogna considerare due
casi molto importanti:
1. accesso da qualunque punto di una rete, ad una rete di sensori
2. interazione di due o più nodi con differenti tecnologie, inclusi tutti i
cammini intermedi di qualsiasi tipo
1 Considerando le esistenti soluzioni alternative per conseguire l’obiettivo
finale, la soluzione ottimale è senz’altro quella di usare un protocollo unico comune a tutte le reti, includendo uno schema di instradamento globale.
Ovviamente con ciò, non si pretende di sostituire il protocollo IP, però è possibile risolvere i problemi dell’uso della pila TPC/IP in alcuni ambiti di reti
eterogenee, ergo bisognerà costruire un protocollo non solo indipendente dalla rete, ma anche dal trasporto. Costruire un nuovo protocollo sopra il livello
di collegamento implica il reinventare la ruota, affrontando un problema già
risolto. L’alternativa più adeguata quindi è usare il protocollo o la pila che
risulta più naturale in ogni ambiente e costruire il protocollo omogeneizzante
in un livello superiore.
Le specifiche CORBA Message Routing [13] descrivono il percorso ideale.
Il middleware prevede un livello di astrazione sufficientemente consistente
per occultare i dettagli delle tecnologie software e hardware sottostanti. Si
può inoltre, implementare sopra una gran varietà di sistemi a patto che si
13
rispettino delle condizioni(in funzione del middleware). Riguardo le specifiche CORBA che risultano essere adeguate, ci sono anche dei punti su cui
focalizzare l’attenzione, poichè CORBA non soddisfa i seguenti requisiti:
1. i router non dispongono delle tabelle di routing che permettono di
costruire l’instradamento da un estremo all’altro, attraverso i router
vicini
2. non prevede di implementare una forma di instradamento dinamico che
permetta di stabiliare rotte alternative e successivi cambiamenti
3. le referenze ad oggetti possono avere dimensioni arbitrari. Quindi, dato
che possono contenere una quantità non delimitata di profili e componenti, che includono a loro volta la lista dei router possibili, il volume
di questi riferimenti può raggiungere con facilità migliaia di bytes
Ovviamente questi 3 punti non vanno considerati come errori di CORBA,
semplicemente il protocollo che si vuol costruire ha obiettivi differenti che
richiede quindi, specifiche e requisiti differenti. Nelle righe successive quindi,
si andrà ad introdurre il protocollo IDM ed i meccanismi associati per creare
un MDOO generale per incapsulare e trasportare messaggi come invocazioni
ad oggetto. Molti aspetti essenziali alla creazione del protocollo verràno
comunque presi dal protocollo IP e CORBA.
Ecco alcuni aspetti essenziali che andremo a considerare nel nuovo protocollo:
• Mantenere un sovraccarico sufficientemente basso per permettere l’eseguibilità delle applicazioni nella rete, soprattutto nei casi di basso
MTU. Inoltre un minor sovraccarico implica trasmettere meno bytes e
pertanto consumare meno energia
• Il protocollo deve essere sufficientemente generico a tal punto da permettere l’implementazione di algoritmi di routing dinamici
• Deve essere cross-layer, tale da permettere l’eliminazione di livelli o
prestazioni non necessari in funzione dei requisiti richiesti dal cliente
• Deve definire uno schema di instradamento universale, gerarchico. Il
instradamento universale, che può includere nodi di milioni di reti,
può implicare un alto instradamento del traffico. Perciò è necessario
arrivare ad un compromesso che soddisfi entrambi i requisiti proposti
Sia gli host di rete che i router che smistano il traffico di rete, verràno
trattati come oggetti distribuiti. Inoltre, il programmatore disporrà di due
possibili punti di vista quando dovrà progettare la sua applicazione:
14
1. un meccanismo trasparente per le applicazioni di tipo client, per mezzo
di un API simile a quella usata dai sockets in BSD
2. un riferimento ad un oggetto remoto (mediante proxy) sopra il quale
può invocare metodi conformi al suo tipo
3.1.1
Introduzione al protocollo IDM
IDM (Inter-Domain Messaging) è un protocollo che ha lo scopo di trasferire
messaggi verso diversi dispositivi usando protocolli e tecnologie di rete eterogenee. L’obiettivo principale è far comunicare vari network, ciascuno con
differenti dispositivi, anche da differenti provider di rete e usando tecnologie e protocolli incompatibili. Lo schema di indirizzamento è indipendente
dal livello fisico e logico sottostante, perciò è necessario tradurre gli indirizzi
IDM in indirizzi reali. Per far si che tutti i router IDM siano raggiungibili tra
di loro, anche se sono disposti in reti differenti con tecnologie incompatibili,
si usa un protocollo di scoperta di nodi chiamato ALP, cosı̀ facendo si evita
anche l’uso di un registro centralizzato. Ogni oggetto è rappresentato usando
un indirizzo IDM. Ci sono due modalità d’uso. La più semplice è basata sullo
metodo standard Socket-Like. Il server apre un socket in ascolto, sul quale i
client si connetteranno. I dati che usano questo modello sono semantic-less,
al fine di aumentare la flessibilità per le applicazioni che lo necessitano. Il
secondo caso d’uso è basato su RMI, dove i client e i server usano una interfaccia comune per comunicare. In questo modo, non c’è bisogno di cambiare
il codice delle applicazione che usano RMI al fine di utilizzare IDM, cosı̀ l’adattamento è facile e veloce. Dato che si usano protocolli eterogenei, ci deve
essere uno schema di indirizzamento uniforme. IDM assegna ad ogni oggetto un identificatore, il quale può anche essere unico se richiesto. L’oggetto
assegnato è rappresentato da una sequenza di bytes, formato da vari campi
contenenti le informazioni necessarie all’indirizzamento. Alcuni dei campi
possono anche essere omessi, se il nodo non è in grado di elaborarli. Tutto
ciò fa si che ci sia uno schema di indirizzamento di tipo gerarchico. Ci sono
molti scenari dove è richiesto porre in comunicazione differenti dispositivi,
ognuno da un diverso provider che può usare differenti tecnologie e protocolli. Ciò presenta un grosso probema, il quale può essere risolto applicando
l’uso del protocollo IDM. IDM usa un approccio orientato agli oggetti. I
dispositivi e i router sono modellati come fossero oggetti, usando un middleware standard. Ciò fa si che i messaggi inviati siano indipendenti sia dai
protocolli che dalle tecnologie differenti, facendo risultare la comunicazione
trasparente. Il prototipo attuale usa il middleware ZeroC Ice scritto in C++,
e in parte in Python. Ciascun nodo è trattato come oggetto Identity in Ice
15
Objectmmentre ciò che sta al di sopra si appoggia sul protocollo TCP/IP. I
risultati ottenuti dall’attuale prototipo verrànno discussi nella sezione 1. 7.
3.1.2
Inter-Reti
Si può analizzare il problema prendendo in esame la tipologia di rete più
diffusa, ossia Internet. Come la maggior parte delle reti, usa un protocollo
di rete unico in questo caso è IP. Uno schema globale di connessioni logiche
permette la interconnessione di reti con distinte tecnologie nel livello di collegamento e fisico. Pertanto, affinchè una rete possa far parte di una inter-rete
necessita il soddisfacimento di alcuni requisiti base:
• gli host devono conoscere lo schema di instradamento logico
• gli host devono poter creare e inviare pacchetti sopra la tecnologia di
rete sottostante
• nel caso in cui si tratti di un mezzo di diffusione, deve esistere un
meccanismoche permetta mappare il instradamento logico e fisico
• è necessario sempre un router che sia in grado di reinviare (forward)
pacchetti per reti differenti
In Internet, quando si vuole attraversare una rete che utilizza un protocollo di rete incompatibile, si ricorre al tunneling, ma ciò impedisce la creazione
di uno schema di routing omogeneo. Un altro problema evidente è inviare
dati ai dispositivi di questa rete, che hanno protocolli di rete incompatibili.
3.1.3
Routing omogeneo
L’obiettivo è la creazione di un servizio di trasporto di messaggi da estremo
ad estremo, indipendentemente dalle tecnologie di rete intermedie, sfruttando
i protocolli e le tecnologie disponibili in ogni dominio, al fine di non reimplementare funzionalità già rese disponibili. IDM non delega il instradamento
ai livelli inferiori, quindi si può delegare il routing. Ad esempio, in una rete
TCP/IP si possono incapsulare i messaggi sopra i pacchetti IP e delegare
il routing nei protocolli abituali. La combinazione di un middleware con la
possibilità di routing multiplo (cross-layer) da estremo a estremo, porta molti
vantaggi:
Instradamento Realmente globale e indipendente dalla tecnologia e dal
protocollo
16
Rete virtuale Possibilità del dispiego di reti virtuali sopra qualsiasi tipo di
rete esistente o futura
Qualità di servizio La possibilità di gestire al meglio l’informazione, ma
nel livello più alto
Flessibile Si adatta alle necessità di ogni applicazione. Usare un middleware di comunicazione non implica necessariamente un sovraccarico
di protocolli, né un aumento significativo della complessità
Servizi di piùttaforma Dato che si usa un middleware di comunicazione
generico, si possono sfruttare delle caratteristiche già incorporate in esso. IDM si basa su ICE, quindi è possibile usare la cifratura e l’autenticazione trasparente, supporto multi-lingua e molte altre caratteristiche
incluse in esso.
Trasparenza di localizzazione I router vengono trattati come entità logiche e per questo possono essere migrati o replicati ad altri noti di
rete
Routing funzionale Questa qualità permette di esporre gli schemi e gli
algoritmi di routing di base in raggruppamenti funzionali di nodi e non
solo su localizzazione geografica
Orientato agli oggetti Se il programmatore lo desidera, può vedere il server come un oggetto remoto e richiamare su di esso vari metodi, inoltre
è possibile usare delle API alternative con primitive read/write
3.2
Instradamento
Gli schemi di instradamento tradizionale, utilizzano una direzione logica che
identifica l’host, delegando l’identificazione dell’applicazione destinata, ai
protocolli del livello di trasporto. IDM usa uno schema di instradamento gerarchico, nel quale si riserva un suffisso per identificare l’applicazione. Queste
direzioni sono realmente identità di oggetti. Se si desidera un instradamento
globale, si può usare un qualsiasi schemda di identificatori che garantisca
l’unicità, chiamato GUID(Globally Unique Identifiers), e che permetta di
ottenere identificatori gerarchici. Benchè sia possibile, non è strettamente
necessario che la direzione identifichi l’host dove risiede l’oggetto.
Solo il cliente necessita conoscere l’identità dell’oggetto, che può essere
visto a tutti gli effetti come una direzione logica. Per giungere a capo della
trasmissione dei dati, si usa un endpoint. Il quale incapsula l’implementazione di trasporto sopra una tecnologia o anche un protocollo completo, tipo
17
Bluetooth, TCP, UDP, etc. La presenza dell’endpoint è realizzata dal router
in base alle restrizioni fornite dalla qualità di servizio specificata per il client
e dalla disponibilità delle interfacce fisiche del nodo nel quale risiede. La
trasmissione non può essere possibile se non vengono soddisfatti entrambi i
requisiti.
IDM è in grado di localizzare un endpoint senza conoscere la sua ubicazione, ma sfruttando il suo identificatore. Più concretamente, serve per
verificare l’endpoint dell’adattatore nel quale è registrato l’oggetto di destinazione.
18
3.2.1
Identità dell’oggetto
Dal punto di vista funzionale, l’identificatore dell’oggetto è una sequenza di
byte globalmente unica con due campi rilevanti:
Applicazione Identifica il servizio in uso, ad esempio un servizio di streaming, una rete P2P, Bluetooth, etc. Deve essere inteso come un filtro e,
per questo, il suo uso non è sempre obbligatorio. Questo campo può essere usato dai router per un trattamento speciale per alcuni tipi di messaggi che corrispondono ad una applicazione determinata, applicando
quindi la tecnica del traffic-shaping o priorità per contenuti.
Nome Identifica l’oggetto indipendentemente dall’applicazione. Come nell’Object Oriented, un oggetto dato ha lo stesso nome in tutte le applicazioni nel quale è presente, perciò è possibile che uno stesso oggetto
possa avere più di un nome, pertanto può avere varie identità incluse
nel contesto della medesima applicazione. È necessario quindi l’uso di
uno schema gerarchico, che rende il sistema flessibile e permette la trasmissione trasparente dai nodi e dai router. Per questo possono essere
presenti router in qualsiasi punto della rete, nonostante le delimitazioni
poste in reti diverse(ad esempio tra una LAN e Internet) è garantita la
interconnessione, che è l’obiettivo principale del protocollo IDM. [12]
3.2.2
Un esempio di instradamento
Per illustrare il sistema di instradamento si propone un esempio basato su
IPV6. Da considerare che IDM non vuole essere un sostituto del protocollo
IP, ma un protocollo generico per il trasporto di messaggi in applicazioni
distribuite.
Lo spazio di instradamento è diviso nei seguenti campi:
Applicazione(32 bits) Identifica una applicazione o rete logica concreta
Organizzazione(32 bits) Identifica l’entità responsabile o proprietaria dell’oggetto
Sezione(8 bits) Livelli organizzativi intermedi
Unità(8 bits)
Sottorete(16 bits)
Nodo(16 bits) Identifica un nodo logico dentro la rete. Lo stesso dispositivo ne può contenere vari
Oggetto(16 bits) Identifica un oggetto dentro al nodo
19
Figura 3: Esempio di instradamento
3.3
Endpoints
Un endpoint è una struttura logica indipendente che incapsula tutti i dettagli
di trasporto di dati per una tecnologia o protocollo sottostante. Non ci
sono differenze funzionali tra un EP che permette di aprire e mantenere una
connessione TCP su una VPN, rispetto ad un EP che invia dati SLIP tramite
un cavo RS-232. Le differenze stanno nelle prestazioni dell’EP, non nel suo
utilizzo.
L’EP è responsabile dei seguenti compiti:
• Costruire pacchetti IDM, serializzare e incapsulare l’invocazione dell’utente, calcolo del checksum, autenticazione, etc.
• Occultare tutti i dettagli in relazione con il protocollo o l’interfaccia di
comunicazione.
• Enumera le prestazioni di QoS che offre ogni trasporto e tecnologia
concreta.
ICE supporta 3 tipi di EP: TCP, UPD, SSL. In IDM ne sono stati aggiunti
due: Socket UNIX e Crossbow. Nella figura sottostante è rappresentata la
relazione di IDM con i livelli sottostanti nel modello di rete tradizionale.
Ogni EP presenta una rappresentazione testuale che specifica il protocollo di livello inferiore che è utilizzato, la direzione logica o fisica, o altre
informazioni necessarie per stabilire la connessione o l’invio dei dati.
20
Figura 4: Livello IDM
In IDM esiste un tipo di EP molto speciale che si incarica di anteporre
l’intestazione IDM, ai messaggi convenzionali del protocollo inter-OBR. Nel
caso di ICE, ciò semplifica l’uso di IDM sulla distribuzione software poiché
non si ha la necessità di modificare nulla nel codice.
IDM potrà utilizzare il protocollo inter-ORB per codificare i suoi messaggi, però ciò implica un sovraccarico di dati molto importante che risulta
problematico per MTUs di piccole dimensioni. Per questa ragione, è stato
definito un formato di intestazione (header) specifico. I campi usato sono i
seguenti:
1. magic sequence (3 bytes) Caratteri ’I’ ’D’ ’M’ 2. messageType (1 byte)
Tipo di messaggio 3. messageSize (4 bytes) Dimensione totale del messaggio
4. requestId (4 bytes) Realizza la corrispondenza col messaggio di risposta 5.
routerId (2 bytes) L’Id del router che reinvia il messaggio 6. dst (16 bytes)
L’Id dell’oggetto destinatario 7. src (16 bytes) L’Id dell’oggetto sorgente 8.
hopLimit (1 byte) Un contatore che il router incrementa in ogni hop. 9.
Tos (1 byte) Un codice che identifica il ToS. Il router applica un congiunto
di restrizioni di QoS ad ogni tipo di servizio. È molto simile al QoS del
protocollo IP. 10. Flow (4 bytes) Identifica una sequenza di messaggi che
condividono il profilo del QoS. 11. Mode (1 byte) Caratteristiche di invio
della invocazione: idempotente, oneway, twoway, risposta richiesta, etc
21
struct HeaderData {
byte magic_I, magic_D, magic_M;
byte messageType;
byte mode;
short messageSize;
int requestId;
byte routerId;
IDM: : Identity dst;
IDM: : Identity src;
byte hopLimit;
ToS tos;
int flow;
};
struct ForwardData {
string operation;
Encapsulation params;
};
struct ForwardMsg {
struct HeaderData;
struct ForwardData;
};
Il campo routerId non è una identità IDM completa. È presente solo
se richiede il suffisso(l’id dell’oggetto nel nodo)dato che il dispositivo che lo
ospita deve essere localizzato per altro mezzo. Quindi è un vantaggio che
vari router IDM(oggetti) convivano al tempo stesso con un nodo.
IDM supporta due tipi di messaggi:
Raw offre all’utente una API simile ai socket BSD per dargli la possibilità di
trasportare blocchi di dati senza nessun tipo di semantica né formato
User se si dispone delle specifiche dell’interfaccia dell’oggetto remoto, è possibile realizzare delle invocazioni sui metodi dell’oggetto remoto. Cosi
facendo, si realizza la serializzazzione e deserializzazione dei parametri,
verifica di tipo, gestione degli errori e delle eccezioni, etc
22
3.4
3.4.1
Le politiche del TOS e QOS
Quality of service
Nell’ambito delle telecomunicazioni, il termine Quality of Service viene utilizzato sia per far riferimento ai parametri utilizzati per caratterizzare la qualità
del servizio offerto (ad esempio delay, jitter, throughput, packet loss rate, etc.
) sia per indicare gli strumenti necessari a garantire la qualità di servizio desiderata. Il progetto originario dei protocolli di rete su cui si basa l’odierna
infrastruttura di Internet non percepiva la necessità di QoS per le applicazioni e, quindi, non prevedeva alcun supporto per tale funzionalità. Si parla in
questo caso di servizi offerti in modalità best-effort, il sistema garantisce di
fare tutto il possibile per portare a termine un’operazione, ma non garantisce
affatto che l’operazione verrà compiuta né tanto meno in che modo. Questo
modello funziona discretamente per tutte le applicazioni le cui performance
non risentono di prestazioni di rete particolarmente degradate, ma esistono
altre applicazioni che richiedono determinate condizioni per poter funzionare
correttamente, ad esempio la trasmissione dati relativa al traffico VoiP (Voice Over IP). Tale tipologia di traffico risulta essere estremamente sensibile
al ritardo con cui i pacchetti vengono ricevuti: il segnale vocale, prima di
essere trasmesso, subisce un’operazione di campionamento; tale operazione
consiste nel valutare, ad intervalli periodici, il valore del segnale in quel determinato istante (il campione appunto). Tali campioni vengono trasmessi e
successivamente ri-assemblati dal ricevente in maniera da poter ricostruire il
segnale originario. Qualora, però, alcuni pacchetti che contengono le informazioni sui campioni dovessero essere ricevuti con grosso ritardo, il segnale
ricostruito risulterebbe incomprensibile. Per questo motivo, per far funzionare un servizio di telefonia VoiP è necessario prevedere che questa classe di
traffico subisca un trattamento differente da altre classi: i requisiti in termini di throughput del traffico voce sono realmente minimali, ad esempio,
usando il codec G.711 PCM per la codifica del segnale vocale, la banda richiesta per una singola conversazione infatti di appena 64 Kbps (il valore fa
riferimento soltanto al payload applicativo) arriva ad appena 5.3 kbps per il
codec 6.723.1 ACELP. Di questo valore di banda minima richiesta per la singola conversazione, per quanto piccolo esso sia, si dovrà comunque ricordare
quando configureremo QoS per questa classe di traffico, per non trovarci nelle
condizioni di non poter garantire le condizioni minime necessarie affinchè la
conversazione avvenga. Si noti che si sono sommariamente definiti i requisiti
per una tipologia di traffico. Nella realtà il parametro realmente interessante è il massimo ritardo tollerabile perchè la qualità della conversazione non
risulti degradata. Esistono fondamentalmente due metodi per fornire garan-
23
zie sulla qualità di servizio. Il primo, detto overpro visioning, consiste nel
fornire risorse in abbondanza tale da soddisfare la domanda di picco attesa
con un sostanziale margine di sicurezza. Una soluzione sicuramente semplice,
ma poco scalabile, qualora le esigenze dovessero crescere più velocemente di
quanto predetto. L’alternativa sarebbe amministrare la banda disponibile,
facendo in modo che i pacchetti a cui deve essere garantita una certa QoS
ottengano un trattamento privilegiato rispetto ad altri. Per ottenere questo
risultato bisogna, però, prima di tutto identificare tali pacchetti e questa fase
non può prescindere da un’analisi dei requisiti necessari. Una volta identificati tali requisiti, si andrà ad applicare a questa classe di traffico una disciplina
di coda (queueing discipline) che garantisca le prestazioni richieste. I metodi strutturati per identificare il traffico da privilegiare (individuando quindi
delle classi di traffico) sono:
Integrated Services tale metodo è basato su un meccanismo simile a quello
di una normale prenotazione. Prima di iniziare una sessione con specifici requisiti di QoS, l’applicazione deve ”chiedere” alla rete se essa
puo garantire le prestazioni necessarie. La rete valuta se dispone delle
risorse adeguate e, in caso positivo, accetta la prenotazione. Tale meccanismo di signaling avviene attraverso Il protocollo RSVP (Resource
Reservation Protocol) definito nell’RFC 2205.
Differentiated Services contrariamente al modello Integrated Services, il
modello DiffServ ignora totalmente il concetto di sessione. Infatti quando un pacchetto arriva ad un nodo di ingresso ad un dominio DiffServ,
esso viene ”marchiato” mediante l’assegnazione di un valore opportuno nel campo DSCP, come vedremo nel seguito. Questo valore verrà
in seguito utilizzato da tutti i nodi del dominio DiffSery per determinare qua le comportamento o livello di GoS si applicano. E’ definito
nell’RFC 2474.
In un router che non applichi politiche di qualità di servizio, i pacchetti
vengono trasmessi dalle interfacce di uscita nell’ordine in cui essi sono arrivati (politica FIFO, First In First Out). Una disciplina di coda (queueing
discipline o brevemente qdisc) consiste essenzialmente nel gestire per ciascuna interfaccia diverse code in uscita in cui i pacchetti vengono classificati. La
qdisc stabilisce in quale ordine verrànno prelevati i pacchetti dalle varie code. Questa operazione, definita scheduling, potrebbe portare a decidere che
alcuni pacchetti devono essere trasmessi prima di altri a causa di specifiche
esigenze delta classe di traffico di appartenenza. Con riferimento al mondo
Linux, è opportuno fornire la terminologia di base per la gestione delle qdisc.
Un primo concetto fondamentale è quello di root qdisc. Tale qdisc ha un
24
ruolo estremamente importante in quanto essa è connessa direttamente al
device. Un altro concetto fondamentale da chiarire subito è la differenza tra
classless e classfull qdisc. Si definisce classless una qdisc che non preveda
”classi” (cioe ulteriori suddivisioni) al proprio interno, mentre una classfulll
qdisc le può prevedere. Cerchiamo di capire meglio i concetti appena presentati mediante un esempio: in figura 5 viene mostrata una gerarchia di
classi.
Figura 5: Gerarchia di classi in QoS
Si osserva che ogni qdisc e class sono caratterizzate da un handle costituito da un major number e un da un minor number. La root qdisc ha handle
1:0 abbreviato in 1: . I pacchetti vengono inseriti in coda e prelevati soltanto
dalla root qdisc, che è l’unico elemento con cui il kernel si interfaccia, affidandogli i pacchetti per la classificazione. Quando, poi, il kernel ritiene che sia
giunto il momento di dare ad un’interfaccia la possibilità di trasmettere, esso
richiede alla root qdisc i pacchetti da passare all’interfaccia di rete, che poi
si occuperà della trasmissione vera e propria. Una classfull qdisc può avere
molte classi ed ogni classe può essere figlia della qdisc o di un’altra classe,
come ad esempio 1: 10, 1: 11 e 1: 12 in figura 5. Una leaf class (classe foglia)
e una classe priva di classi figlie. Quando il traffico entra in una classfull
qdisc, esso deve essere inviato a una delle sue classi interne (classificazione):
per determinare in quale, vengono consultati i cosiddetti filtri. Vedremo nel
seguito che quando si crea una classe, viene creata una qdisc FIFO che può
25
essere rimossa dall’aggiunta di una classe minore o sostituita con un’altra più
idonea. Per il momento ci interessa comprendere la logica di una classfull
qdisc.
3.4.2
Type of service
È da riconsiderare l’header IP e in particolare il campo Type of Service.
Questo ottetto può essere interpretato, per motivi storici, in due maniere
differenti: le specifiche del protocollo IP vengono definite nell’RFC 791 nel
Settembre 1981. In questo documento si legge testualmente ”The type of
service (TOS) is for internet service quality selection. The type of service is
specified along the abstract parameters precedence, delay, throughput, and
reliability. These abstract parameters are to be mapped into the actual service parameters of the particular networks the datagram traverses”. In base a
quanto definito, il campo Precedence fornisce un’indicazione dell’importanza del pacchetto. In particolare, esso si presta a vari utilizzi (e conseguenti
priorità). Il più basso livello di priorita definito nelle specifiche prende il
nome di routine traffic, ma altri possibili utilizzi sono network control traffic
e routing traffic. Nella realtà, questo field non ha mai trovato alcuna applicazione pratica per il semplice motivo che da principio i router e le prime
implementazioni degli UNIX di quegli anni non lo supportavano. In seguito,
al crescere della complessità delle reti, i vendor hanno sviluppato maniere alternative per gestire la qualità del servizio basandosi sull’analisi degli header
(sia a network che a transport layer).
3.4.3
Class queueing discipline
La queueing discipline non è configurabile con ulteriori suddivisioni interne
per cui risulta essere il caso più semplice in assoluto.
3.4.4
Pfifo fast queueing discipline
Conviene analizzare pfifo fast, per almeno due ragioni: la prima perchè essa
è la qdisc utilizzata di default su qualsiasi scheda di rete; la seconda poichè
non è difficile da configurare, dato che non offre alcuna opzione di configurazione. Questa qdisc è, come dice il nome, basata su una coda FIFO (First
In First Out). Come accennato in precedenza, una FIFO ha la caratteristica
che un pacchetto ricevuto viene messo in coda agli altri pacchetti ricevuti in
precedenza e viene trasmesso subito dopo essi, rispettando l’ordine di arrivo. Questo dovrebbe significare che nessun pacchetto riceve un trattamento
particolare, anche se spesso ciò non avviene, a causa delle cosiddette bande.
È opportuno prendere confidenza con tc, che analogamente a ip, fa parte
26
della suite iproute2. La sintassi è molto simile come possiamo facilmente
osservare.
Figura 6: Mappatura delle varie tipologie di traffico nelle bande messe a
disposizione della qdisc pfifo fast
La qdisc utilizzata è proprio la pfifo fast come mostrato anche da ip, ma
i parametri mostrati sono ancora piuttosto oscuri. La qdisc mostrata è una
root qdisc e quindi è direttamente agganciata al device eth0. Nell’output di
tc, si fa riferimento a tre bande e ad una priomap. Le tre bande in questione
(definite banda 0, 1 e 2) sono, a loro volta, delle code FIFO gestite secondo
priorità crescente. Questo significa che fino a quando ci sono dei pacchetti
nella banda 0, le bande 1 e 2 non vengono processate. Quando la banda
0 è vuota, si passa a gestire la 1 e soltanto quando le altre sono vuote si
passa a gestire la 2. Inoltre, all’interno di ciascuna banda si applica una
logica FIFO pura, ossia il primo pacchetto ricevuto viene trasmesso senza
ulteriori elaborazioni. Chi decide in quale banda va collocato un pacchetto
è il kernel, che onora il field Type of Service presente all’interno dell’header
IP del pacchetto, avvalendosi della priomap. Nella tabella vista in precedenza, la seconda colonna contiene 1 valore (decimale) dei 4 bit del campo
ToS mentre la terza colonna indica il loro significato. La quarta colonna
indica, invece, come il kernel interpreti questi 4 bit mostrandone la priority.
L’ultima colonna, infine, traduce questa priority in una delle tre bande di cui
si parlava in precedenza. La logica che governa l’assegnazione è molto semplice: prendiamo ad esempio la priority 6 (Interactive). E’ semplice capire
che, poichè i1 traffico interattivo deve avere precedenza su altre tipologie di
traffico, esso deve necessariamente essere mappato nella banda 0. Facendo
riferimento alla tabella si vede, inoltre, che, in base alla Linux priority, un
pacchetto ha priority 2 (Bulk) se il flag Maximize Throughput è impostato e
27
che un pacchetto ha priority 6 (Interactive) se il flag Minimize Delay è impostato e il flag Maximize Throughput non lo è. Per completezza, è opportuno
sottolineare come RFC1349 fornisca le seguenti indicazioni per lo sviluppo
di alcune applicazioni di rete. Esistono delle varianti della qdisc pfifo fast e
sono le qdisc pfifo e bfifo, che altro non sono che qdisc basate su FIFO queue,
ma senza l’utilizzo di bande. Non hanno grande utilità pratica rispetto alla
pfifo fast se non per il fatto che mantengono statistiche sul traffico e possono
quindi tornare utili in fase di analisi di dettaglio dell’utilizzo di una rete.
3.4.5
Token bucket filter queueing discipline
Token Bucket Filter (d’ora in poi brevemente TBF) è una qdisc estremamente
semplice che consente di limitare il rate di trasmissione dei pacchetti entro un
determinato valore consentendo, eventualmente, burst di traffico addizionali
qualora non ce ne siano le condizioni.
Figura 7: Token bucket filter queueing discipline: i token arrivano a cadenza
regolare ed ogni pacchetto inviato ne consuma uno
L’immagine 7 mostra un secchio (bucket) in cui vengono inseriti dei gettoni (token) ad un ritmo di inserimento costante (token rate). Il secchio è
inoltre caratterizzato da una dimensione (bucket size) definita come il massimo numero di gettoni che esso può contenere. Qualora si provi ad inserire
28
nel secchio un numero di gettoni superiore alla dimensione massima, tali
token deborderebbero e verrebbero persi, proprio come accadrebbe per un
secchio vero e proprio, a ciascun gettone corrisponde un pacchetto. Con questa immagine davanti agli occhi, il funzionamento di TBF è molto semplice
da comprendere. Infatti, ogni pacchetto da trasmettere viene associato a un
token e, quando viene trasmesso, viene tolto dal secchio, come se ci fosse un
buco sul fondo. A questo punto, si capisce che ci possono essere tre possibili
scenari:
1. i pacchetti arrivano al TBF ad un rate uguale al token rate
2. i pacchetti arrivano al TBF ad on rate inferiore al token rate
3. i pacchetti arrivano al TBF ad un rate superiore al token rate
Ogni pacchetto da trasmettere ha sempre a disposizione un token, quindi
”scivola via” insieme al gettone e viene trasmesso senza alcun ritardo. Ogni
pacchetto da trasmettere ha sempre a disposizione un token e quindi viene
trasmesso senza alcun ritardo, ma con una differenza: essendo il token rate
superiore al data rate, i token cominceranno ad accumularsi ed a riempire il
bucket, fino eventualmente a debordare (ricordiamo che i token che debordano vanno persi). I token accu mulati possono essere ancora utilizzati qualora
ci sia un burst (ossia molti pacchetti da trasmettere in breve tempo). La
presenza di tali token, infatti, può consentire anche un rate di trasmissione superiore al token rate per un periodo di tempo limitato fino a quando
almeno il bucket tornerà vuoto. Si noti comunque che un eventuale burst
è limitato e controllato come entità proprio dal bucket size. Maggiore è la
dimensione del bucket, maggiore il numero di token che si possono accumulare, maggiore l’entita del burst. Nello scenario 7, invece, a un certo punto
il secchio sarà vuoto. In questo caso, i pacchetti da trasmettere verranno
posti nella coda di trasmissione in attesa dell’arrivo di nuovi token. Qualora
la coda di trasmissione dovesse riempirsi, i successivi pacchetti verrebbero
scartati. Dalla descrizione dell’algoritmo alla base di TBF, si capisce come
questa qdisc possa essere utilizzata molto efficacemente per limitare il rate
di trasmissione e consentendo anche eventualmente burst di trasmissione di
entità configurabile. E’ opportuno inoltre precisare che nell’implementazione
di Linux, i token corrispondono a byte e non a pacchetti. Vediamo a questo
punto un esempio di configurazione di TBF in Linux. Per comodità i parametri disponibili per la configurazione di TBF sono consultabili con man
tc-tbf.
# tc qdisc add help Usage:
29
tc qdisc [ add 1 del 1 replace 1 change 1 show ]
dev STRING handle QHANDLE ] [ root 1 ingress 1 parent CLASSID ]
[ estimator INTERVAL TIME_CONSTANT ]
[ stab [ help 1 STAB OPTIONS] ]
[ [ ODISC_KIND ] [ help 1 OPTIONS ] ]
tc qdisc show [ dev STRING ] [ingress]
Where: ODISC_KIND : = [plb]fifo 1 tbf 1 prio 1 cbq 1 red 1
try tc qdisc add <desired ODISC_KIND> help STAB OPTIONS : =
try tc qdisc add stab help
Successivamente
tc qdisc add dev ethe root tbf rate 6. 5mbit burst Skb
\ latency nms peakrate 1mbit minburst 1546
Il comando in questione aggiunge al device eth0 una qdisc TBF come root
qdisc. Il parametro rate indica il token rate e questo rappresenta il valore a
cui stiamo limitando il traffico (si parla anche di shaping). In questo caso il
suo valore è stato fissato a 0.5 Mbit/s. Il parametro burst (talora indicato
con il nome buffer o anche maxburst) rappresenta il bucket size espresso
in byte. Si tenga presente che shaping rate maggiori richiedono un buffer
più grande. Indicativamente, si assuma che per shaping rate di 10Mbit/s, è
necessario disporre di un buffer di dimensione almeno pari a 10 Kbyte se si
vuole raggiungere un rate desiderato in quanto, se il buffer è troppo piccolo,
si corre rischio che i pacchetti possano essere scartati. Il suo valore, nel
nostro caso, è fissato a 5Kbyte. Per quanto riguarda i parametri latency e
limit 1 il discorso è più complesso. Infatti, tali parametri servono a limitare
H numero di byte che possono essere accodati nell’attesa che nuovi token
diventino disponibili.
# tc qdisc add dev ethe root tbf rate lmbit
\ burst 20kb limit 30kb
È impostato il bucket size a 20Kbyte. Il parametro limit dice che, in attesa di nuovi token, la coda TBF può ospitare al massimo 30Kbyte. Questo
significa che, a regime, potranno essere presenti nella coda (limit - burst)
byte ossia 10Kbyte che quindi sperimenteranno una latenza dovuta alla dimensione della coda e del rate di trasmissione. È possibile, in alternativa,
impostare il parametro latency che indica il tempo massimo di permanenza
in coda di un pacchetto. Il calcolo tiene conto del bucket size, del rate ed
eventualmente del peakrate (se impostato); è possibile stimare latency con
la formula (limit - burst) / rate. Qualora si desiderino limitare eventuali
30
picchi di trasmissione raggiungibili nei burst, si possono usare peakrate e
minburst. Il primo rappresenta il massimo rate di trasmissione raggiungibile
in presenza di burst ed e utile per limitarne la dimensione soprattutto se il
bucket size e grande. Nel nostro caso esso impostato a 1Mbit/s. Il parametro minburst specifica la dimensione del peakrate bucket che dovrebbe essere
sempre settato all’MTU dell’interfaccia. Si veda la pagina man per ulteriori
dettagli. A cosa serve questa configurazione?Se si dispone di un dispositivo di rete con una coda di grandi dimensioni (ad esempio un modem DSL)
è facile rendersi conto che il traffico in upload può distruggere totalmente
l’interattività, perchè tale traffico tende a riempire la coda del modem (che
è spesso enorme in quanto questo aiuta a conseguire buon throughput in
upload). Se la coda del modem non fosse troppo grande, i pacchetti relativi
ad applicazioni interattive non dovrebbero aspettare molto tempo per essere
trasmessi e l’interattività non ne sarebbe danneggiata. Con questa configurazione si sposta la coda nel kernel di Linux, dove è possibile controllarla al
meglio. Quindi impostiamo il rate alla velocita di uplink e salvaguardiamo
l’interattività delle nostre applicazioni.
3.4.6
Stochastic fairness queueing discipline
Stochastic Fairness Queueing (SFQ) una semplice implementazione di un
algoritmo di accodamento estremamente fair (corretto, onesto). E’ meno accurato rispetto ad altri, ma richiede anche minori sforzi per la configurazione.
Si basa sul concetto di flusso, che corrisponde in gran parte a una sessione
TCP o a uno stream UDP. Il traffico viene suddiviso in un numero abbastanza grande di code FIFO, una per ogni flusso e, successivamente, inviato
secondo una logica round robin, ossia dando ad ogni sessione la possibilità di
inviare i dati a sua volta a rotazione. Questo porta ad un comportamento,
appunto fair (corretto), non permettendo ad alcun singolo flusso di bloccare
gli altri. SFQ si chiama stocastico perchè, in realtà, esso non assegna una
coda per ogni sessione, ma divide il traffico in un numero limitato di code
con un algoritmo di hashing. A causa di una potenziale collisione tra hash,
sessioni multiple potrebbero finire nella stessa e questo potrebbe dimezzare
la possibilità di ogni sessione di inviare un pacchetto. Per evitare che ciò
accada, SRI cambia il suo algoritmo di hashing molto spesso in modo che,
qualora due sessioni vadano in collisione, che possa accadere per un intervallo
di tempo molto limitato. E’ importante sottolineare che SFQ è estremamente utile soltanto nel caso in cui la coda dell’interfaccia di uscita sia piena
al limite delle sue capacità. In tal caso, esso è infatti in grado di garantire
fairness a tutte le sessioni presenti. Qualora invece la coda fosse scarica,
l’applicazione di SFQ non avrà grossi effetti.
31
3.4.7
Prio queueing discipline
La PRIO qdisc non fa shaping, ma si limita soltanto a suddividere traffico
in maniera motto simile a quanto fa pfifo fast con la differenza che essa non
utilizza una semplice FIFO per ogni classe di traffico. Quando un pacchetto
viene accodato alla qdisc PRIO, viene identificata la classe di appartenenza
sulla base dei filtri specificati. Per impostazione predefinita, vengono create
tre classi che di default contengono delle FIFO qdisc pure senza alcuna struttura interna, ma è possibile sostituirle con qualsiasi qdisc. Ogni volta che un
pacchetto deve essere trasmesso, si prova prima con classe 1 mentre le classi superiori sono utilizzate solo se tutte quelle inferiori sono vuote. Questa
qdisc è molto utile nel caso in cui si voglia dare priorità a determinati tipi
di traffico senza utilizzare del flag TOS, ma sfruttando a pieno la potenza
dei filtri. È inoltre possibile aggiungere un’altra qdisc alle classi predefinite,
mentre pfifo fast è limitato a qdisc FIFO come visto in precedenza.
Figura 8: Scenario possibile
tc qdisc add dev ethe root handle 1:
prio
Questo comando crea le classi 1: 1, 1: 2, 1: 3 che, per default, vengono
associate rispettivamente alle bande 0, 1 e 2, ma il numero di bande (e di
32
classi) è modificabile mediante il parametro bands. In tal caso, andrà modificata anche la priomap, che ormai conosciamo bene. Leggendo la pagina
man di tc-prio(8) si nota che le bande 0, 1 e 2 hanno di default lo stesso
comportamento delle bande nella pfifo fast. Alla luce di questa osservazione,
si capisce che it traffic Filler e Bulk verrà gestito dalla qdisc 30: , it traffico
Best-Effort ed Interactive Bulk verrà gestito dalla qdisc 20: mentre il traffico
Interactive verrà gestito dalla qdisc 10: . Anche pfifo fast andrebbe considerata classfull in quanto dotata di una suddivisione interna in classi, ma con
una differenza sostanziale: pfifo fast non è configurabile e quindi le bande
sono hardcoded. Per quanto riguarda PRIO, non solo è possibile specificare
un numero di classi (e bande) diverso da 3, ma è anche possibile specificare con estrema granularità che tipologia di traffico finirà in ciascuna classe
(mediante i filtri) e quale sarà il loro comportamento (mediante le qdisc).
[11]
3.5
Gestione della qualità di servizio
I requisiti di QoS necessari sono specificati nel momento in cui si richiede
l’accesso all’oggetto remoto. Alcuni di essi, come la cifratura o l’autenticazione, possono stabilirsi da estremo ad estremo, ma altri come la larghezza
d banda devono seguire tutta la rotta. Listiamo ora, alcuni parametri che
sono stati considerati:
• Invocazioni oneway/twoway
• Conferma di ricezione messaggi
• Ordinamento dei messaggi
• Autenticazione
• Autorizzazione
• Latenza massima
• Larghezza di banda minima
Il client deve anche notificare quando non è possibile soddisfare nessuno
di questi requisiti. Richidere quindi una politica ristretta può implicare
l’impossibilità di terminare la comunicazione.
33
3.6
Invio messaggi
IDM è concepito come un protocollo di rete, in modo che si affrontino gli
stessi problemi di tutti i protocolli di rete, con la differenza di risolverli in un
livello di astrazione differente: sopra il middleware, al di sopra del livello di
collegamento. Un problema di base in un protocollo di rete è la descrizione
dei meccanismi di invio di messaggi, sia negli host vicini che in quelli più
esterni. Sono stati elaborati due modelli di invio di messaggi: l’invio diretto
e l’invio indiretto.
3.6.1
Invio diretto
La ricezione diretta è il modo più semplice per ricevere messaggi dal client
al router o all’oggetto invocato. Per realizzare tutto ciò, è necessario selezionare gli EP dei quali si dispone e l’adattatore al quale appartiene l’oggetto
destinato e poi comprovare se l’host cliente è in grado di raggiungere qualche EP compatibile. Una rete IDM è un congiunto di oggetti direttamente
raggiungibili per mezzo di un tipo di EP. Non c’è una relazione tra la rete
IDM e la rete fisica alla quale è connesso l’host. Nello scenario più semplice i
router IDM sono posti solo ai margini delle reti, che tra loro hanno tencologie
e protocolli incompatibili.
Figura 9: Scenario possibile
Ciò proporziona la connettività all’interno di tutti gli oggetti e dei client
IDM, però ci sono altri usi possibili, per esempio in una rete MANET tutti
i nodi sono router IDM.
Per conoscere gli EP i router, come detto in precedenza, sfruttano il
protocollo ALP. È un protocollo generico di scoperta di oggetti vicini, però
34
assume che gli attori siano oggetti accessibili mediante IDM. Ogni nodo della
rete IDM deve disporre di un demone locale chiamato Servizio ALP, il quale
implementi l’interfaccia ALP: : Locator. Mediante l’invocazione del metodo
lookup e l’identità del nodo destinatario, il nodo client ottiene un proxy,
che permette realizzare invocazioni direttamente sopra l’oggetto remoto. Da
notare che è possibile localizzare solo EP di adattatori vicini, quindi della
stessa rete IDM.
Esistono varie forme per implementare il servizio ALP. Per la creazione
del prototipo ne sono state considerate due.
• Un servizio distribuito che permette a qualsiasi host di interrogare il suo
segmento di rete sull’esistenza di un oggetto concreto. Questo servizio
usa i meccanismi multicast e broadcast. Il servizio in ogni nodo deve
attendere i messaggi request() e deve rispondere attraverso i messaggi
reply(). Questi messaggi appartengono all’interfaccia IDM: : ALP: :
Lookup.
• Utilizzare le caratterische di indirezione incorporate nel middleware.
In ICE la indirezione degli oggetti si consegue attraverso un servizio
chiamato Ice Locator. IDM dispone di un adattatore per utilizzare
IceGrid: : Locator con un sovraccarico minimo. Ciò risulta molto utile
nei segmenti grandi di reti virtuali e quando gli host dispongono di
sufficienti risorse di calcolo per eseguire un nodo IceGrid. Ovviamente
ci sono degli svantaggi rispetto al modello precedente: tutti gli host
devono conoscere dal proprio avvio, la referenza remota di almeno una
delle risposte del Locator e verificare che ci sia un EP compatibile con
essa.
In ambo i casi, gli host che desiderano interagire con gli oggetti devono
essere registrati nel servizio ALP affinchè possano essere raggiunti per altri
nodi, indipendentemente se siano stati implementati attraverso IceGrid Locator o per il proprio host. Entrambi i meccanismi possono coesistere nella
stessa rete.
3.6.2
Invio indiretto
Si utilizza la ricezione indiretta per quegli oggetti che non sono raggiungibili
attraverso nessun EP del client. In questi casi è necessaria la mediazione di
almeno un router. Da notare che ci può essere un caso speciale. Pur esistendo
accessibilità diretta per mezza di un EP, è possibile che le restrizioni QoS
impediscono il suo uso e lo obbligano ad utilizzare uno o vari router per
arrivare alla destinazione.
35
Figura 10: Il nodo in IDM
36
Router
Router
Router
Router
Row NetA
Row NetA
Row NetB
Row
*
Subnet1
Subnet2
*
*
=
tcp
=
tcp
= udp, tcp
=
tcp
*
*
NetA. Subnet1. R2
NetA. Subnet2. R1
Tabella 1: Tabella di routing
Nell’immagine è illustrato il concetto di nodo secondo il protocollo IDM.
Un nodo non è visto(come si è abituati a concepirlo) come un semplice host
di rete, ma come un insieme di oggetti che interagiscono tra di loro. Ad
esempio il nodo stesso fa da client, proxy, router ed EP.
3.7
Routing
Tutti i nodi che formano una parte di una inter-rete IDM richiedono una
tabella di routing che determini se la ricezione dei messaggi possa realizzarsi
in forma diretta, oppure se necessita un router. Anche questo è un oggetto
convenzionale distribuito, simile ai nodi server;la differenza principale è che
può accettare e redirigere messaggi che non sono diretti direttamento verso
se stesso. Nella figura seguente è mostrato un tipico esempio di tabella di
routing. Sono stati usati degli identificatori testuali per rendere migliore la
leggibilità:
• Gli oggetti con prefisso NetA. Subnet1 oppure NetA. Subnet2 sono
raggiungibili direttamente(ricezione diretta)
• Gli oggetti con prefisso NetB sono raggiungibili attraverso il router
NetA. Subnet1. R2
• I restanti oggetti devono usare il router NetA. Subnet2. R3
Ogni riga della tabella di routing include una lista di tipi di EP che si
possono utilizzare per connettersi ad oggetti della rete. Questo perchè ogni
rete IDM è costituita da una o più reti fisiche compatibili, che usano lo stesso
protocollo. Per utilizzare il meccanismo ALP di una rete IDM è necessario
conoscere almeno un tipo di EP compatibile con la rete stessa.
3.7.1
Routing dinamico
Dato che i router sono oggetti distribuiti, risulta relativamente semplice implementare algoritmi di routing dinamico di qualsiasi tipo. Ogni messaggio
37
del protocollo di routing si definisce come un metodo dell’oggetto nell’interfaccia specificata. Per supportare un nuovo protocollo di routing è sufficiente
implementare l’interfaccia corrispondente. Per questo è molto semplice e
veloce implementare nuovi protocolli di routing dinamico nello stesso nodo.
3.7.2
Gestione della rete
Visto che i router e i server sono oggetti convenzionali distribuiti, è possible utilizzare i servizi standard per interfacciarli col middleware. Per questo si conseguono molte funzionalità, alcune tipiche di una piùttaforma di
gestione di rete, però con sovraccarico minimo e totalmente integrato nel
funzionamento della propria rete. Le funzionalità sono le seguenti:
Pianificazione molto vantaggiosa poiché è possibile disegnare la topologia
della rete, analizzare le necessità e i requisiti della rete e gli utenti, quantificare i costi e il mantenimento, tuttò ciò prima di disporre fisicamente
degli host di rete e di tutti gli strumenti che la compongono.
Monitorizzazione/contabilità È possibile valutare il rendimento del sistema in conseguenza delle prestazioni, larghezza d banda disponibile/consumido, latenza e molte altre variabili di un modo sencillo in
ogni router e server della rete.
Gestione della configurazione Quando si dispone di nuovi versioni del
software, può essere comunicato ai router, includendo implementazioni
o migliorie dei protocolli di routing. Anche è sencillo aggiungere interfacce di amministrazione, definizione di priorità, politiche di sicurezza,
etc.
3.8
Integrazione con il middleware
Uno degli obiettivi prioritari è l’integrazione del meccanismo di routing con il
middleware. Per il programmatore, le differenze tra l’uso di un oggetto IDM
e un oggetto distribuito convenzionale devono essere minime. Per questo
motivo, il reinvio dei messaggi utilizza unicamente i router e non comporta
l’interazione di questo, con i client e gli oggetti. Quando un client desidera
fare una invocazione ad un oggetto remoto IDM, utilizza una classe speciale per ottenere un proxy al suo router locale(situato nello stesso nodo del
client). Il client realizza l’invocazione usando questo proxy come se si trattasse realmente dell’oggetto remoto. In seguito si illustra in dettaglio il processo
38
Figura 11: Invocazione dell’oggetto remoto
completo per realizzare una invocazione ad un oggetto IDM remoto coinvolgendo alm meno un router intermedio, potenzialmente il client e l’oggetto
destinatario possono incontrarsi in una rete tecnologicamente distinta.
Il router locale può ricevere invocazioni destinate a qualsiasi oggetto. Se
l’identità destinataria coincide con la propria, processa il messaggio;in caso
contrario, reinvia il messaggio verso il destinatario. Quando un router riceve
una invocazione di un client locale, realizza i seguenti passi:
1. Se il tipo di messaggio richiede una risposta, alloca nel suo spazio di memoria un oggetto di callback per poter ricevere la risposta. La referenza
a questo oggetto è quella che nell’header del pacchetto è denominata
src.
2. Costruisce il messaggio secondo il formato della struttura ForwardRawMsg o ForwardUserMsg a seconda del tipo dell’invocazione fatta dal
client.
3. Consulta la sua tabella di routing e determina l’identità del seguente
router e degli EP che dispone.
4. Filtra gli EP secondo l’informazione QoS di ognuno, in relazione al
ToS al quale corrisponde l’invocazione precedente del client. Se non
ne incontra nessuno, ritorna al client un’eccezione e interrompe la
comunicazione.
5. Utilizza il servizio ALP per determinare l’informazione di instradamento del protocollo inferiore al quale corrisponde.
6. Utilizza l’EP per inviare il messaggio forward al router successivo.
39
Il router intermedio è quello che riceve i messaggi forward provenienti
da qualunque altro router. In questo caso il procedimento di lavoro include
unicamente i punti 3 e 6 .
Il router finale deve incaricarsi di inviare l’invocazione direttamente agli
oggetti destinati. Nel seguente modo:
1. Riceve un messaggio forward e confronta la sua tabella di routing per
determinare se il destinatario è l’oggetto remoto al quale va spedito il
messaggio.
2. Mediante ALP ottiene gli EP dell’oggetto destinatario. Se nessuno di
essi fosse compatibile con i requisiti QoS, allora si genera una eccezione
rivolta all’oggetto src.
3. A partire dal contenuto del messaggio forward, si crea un messaggio di
invocazione convenzionale.
4. Esegue l’invocazione direttamente sul client. Può essere sincrona oppure no, dipende dal tipo di messaggio e dall’EP utilizzato.
5. Se la invocazione è sincrona e si ha la risposta, il router procede con gli
stessi passi che si sono descritti per il router locale, però utilizzando la
referenza src contenuta nel messaggio forward.
Quando la risposta arriva all’oggetto temporaneo creato dal router locale,
questo crea una risposta secondo il formato del protocollo inter-ORB e lo
invia al client per la stessa connessione che è stata stabilita per realizzare
l’invocazione. Il client è stato bloccato durante tutto il processo a meno
che utilizzi meccanismi AMI proporzionati per il middleware. I qualificativi
locale, finale, intermedio non determinano i tipi di router, bensı̀ ruoli. Tutti i
router possono assumere qualsiasi di questi ruoli. La distinzione fatta è a solo
scopo di semplificazione della leggibilità dello schema proposto. È da notare
che a differenza di CMR, si assume che tutto il nodo che contiene i client
ha un router locale, il quale è l’unico che riceve le invocazione direttamente
dai client. Cioè, un client non può effettuare invocazioni convenzionali(quindi
non IDM)su router che sono presenti al di fuori del suo nodo. Dunque questo
implica un salto in più, migliora la scalabilità del sistema dato che i router
devono immagazzinare oggetti callback per i loro client. In questo modo,
è molto semplice dimensionare le necessità di memoria e processamento del
nodo, e i router senza client ne oggetti possono essere molto più semplici
poiché sono progettati per essere esenti da questo compito.
40
Latenza
Socket ICE
(Twoway)
Local
23
31
Remote(direct)
268
274
Remote(1 IP hop)
312
360
Remote(1 IDM hop) N/A N/A
(Oneway)
Local(oneway)
Remote(direct)
Remote(1 IDM hop)
8
76
N/A
13
98
N/A
IDM
32
278
384
2537
15
112
1049
Tabella 2: Latenza su Socket, ICE, IDM
3.8.1
Prototipi e risultati
Sono stati sviluppati dei prototipi per illustrare le potenzialità di IDM. I
risultati del prototipo sono stati comparati con Ice e i socket TCP/UDP.
I seguenti risultati sono stati ottenuti su un calcolatore Intel Core Duo 2.
33Ghz, 100Mbps Ethernet NIC e sistema operativo Debian GNU/Linux. Il
codice è stato scritto con ZeroC Ice versione 3. 3 e compilato con GNU GCC
versione 4. 3 Lo scopo di questi test è provare che le performance di IDM
non si discostano molto dai risultati attesi.
41
Throughput
Socket ICE
IDM
Local
292
365
485
Remote(direct)
42394 43051 43276
Remote(1 IDM hop)
N/A
N/A 98291
Remote(2 IDM hops) N/A
N/A 101265
Tabella 3: Throughput su Socket, ICE, IDM
È da notare che tutti gli EP usati nel test usano TCP. Quando saranno
disponibili maggiori EP idonei, sarà possibile ottenere risultati migliori di
TPC e di ICE in molti casi. Ad esempio, con le adeguate applicazioni e
requisiti sarà possibile spedire in multicast uno stream multimediale in una
LAN.
Latenza Questo test misura il tempo necessario per completare una invocazione ad un oggetto remoto, mandando un pacchetto molto piccolo o
null. La tabella 1 mostra le statistiche per 100000 ice ping(). Questo è
il messaggio più semplice che possa essere implementato in ICE, poichè
non ha argomenti e non ritorna valori.
Throughput Il test misura l’efficienza del protocollo nella trasmissione dei
dati raw. La tabella 2 mostra le statistiche ove vengono inviati 500KB
di dati raw in un loop di 1000 iterazioni. Tutte le invocazioni sono
twoway.
API Uno degli scopi principali è quello di rendere IDM come una libreria
di funzioni avanzate, che offrono una molteplicità di servizi in maniera
chiara e trasparente per l’utente.
Dal punto di vista del programmatore, l’implementazione lato server è quasi
identica ad una qualsiasi implementazione di un server ICE.
Viene usato un oggetto speciale chiamato IDM: : Adapter il quale è un
decoratore dello standard Ice ObjectAdapter. Quando viene creato, sarà automaticamente registrato nei servizi disponibili di ALP. Per quanto riguarda
il client, richiede varie modifiche rispetto all’implementazione del modello
convenzionale ICE. In primis, necessita la creazione di un socket quindi lo
si invoca attraverso IDM: : Socket e successivamente il metodo plug() che
prende un oggetto identificatore e restituisce un proxy per effettuare invocazioni specifiche su un oggetto remoto. Codesta classe è responsabile per il
looking up dei nodi e usa il servizio ALP per raggiungere il nodo ultimo dove
è instanziato l’oggetto remoto.
42
4
I simulatori, la simulazione ed Omnet
4.1
Simulazione ed emulazione
Per simulazione si intende un modello della realtà, mediante il quale è possibile valutare e prevedere l’evoluzione dinamica di eventi in un sistema sotto
determinate condizioni settate dall’utilizzatore, lo scopo è quello di fare un’analisi del funzionamento del sistema, poiché spesso nella realtà non si ha la
disponibilità di risorse sufficienti per effettuare delle valutazioni. La difficoltà
nel realizzare un modello di simulazione risiede nella capacità del progettista, di modellare quanto più fedelmente il sistema reale. Per realizzare un
modello di simulazione corretto e funzionante bisogna seguire alcune linee
guida :
• definire obiettivi e problematiche mediante un’analisi del problema
• definire un modello concettuale del sistema che bisogna simulare,
definendo il comportamento del modello;
• validazione del modello concettuale
• definizione dei parametri di ingresso del modello
• calibrazione e valutazione
• definizione di una campagna di test definendo diversi scenari di simulazione e valutare i diversi scenari al variare dei tempi di esecuzione per
poi valutare i parametri di uscita
Il modello realizzato bisogna implementarlo mediante un simulatore,
grazie al quale le entità modellate sono implementate assieme alle interazioni
fra esse definite, consentendo l’esecuzione di simulazioni dalle quali estrarre
i dati di interesse per l’analista. La simulazione può essere ad eventi discreti oppure tempo continuo. Nel caso ad eventi discreti è rappresentato
lo stato del sistema in corrispondenza degli eventi da rilevare, mediante uno
schedulatore che consente agli eventi di essere eseguiti ordinatamente, senza simulare intervalli di tempo che intercorrono tra due eventi, riducendo la
complessità computazionale. Nel caso tempo continuo lo stato del sistema è
rappresentato ad ogni istante, assicurando il sincronismo tra gli eventi, ma
rappresentando anche istanti di tempo poco significativi, facendo crescere
quindi la complessità computazionale.
L’emulazione invece consiste nella capacità di eseguire (mediante un software), codice realizzato per un determinato ambiente (hardware o software)
43
in un ambiente diverso, riproducendo virtualmente l’ambiente che è stato
usato per eseguire quel codice. Il livello di astrazione è quindi basso. L’emulazione può essere realizzata in due modalità: ricompilando il codice sorgente
(in linguaggio di programmazione di alto livello), ottenendo il file binario
per lambiente ospitante, oppure interpretando il codice del programma in
linguaggio macchina, approccio più efficace ma che richiede una maggiore
complessità computazionale.
4.2
Classificazione dei simulatori
I simulatori disponibili sul mercato sono molteplici, ognuno con particolari
caratteristiche, è necessario analizzare e capire le peculiarità di ognuno di
essi, scegliendo quello che meglio si adatta alle esigenze del modello che si
intende realizzare. Una prima distinzione è possibile classificando i simulatori in comportamentali ed orientati agli algoritmi. I primi consentono la
simulazione su ogni nodo della rete di tutti gli strati dello stack protocollare, al fine di studiare il traffico di messaggi sulla rete ed il comportamento
complessivo del modello, rivolgendo meno attenzione a quello che succede a
livello applicativo ed agli algoritmi di instradamento. Lutilizzo di questo tipo
di simulatori consiste nella costruzione di nodi della rete, combinando moduli software della libreria del simulatore, loutput della simulazione contiene
gli eventi significativi della simulazione. La seconda categoria di simulatori presenta un maggiore livello di astrazione, lo scopo è quello di simulare
lesecuzione di un algoritmo su ogni nodo, la simulazione di come avviene
la trasmissione è generalmente poco realistica ed affidabile. Un’altra distinzione interessa la modalità di funzionamento dei simulatori. Essi possono
essere orientati agli eventi ed ai processi. Nei simulatori orientati agli eventi
(cambiamento dello stato del sistema in un determinato istante di tempo),
il tempo simulato avanza al verificarsi del prossimo evento. Nei simulatori
orientati ai processi (istanza di un programma in esecuzione che emula il
flusso di un’entità del sistema da simulare), il tempo di simulazione avanza
al processo successivo, quando il flusso di esecuzione del processo corrente è
bloccato, ritardato o terminato. Per operare la scelta del simulatore, sono
state considerate un insieme di caratteristiche generali:
tipo di licenza indica se il simulatore è free software o è disponibile solo in
versione commerciale
linguaggio dei componenti dei nodi indica il linguaggio di programmazione usato per implementare i componenti dei nodi
44
tipo di simulazione indica se la simulazione è ad eventi discreti o tempo
continuo
emulazione indica se è supportata lemulazione
simulazione parallela indica se è presente un supporto allesecuzione parallela in multithreading e se è consentito allutente, configurare tale
funzionalità mediante la gestione dei thread
Una classificazione di maggior dettaglio riguarda le caratteristiche qualitàtive, per illustrare in dettaglio il modo in cui è condotta la simulazione.
Le caratteristiche qualitàtive sono:
interfaccia grafica indica se è presente unadeguata interfaccia grafica per
lavvio, lesecuzione e la terminazione della simulazione, indispensabile
per studiare il comportamento del sistema
estensibilità e modificabilità è la possibilità di estendere e modificare i
moduli del simulatore specializzando le funzionalità in base alle proprie
esigenze di modellazione
modularità è la possibilità di comporre tra loro le entità della simulazione,
per formare entità più generali
tipologia di guasti indica il tipo di guasto che lutente può simulare durante la simulazione
L’attenzione è stata rivolta alla perdita dei pacchetti ed alla corruzione dei bit
dei pacchetti; statistiche finali: indica la possibilità di produrre agevolmente
statistiche finali. [14]
4.3
I simulatori adottati
Durante lo svolgimento del lavoro, sono stati presi in esame due simulatori
in particolare: Ns-2 ed Omnet. La scelta finale è ricaduta sul secondo poiché
possiede maggiori requisiti e funzionalità richieste, per una simulazione. Inoltre rispetto ad Ns-2 possiede una quantità di tool maggiore, soprattutto dal
punto di vista grafico, che facilitano e velocizzano la scrittura del codice. Di
seguito verràno comparati.
45
4.3.1
Ns-2
Ns-2 è un simulatore comportamentale, ad eventi, scritto in C++, con interfaccia utente in Otcl per configurare le simulazioni, nasce per studiare il
traffico di messaggi sulla rete. E’ tra i simulatori di reti più usati per l’eterogeneità d’uso e la varietà di modelli offerti, ma manca una documentazione
rigorosa ed organizzata. Ns-2 è open-source e non supporta nè l’esecuzione parallela, nè l’emulazione. Non c’è uninterfaccia grafica per impostare
agevolmente lambiente di simulazione, inoltre l’utilizzo del simulatore non è
semplice. Gli output sono prodotti in diversi formati. Un’utility che consente di seguire la simulazione graficamente è la Network Animator, essa legge
il file di tracing degli eventi e lo visualizza. Presenta vari modelli per rappresentare i link, consentendo di impostare caratteristiche della topologia di
rete come ampiezza di banda, ritardo di propagazione, perdita di pacchetti.
NS-2 presenta un’ampiù scelta di algoritmi di routing. Il comportamento di
un nodo è specificato mediante lo script Otcl, specificando gli oggetti che lo
compongono ed il modo in cui sono collegati. La scrittura di moduli C++
offre lopportunità di implementare nuove caratteristiche. Poco funzionali le
API offerte, non c’è una netta distinzione tra librerie di simulazione e modelli implementati. Non produce dati statistici in output, ma l’utente può
inserire nello script OTCL operazioni per il prelievo di dati di interesse. Tra
i motivi che lo rendono poco consono alle nostre esigenze, si segnala l’assenza
di modularità, l’assenza di un’interfaccia grafica, statistiche finali difficili da
gestire. [8]
4.3.2
Omnet
OMNeT++ [2] è un simulatore ad eventi discreti, non commerciale, scritto
in C++, è dotato di uninterfaccia grafica di alto livello, è classificato fra
i simulatori comportamentali. Esso supporta lesecuzione parallela, ma non
lemulazione. Il simulatore è dotato di un tool (NED) per la definizione della
topologia e delle caratteristiche della rete, offrendo sia un supporto grafico
che testuale. Le entità definite sono dei moduli che possono estendere le proprie funzionalità mediante codice C++, ogni modulo può contenere al suo
interno sottomoduli. Un file di configurazione consente di settare i parametri iniziali del modello. Consente una modellazione dei guasti introducendo
soltanto la corruzione dei pacchetti. Al termine della simulazione fornisce
un servizio di base di statistiche finali, con la possibilità da parte dellutente di estenderle. Diversi framework consentono di utilizzare OMNeT++ in
svariati domini applicativi, quello che risponde alle esigenze del modello da
simulare è INET che modella diversi stack protocollari, fra i quali UDP/IP.
46
Da segnalare inoltre, che Omnet è una versione custom di Eclipse, il noto
IDE per svariati linguaggi di programmazione tra cui Java, C e C++.
4.4
Scelta di omnet
La scelta di OMNeT++ e del suo framework INET (implementa strati protocollari per l’interconnessione di calcolatori su rete) tra la vastità di simulatori
presenti sul mercato, è stata guidata dalla combinazione di molteplici esigenze. È un simulatore comportamentale, i moduli sono facilmente riusabili ed
assemblabili fra loro, consente di visualizzare i pacchetti sulla rete ed il loro
contenuto durante l’esecuzione e come variano i parametri all’evolvere dell’esecuzione, inoltre, la presenza del framework INET offre un buon supporto
per la gestione ed il settaggio della topologia della rete anche per reti di notevoli dimensioni. L’unico limite è rappresentato dalla memoria del calcolatore
in uso. Inoltre, esso offre funzionalità per supportare l’instradamento. Queste funzionalità fornite dal simulatore sono comunque estendibili dall’utente
che può imporre delle varianti al comportamento di default, potendo introdurre algoritmi di instradamento alternativi, o settare nuove route scrivendo
direttamente gli hop per il percorso da seguire mediante appositi file.
4.5
Il simulatore OMNeT++
OMNeT++ (Objective Modular Network Testbed in C++) è un simulatore
di rete modulare component-oriented ad eventi discreti basato sul linguaggio
C++ ed open source che nasce nel 2003. Tale simulatore è modulare perché
ogni entità presente o da realizzare è rappresentata mediante un modulo e
tutti i moduli sono organizzati gerarchicamente, comunicano mediante scambio di messaggi che viaggiano attraverso porte e connessioni. Componentoriented indica che larchitettura del simulatore è costituita da componenti
che interagendo tra loro, consentono lesecuzione del programma di simulazione. Un sistema ad eventi discreti è un sistema in cui lo stato cambia quando
accade un evento ad istanze discrete nel tempo. Il simulatore può essere
utilizzato per:
• modellazione del traffico nelle reti di telecomunicazioni
• modellazione di protocolli
• modellazione di code nelle reti
• modellazione di sistemi multiprocessore
• modellazione di sistemi distribuiti
47
• validazione di architetture hardware
• valutazione delle prestazioni di sistemi software complessi
• modellazione di sistemi rappresentabili con eventi discreti
L’innovazione principale di OMNeT++ è quella di essere componentoriented, facilita luso di modelli strutturati e riusabili, supporta l’esecuzione
parallela (in sistemi multiprocessore), gli ambienti di esecuzione supportano
la simulazione interattiva. Questo simulatore fornisce per lo sviluppo ed
il debugging delle topologie da simulare, un ambiente grafico abbastanza
intuitivo (GNED), il quale contiene anche una rappresentazione testuale della
topologia del modello, uninterfaccia grafica (Tkenv) per lesecuzione della
simulazione, mediante questa interfaccia è possibile visionare i moduli del
modello e vedere levolvere dello stato della simulazione, uninterfaccia da linea
di comando (Cmdenv), tool grafici (PLOVE e SCALARS) per visualizzare il
contenuto degli output della simulazione scritti su appositi file dati generati
automaticamente, ma estendibili dallutente.
Figura 12: File Omnet++
48
OMNeT++ non è un simulatore commerciale, è rivolto principalmente alluso accademico ed alla ricerca, la sua versione commerciale è OMNEST. Fra
i simulatori esistenti, OPNET rappresenta il migliore simulatore sul mercato,
ma è commerciale. I simulatori commerciali offrono una vasta gamma di modelli di protocolli, mentre quelli non commerciali offrono una minore scelta.
Un limite principale di OMNeT++ è proprio la mancanza di una vasta scelta
di protocolli, (ne esistono diversi, ma in scarso numero), limite dovuto al fatto che è un simulatore nato da poco; con la diffusione delle community questo
limite dovrebbe essere superato in pochi anni. Il livello di astrazione è molto
elevato, ha una notevole facilità d’uso per l’utente (interfaccia user-friendly),
la documentazione offerta e le prestazioni durante l’esecuzione sono di livello
eccellente. OMNeT++ è disponibile sia per macchine Windows che Linux, la
versione per Linux è la stessa per distribuzioni diverse, inoltre la portabilità
è garantita, previa modifica dei makefile per la simulazione da effettuare. Un
modello OMNeT++ è costituito da moduli organizzati gerarchicamente e caratterizzati attraverso parametri, i moduli comunicano mediante scambio di
messaggi (che possono anche contenere strutture dati complesse) attraverso
i canali, inoltrando i messaggi direttamente verso una destinazione o lungo
un percorso, usando porte e connessioni. Le connessioni possono essere caratterizzate da tre parametri: ritardo di propagazione, tasso di errore per
bit, tasso di trasmissione. Gli oggetti della simulazione sono rappresentati
da classi C++, le principali sono quelle per moduli, porte, connessioni, parametri, messaggi, container, raccolta dati, stima statistica e distribuzione.
Un modello OMNeT++ si compone di: file per la descrizione della topologia
(. ned), file per la definizione dei messaggi (. msg), tradotti in codice C++
mediante compilazione, moduli del codice sorgente (. h/. cc) che devono essere compilati e collegati con il simulation kernel, esso contiene il codice per
gestire la simulazione, le classi di libreria (. a/. lib) e le interfacce utente (.
a/. lib) per formare il programma di simulazione eseguibile. Il file eseguibile
necessita del file di configurazione omnetpp. ini che contiene informazioni di
controllo, esso è utilizzato per costruire un file binario per consentire lesecuzione anche su macchine sulle quali non è installato OMNeT++. Loutput
della simulazione è scritto in file dati: output scalar e vector file (vector
file è opzionale), visualizzabili anche graficamente con gli strumenti forniti
da OMNeT++ o importabili da software diffusi sul mercato come MatLab,
Microsoft Excel, OpenOffice calc.
4.5.1
Il linguaggio NED
Il linguaggio NED specifica la topologia di un modello, facilitando la descrizione modulare di una rete ed offre la possibilità di costruire una rete con
49
sottomoduli innestati. I possibili componenti di un modello NED sono:
direttive import, usate per importare dichiarazioni da un
altro file per la descrizione di
una rete:
import ’’ethernet’’;
definizioni dei canali, specificano un tipo di connessione,
il nome del canale può essere usato per la creazione di
connessioni, gli attributi possono essere assegnati
anche nel corpo della dichiarazione del canale:
channel ChannelName
//. . .
endchannel
simple module, blocco di base per la costruzione dei
moduli, è definito dalla
dichiarazione di parametri e porte:
simple SimpleModuleName
parameters:
//. . .
gates:
//. . .
endsimple
compound module, moduli composti di uno o più sottomoduli,
che possono avere porti e parametri:
module CompoundModule
parameters:
//. . .
gates:
//. . .
submodules:
//. . .
connections:
//. . .
endmodule
definizione della rete, dichiara un modello di simulazione
come una istanza di un tipo
di modulo definito precedentemente:
network wirelessLAN: WirelessLAN
parameters:
numUsers=10,
50
httpTraffic=true,
ftpTraffic=true,
distanceFromHub=truncnormal(100, 60);
endnetwork
4.5.2
Il sistema di simulazione ad eventi discreti
OMNeT++ utilizza una struttura dati per mantenere linsieme degli eventi
futuri e prende il nome di FES (Future Event Set) o FEL (Future Event
List) implementato in OMNeT++ con lheap binario. I simple module sono
i componenti attivi nel modello perché in essi accadono gli eventi, essi creano, inviano, ricevono, memorizzano, modificano, schedulano e distruggono i
messaggi, sono programmati in C++ come sottoclassi di cSimpleModule con
funzioni membro virtuali ridefinite per definire le caratteristiche, tale codice
genera e reagisce agli eventi, usano OMNeT++ class library e le funzioni
membro sono le seguenti:
• void initialize()
• void handleMessage(cMessage *msg)
• void activity()
• void finish()
Nella fase di inizializzazione (funzione initialize()) si costruisce la rete, si
creano i simple e compound module e sono connessi in base alle definizioni
del file NED e del file di configurazione omnetpp. ini. Durante il processamento degli eventi sono chiamate le funzioni handleMessage() (chiamata da
ogni messaggio che arriva al modulo oppure in seguito a schedulazione ad
un fissato istante di tempo) oppure activity(), nelle quali sono implementate
dallutente le caratteristiche del modello. La funzione activity() non necessita
della preventiva esecuzione della funzione initialize(), ma presenta limiti notevoli dal punto di vista della scalabilità: questa funzione crea un sovraccarico
dello stack, quindi in presenza di centinaia di simple module, crea difficoltà
nella gestione della memoria, inoltre introduce un maggiore overhead a runtime, nonché una maggiore lentezza nella chiamata della coroutine rispetto
ad una normale chiamata a funzione. Solo nella fase finale è possibile memorizzare i dati statistici raccolti durante la simulazione (durante linvocazione
della funzione finish()). Gli eventi sono rappresentati mediante i messaggi
da unistanza della classe cMessage. I messaggi sono inviati da un modulo ad
un altro, quindi il posto dove occorre un evento è il modulo destinazione del
messaggio. Gli eventi in ingresso al buffer del FES sono consumati in base
51
#include <omnetpp. h>
class HelloModule : public cSimpleModule
{
protected:
virtual void initialize();
virtual void handleMessage(cMessage ∗msg);
};
Define Module(HelloModule);
void HelloModule: : initialize()
{
ev << ’’Hello World!\n’’;
}
void HelloModule: : handleMessage(cMessage ∗msg)
{
delete msg; }
allordine darrivo, dati due messaggi, quello con il tempo darrivo più basso è
eseguito prima, se tali valori sono uguali, si esegue prima quello con il valore
di priorità più basso, se le priorità sono le stesse si valuta quello schedulato o inviato prima. Un dettaglio tecnico interessante nel funzionamento di
OMNeT++ riguarda le porte, infatti esse hanno associate code per memorizzare messaggi in attesa di essere trasmessi, i messaggi sono però memorizzati
nei buffer della FES. Questo tipo di approccio dovrebbe essere più veloce
rispetto ad una soluzione che fa uso delle code, perché evita loverhead dovuto allaccodamento (ed al disaccodamento), eventi e messaggi sono trattati
come ununica entità. Altri simulatori (come ad esempio OPNET) assegnano
code di pacchetti alle porte in ingresso prima di bufferizzare i messaggi, in
questo modo gli eventi sono gestiti da unentità equivalente alla FES, mentre
i messaggi dalle porte, quindi eventi e messaggi risultano essere due entità
separate. La registrazione della classe con OMNeT++ avviene mediante la
macro Define Module() inserita nel codice C++:
4.5.3
La macchina a stati finiti
La macchina a stati finiti fa parte del modello di programmazione supportato
dallambiente di simulazione, è attivata con il metodo handleMessage(), OMNeT++ fornisce una classe ed un insieme di macro per costruire una FSM
in cui sono possibili due stati: transient e steady. Lo stato transient indica
una condizione temporanea della FSM che si verifica durante la transizione
da un evento al successivo; lo stato steady indica una condizione in cui levento è accaduto. Il modello di programmazione di OMNeT++ comprende
52
anche una soluzione basata sulle coroutine che implementa linterazione tra i
processi mediante la funzione activity(). Ad ogni evento la FSM transita da
uno stato costante attraverso uno o più transitori per poi ritornare in uno
stadio costante. Nel codice del metodo è possibile inserire i punti di ingresso
e di uscita da uno stato. La FSM è memorizzata in un oggetto cFSM.
4.5.4
I messaggi
L’oggetto cMessage rappresenta messaggi, eventi, pacchetti, frame, bit, segnali (o altre entità) che viaggiano attraverso la rete. Tale oggetto ha degli
attributi, alcuni usati dal simulation kernel, altri di utilità per il programma
di simulazione, ecco alcuni di essi: nome del messaggio, tipo, lunghezza, bit
error flag (settato ad uno quando la probabilità derrore supera una certa
soglia), priorità usata dal kernel per ordinare i messaggi in ingresso al FES,
timestamp usato in caso di accodamento o reinvio, lista parametri, messaggio
incapsulato per modellare il passaggio attraverso i livelli della pila protocollare, informazioni di controllo, indicatore di contesto, infine attributi per la
memorizzazione di informazioni come moduli e porte sorgente e destinazione,
tempo di invio e di ricezione.
Questo oggetto può essere esteso per aggiungere nuovi campi ed OMNeT++ fornisce un modo molto conveniente per la definizione dei messaggi
creando file con estensione *. msg, dal quale in seguito ad una compilazione, è generato codice C++ che fornisce i metodi allutilizzatore per settare i
campi dei messaggi definiti dallutente.
4.5.5
Architettura
Larchitettura di OMNeT++ è realizzata mediante i seguenti componenti:
Sim è il simulation kernel ed una libreria di classi che lutente può collegare
alla propria simulazione. Questo componente gestisce gli eventi futuri,
istanzia simple module ed altri componenti allinizio dellesecuzione della
simulazione
Envir è un’altra libreria contenente il codice comune a tutte le interfacce
utente, consente di estendere le interfacce di base, mediante plug-in
aggiuntivi. Esso mantiene il controllo di cosa accade durante la simulazione. Il metodo main() è localizzato in questo componente e determina
quali modelli richiamare durante la simulazione
Cmdenv e Tkenv sono implementazioni di interfacce utente specifiche da
collegare alla propria simulazione: la prima agisce da linea di comando,
53
la seconda è grafica. Mediante queste interfacce l’utente ha la possibilità di iniziare e terminare la simulazione, nonchè seguire l’evolvere
della simulazione;
Model component library consiste di definizioni di simple module e relativa implementazione in C++, tipi di compound module, canali, reti,
messaggi ed altre entità legate alla simulazione
Executing model è il modello che è stato impostato per la simulazione. Esso contiene oggetti (moduli, canali) che sono tutte istanze di
componenti appartenenti al Model Component Library
Figura 13: Componenti Omnet++
Sim ¡-¿ Executing Model: Sim invoca i moduli nellExecuting Model come
eventi accaduti memorizzandoli nelloggetto principale di Sim: simulation
(della classe cSimulation, che memorizza i moduli del modello in esecuzione
e tiene traccia degli eventi nella FES), mentre Executing Model chiama le
funzioni nel Sim ed usa le sue classi di libreria. Sim ¡-¿ Model Component
Library: Sim fa riferimento al Model Component Library quando è usata
la creazione dinamica dei moduli (durante la fase di inizializzazione della
simulazione). Executing Model ¡-¿ Envir: loggetto ev (unica istanza della
classe cEnvir, serve a gestire le funzionalità per lI/O e fornire metodi per
accedere a Sim), è usato per visualizzare informazioni durante la simulazione
e per la scrittura sul file di log. Sim ¡-¿ Envir: invoca Sim per le funzionalità
legate allo scheduling ed allesecuzione degli eventi, mentre Sim usa Envir
per produrre i risultati della simulazione. Envir ¡-¿ Tkenv e Cmdenv: Envir
definisce una classe per linterfaccia utente: TOmnetApp, Tkenv e Cmdenv
54
sono sue sottoclassi che consentono allutente di scegliere quale usare mediante
il metodo main() che crea unistanza e la esegue. Envir fornisce anche delle
funzionalità di base per le sottoclassi di TOmnetApp che usano i suoi stessi
metodi essendo sue sottoclassi.
4.6
INET framework
INET framework è un modello di simulazione per alcuni strati protocollari
per l’interconnessione di calcolatori su rete. Esso contiene limplementazione di protocolli come TCP/IP ed UDP/IP, è stato scritto per l’ambiente di
simulazione OMNeT++/OMNEST, utilizzando i moduli attraverso i quali
sono scambiati i messaggi. Include anche MPLS con RSVP-TE e segnalazione LDP. I modelli del livello di collegamento sono PPP, Ethernet e 802. 11.
Si osserva che la distribuzione dell’INET framework presenta delle differenze
tra Linux e Windows, infatti la distribuzione Windows offre una scelta dellinsieme di protocolli più limitati, poichè nasce come una versione dimostrativa
e non di sviluppo. Esso contiene alcuni esempi di reti da simulare, modelli
di entità di rete, classi C++ per la definizione di messaggi che viaggiano
sulla rete. Rispetto ad altri concorrenti, come già detto, presenta pochi modelli, questo framework fornisce alcuni modelli che per lo scopo del nostro
lavoro sono più che sufficienti, consentendo di sfruttare al meglio i pregi del
simulatore. I protocolli sono rappresentati mediante simple module. Linterfaccia esterna del modulo è descritta mediante file NED, limplementazione
corrispondente è contenuta in file C++ con lo stesso nome del file NED.
Questi moduli possono liberamente essere combinati fra loro con il linguaggio NED per formare host o altri device, senza effettuare la ricompilazione.
Sono comunque presenti host preassemblati, router, switch, access-point utilizzabili dallutente, ma è possibile crearne di nuovi. Le interfacce di rete sono
compound module, composti da una coda, un MAC, ed eventualmente altri
simple module. Non tutti i moduli implementano protocolli, esistono molti
moduli che servono a facilitare la comunicazione con altri moduli, consentire
l’autoconfigurazione della rete, spostare un nodo mobile. I protocolli sono
dotati di specifici messaggi, sono descritti dai file con estensione *. msg di
OMNeT++. Essi sono rappresentati da classi C++, estensioni della classe
cMessage, generate automaticamente quando è compilato lINET framework.
Ci sono alcuni moduli in comune a modelli di host, router e device che è
opportuno segnalare:
InterfaceTable contiene la tabella delle interfacce di rete nell’host. Questo
modulo non invia né riceve messaggi, è acceduto da altri moduli, nella
fattispecie quelli che implementano interfacce di rete, per determinare
55
linterfaccia attraverso la quale inviare il pacchetto, usando chiamate a
funzioni membro C++
RoutingTable contiene la tabella di routing del protocollo IP v. 4 (RoutingTable6 ha la tabella IP v. 6), si affida all’interfaccia di rete per
effettuare le sue operazioni. Questo modulo è acceduto da altri moduli
attraverso chiamate a funzioni membro C++. Sono presenti funzioni
membro per fare query, aggiungere e rimuovere percorsi nonché per
trovare il miglior percorso
NotificationBoard per fornire la comunicazione in modalità
publish-subscribe. Se ad esempio un modulo modifica il suo stato, se
ha sottoscritto una notifica, questa sarà consegnata agli altri nodi che
hanno sottoscritto quella categoria di notifica
FlatNetworkConfigurator assegna indirizzi IP agli host ed ai router
NetworkConfigurator assegna indirizzi IP agli host ed ai router ma a
differenza del precedente opera anche oltre gli ambienti LAN
ScenarioManager supporta gli scripting per implementare l’interfaccia
IscriptableC++
ChannelControl serve per simulazioni wireless, tiene traccia di quali nodi
sono nel raggio di interferenza di altri nodi
Questo framework offre supporto al multicast, ma le funzioni di instradamento utilizzate nella modalità unicast, non funzionano per il multicast. Il
motivo risiede nel fatto che le funzioni di instradamento utilizzate per unicast, sono definite nei moduli FlatNetworkConfigurator e NetworkConfigurator
che assegnano indirizzi IP solo a nodi e non a gruppi, nel caso del multicast
non essendo loro ad assegnare lindirizzo multicast, non consentono neppure
luso delle funzioni di instradamento. L’utente è costretto a creare degli appositi file di routing di semplice costruzione (con estensione *. rt, *. irt, *.
mrt) in cui configurare i nodi della rete per specificare lappartenenza ad un
gruppo multicast e specificare il percorso da seguire per raggiungere una data
destinazione. Questi file possono essere utilizzati anche per configurare i nodi
di rete e specificare un percorso nel funzionamento unicast, ma solo nel caso
non si voglia utilizzare il NetworkConfigurator o il FlatNetworkConfigurator.
Quando un protocollo di livello superiore vuole inviare un pacchetto dati
ad un protocollo di livello inferiore, invia l’oggetto messaggio che rappresenta
il pacchetto incapsulandolo. Il processo di invio dal basso verso l’alto, prevede l’operazione inversa a quella di incapsulamento del pacchetto. Spesso è
56
necessario trasportare informazioni aggiuntive con il pacchetto, ad esempio
inviando dati su TCP o UDP serve un identificatore della connessione TCP o
informazioni utilizzate da UDP nel messaggio inviato dal livello applicativo.
TCP o UDP a loro volta inviano un segmento su IP, il messaggio a livello
trasporto necessita di un indirizzo destinazione ed altri parametri come TTL,
analogamente IP effettua l’invio di datagrammi verso un’interfaccia Ethernet, anche qui nel messaggio di livello rete bisogna specificare un indirizzo
MAC. Queste informazioni aggiuntive sono attaccate al messaggio oggetto
come informazioni di controllo che sono piccoli oggetti attaccati ai pacchetti
con la relativa funzione membro.
All’interno di host e router sono presenti diverse entità (possono essere
sia simple che compound module), ad esempio un possibile modello di host
client contiene: un’interfaccia Ethernet, il livello rete, un’applicazione (ping),
un modello UDP ed uno TCP, un modello applicativo (soprastante TCP), la
tabella di routing ed un modulo per consentire possibili estensioni future.
57
5
5.1
Modellazione del protocollo IDM
su Omnet
Gli argomenti trattati nella simulazione
Di tutti gli aspetti considerati sin’ora, bisogna astrarne soltanto alcuni di essi.
La simulazione adottata con Omnet su un protocollo in sviluppo come IDM,
è in grado di simulare alcuni aspetti genarali che risultano basilari per lo
sviluppo del protocollo. Primo fra tutti l’header di ogni possibile messaggio
mandato in una inter-rete di questo tipo. Successivamente bisogna astrarre
il concetto di nodo riguardante il protocollo IDM. Si è detto nel Capitolo 1,
come mostra l’immagine numero 5, che un nodo è un insieme di entità che
interagiscono tra di loro(oggetto remoto, client, servizio ALP, router IDM,
EP, adattatori). Quindi si creeranno varie entità che interagiranno tra di
loro per simulare in primis il concetto di nodo, e successivamente un’implementazione completa all’interno di una rete. L’obiettivo finale sarà quello
di implementare vari scenari con un numero crescente di nodi, all’interno
dei quali viaggiano i pacchetti IDM e misurare in base al numero di nodi,
le statistiche fornite da Omnet, per rilevare eventuali limiti e attuare una
comparazione col il modello di prototipo sviluppato fin’ora.
Successivamente, sfruttando il framework INET, sarà possibile attuare
un simulazione su un’implementazione completa di protocolli quali TCP ed
UDP.
Questo scenario può essere rappresentato dalla figura 6 .
L’idea di base è quella di riprodurre fedelmente un cammino illustrato
nella figura , che coinvolge gli aspetti che si devono astrarre per la simulazione.
5.2
La progettazione del network
Una prima implementazione comprende 3 elementi: client, router, oggetto
remoto.
Nella figura routerIDM[3] sta a significare che ci sono 3 router di tipo
IDM lungo il cammino. Bisogna però distinguere correttamente i nodi, come
detto precedentemente il concetto di nodo in IDM è completamente differente
dal significato che gli si attribuisce convenzionalmente, ad esempio quando
gli si associa il concetto di host di rete (in una rete TCP/IP). In questo caso
con 3 router IDM un client ed un oggetto remoto, abbiamo in totale 4 nodi.
Nella figura seguente c’è una rappresentazione più chiara.
L’obiettivo di una semplice simulazione basata su questo schema, mira
ad inviare uno o più pacchetti dal client all’oggetto remoto. Ciò simula
58
Figura 14: Scenario 1
59
Figura 15: Scenario 2
su di esso una invocazione di un determinato servizio richiesto dal client,
che l’oggetto soddisfa grazie al protocollo IDM. Il client quindi invia una
richiesta di un determinato servizio verso l’oggetto remoto, la quale viene
inviata (forward) attraverso i router presenti nel cammino. Successivamente
la richiesta viene processata dall’oggetto che fornisce il servizio al client. Una
volta arrivato il pacchetto a destinazione si attua il procedimento inverso
(reply), che consegna la risposta al client.
L’esempio proposto va esteso per protocolli eterogenei. Per questa ragione
si colloca nel percorso un numero arbitrario di router che non siano IDM e
quindi un numero arbitrario di reti. Nella figura seguente è mostrata una
implementazione possibile:
A differenza di prima, qui si hanno 3 reti differenti. Due reti IDM e una
rete generica, che può essere anche l’internet stessa, o comunque un protocollo
differente da IDM. Il procedimento in questo caso non si limita a forwardare
il pacchetto ed a riceverlo, ma IDM si deve occupare dell’instradamento al
di fuori della sua rete stessa. Su questo punto vanno fatte due osservazioni
importanti:
• ogni router IDM deve supportare l’instradamento dinamico e quindi
deve essere versatile a seconda del ruolo che gli spetta. Ergo ogni router
60
Figura 16: Scenario 3
IDM deve avere di base la medesima implementazione per adattarsi a
qualunque punto della rete
• essendo IDM un protocollo multilivello, un router deve occuparsi di
encapsulare i messaggi per poi inviarli sulla rete
Figura 17: Scenario 3.1
5.3
Implementazione
L’implementazione di questo scenario, prevede l’utilizzo di alcuni file che rappresentano delle entità. Prima di analizzare le varie entità che compongono
la rete, va dato uno sguardo alla topologia della rete stessa per mezzo del file
61
. ned. Il file . ned in Omnet permette di realizzare facilmente una qualsiasi
topologia di rete, sia con un meccanismo punta e clicca molto semplice che
con un editor testuale integrato. Di seguito il file che rappresenta lo scenario
precedente:
simple RouterIDM
{
parameters:
@display(’’i=abstract/router’’);
gates:
inout gate[];
}
simple GenericRouter
{
@display(’’i=abstract/db’’);
gates:
inout gate[];
}
simple ClientIDM
{
@display(’’i=abstract/penguin’’);
gates:
inout gate[];
}
simple ObjectIDM
{
@display(’’i=block/socket’’);
gates:
inout gate[];
}
network idm1
{
@display(’’bgb=669, 361;bgl=2’’);
types:
62
channel A extends ned. DatarateChannel
{
datarate = 50Mbps;
delay = 100ms;
}
channel C extends ned. DelayChannel
{
delay = 50ms;
}
submodules:
routerIDM[2]: RouterIDM {
}
clientIDM: ClientIDM {
@display(’’p=35, 138;i=device/pc;is=l’’);
}
objectIDM: ObjectIDM {
@display(’’p=612, 125;is=l’’);
}
genericRouter: GenericRouter {
@display(’’p=292, 32’’);
}
genericRouter1: GenericRouter {
@display(’’p=477, 71’’);
}
connections:
clientIDM. gate++ <--> C <--> routerIDM[0]. gate++;
routerIDM[0]. gate++ <--> A <--> genericRouter. gate++;
genericRouter. gate++ <--> A <--> genericRouter1. gate++;
genericRouter1. gate++ <--> A <--> routerIDM[1]. gate++;
routerIDM[1]. gate++ <--> A <--> objectIDM. gate++;
}
Con la keyword simple sono definiti i moduli base che compongono la rete,
in questo caso sono quattro: il client, il router IDM, il router generico ed infine
l’oggetto remoto. Ciascuno dei quali può inviare e ricevere messaggi, definito
nella keyword inout gate[]. Nel modulo composto network, ci sono i vari
moduli che interagiscono tra di loro per mezzo di alcuni canali (channels). In
questo caso, per differenziare al meglio la qualità della transazione dei dati,
63
class ClientIDM : public cSimpleModule
{
private:
long numSent; //numero pacchetti mandati
long numReceived; //numero pacchetti ricevuti
cLongHistogram hopCountStats; //oggetto creato per le statistiche
cOutVector hopCountVector; //oggetto creato per le statistiche
protected:
virtual
virtual
virtual
virtual
virtual
};
IDMGenMsg ∗generateFMessage();
void sendMessage(IDMGenMsg ∗msg);//forward
void initialize();
void handleMessage(cMessage ∗msg);
void finish();
si è preferito usare due canali differenti. Essendo il primo nodo composto
da due oggetti tra loro strettamente correlati, si è preferito usare il Delay
Channel che simula un ritardo di 50 ms. L’altro canale, il Datarate Channel,
in Omnet supporta oltre al ritardo un datarate che rappresenta la bandwidth
massima nella rete. Se il parametro è settato a zero la bandwidth è pari a
infinito.
Passando ad analizzare il client, si citano le intestazioni delle sue funzioni
principali:
• La funzione generateFMessage() crea il pacchetto da inviare, settando
tutti i possibili campi dell’header
• La funzione sendMessage() si occupa di inviare il messaggio al router
IDM
• La funzione initialize() è predefinita in Omnet. Va invocata nel primo modulo che da lo start all’invio dei pacchetti. In questa funzione
vengono descritti i parametri dichiarati nel campo private, che servono per collezionare le statistiche in vari formati, per poi analizzarle
successivamente.
• La funzione handleMessage è un’altra funzione predefinita di Omnet
e viene invocata ogni qual volta un pacchetto viene processato. Tutti
i moduli di una rete Omnet devono avere questa funzione (oppure la
64
funzione activity()). Quando attraverso lo script ned i pacchetti arrivano a destinazione di ogni modulo, questa funzione va personalizzata in
base all’uso del modulo. Solitamente in questa funzione sono presenti
le operazioni principali di ogni modulo della rete. Per analizzare un
solo pacchetto che transita nella rete è possibile implementare questa
funzione in modo tale che non crei altri pacchetti, in caso contrario
è possibile fare un loop o ciclare all’infinito. Spetterà poi all’utente
interrompere il flusso con la chiamata finish
• Infine, c’è la funzione finish(). La quale è chiamata se la simulazione
viene interrotta dall’utente oppure se la simulazione termina poiché
non vi sono più pacchetti da processare. Raccoglia tutti i dati e crea
le statistiche.
Si è detto precedentemente che la funzione generateFMessage() crea il
pacchetto riempiendo tutti i campi dell’header. È presentata qui di seguito
l’implementazione in Omnet dell’header IDM:
enum IDMGenMsgType
{
IDM_CONN_REQ = 0;
IDM_CONN_ACK = 1;
IDM_DISC_REQ = 2;
IDM_DISC_ACK = 3;
IDM_DATA = 4;
};
//header IDM
packet IDMGenMsg
{
char magic_I;
char magic_D;
char magic_M;
int source;
int destination;
int hopCount = 0;
int messageType; //0 forward 1 reply
int encap; //0 no 1 yes mode
//int messageSize; in Omnet Library setByteLength
int routerId;
int requestId;
65
//char tos; //depends to the service
//int flow; //depends to the tos
}
// an extention of the previous packet to send raw data
packet IDMData extends IDMGenMsg
{
string payload;
};
• La sezione enum enumera i tipi di pacchetti disponibili. A seconda dei
pacchetti che supporterà IDM questa sezione è facilmente implementabile poiché è sufficiente aggiungere il nome del pacchetto e la funzione
predefinita di Omnet getKind() per processarlo.
• La sezione packet contiene l’header IDM. Ciascuno dei campi presenti è
implementato nella funzione generateFMessage del client o generateRMessage dell’oggetto remoto. Questo perchè si è assegnato ai router
IDM il solo incarico di processare i pacchetti e la creazione solo agli
EP, poichè sono i principali attori della comunicazione
• Infine c’è la sezione che consente l’invio di dati raw. Questa è un’estensione del pacchetto precedentemente dichiarato e consente l’invio di un
payload arbitrario.
L’oggetto IDM a differenza del client, è sprovvisto dei metodi finish() e
inizialize() poiché nella simulazione presa in esame, si è deciso di analizzare
il transito di tutti i pacchett che partono ed arrivano su un solo nodo.
L’implementazione di un router normale è molto semplice: deve limitarsi
a smistare i pacchetti quindi nel momento in cui gli arriva un pacchetto, la
funzione handle message non fa altro che smistarlo al router successivo o
precedente, a seconda del messaggio.
Infine si analizza il router IDM. Precedentemente si è detto che IDM è
un protocollo multi-layer e per questo deve adattarsi ad ogni tipo di rete.
Nello scenario di base è stato preso in esame un router generico per simulare
il comportamento dei router IDM in base ad un qualsiasi router presente
su una rete. Un router IDM incapsula il pacchetto e lo spedisce al router
che è presente al di fuori della sua rete. Successivamente quando attraverso
il percorso, il pacchetto giunge sull’ultimo router (IDM) che deve inviarlo
all’oggetto, questo lo decapsula e successivamente lo invia come normale
pacchetto IDM. Nel caso in cui l’oggetto remoto manda la risposta al client
viene eseguito lo stesso procedimento.
66
6
Analisi dei risultati
6.1
I risultati in Omnet
Lo strumento Omnet fornisce una varia gamma di tool atti ad analizzare
i risultati. Nel caso preso in considerazione è stato usato event-log poiché
risulta essere il più dettagliato in ogni istante di tempo della simulazione.
Grazie a ciò è possibile misurare con facilità la latenza ed il throughput,
che sono i due parametri essenziali per poter confrontare il seguente modello
simulativo col precedente prototipo. Di seguito sono listati dei grafici con
associate delle tabelle che riassumono i loro dati.
6.2
Latenza
La latenza dipende soprattutto dal numero di hop presenti in una rete. Per
effettuare questa misurazione di solito si usano pacchetti null oppure pacchetti molto piccoli. In questo caso è stato utilizzato un pacchetto che invia
semplicemente la stringa hello. Nelle due figure seguenti sono stati utilizzati
rispettivamente 3 hop e 2 hop.
Figura 18: Statistiche
Di seguito la tabella con i risultati completi:
67
Pacchetti Totali
100431
100271
Secondi
6242
5003
Hop
3
2
Delay
100ms
50ms
Considerando che il prototipo usando EP di tipo TCP, con un solo hop
da remoto esegue il tutto in 2537 secondi, raddoppiùndo il numero di hop
ed i secondi, ci si rende conto che il risultato ottenuto non si discosta molto
da quello ottenuto dal prototipo. Con l’incremento degli hop il numero dei
secondi e del ritardo accumulato sale, ma non cosı̀ eccessivamente tale da
ritardare la comunicazione.
6.3
Throughput
Per quanto riguarda il throughput di seguito è mostrata la tabella per un
ciclo di 1000 iterazioni che inviano messaggi di 500KB
Pacchetti Totali
10926
8781
Secondi
117420
87032
Hop
3
2
Delay
100ms
50ms
Anche in questo caso i valori non si discostano molto dal prototipo e la
simulazione conferma che i risultati ottenuti precedentemente, sono accettabili poiché non si discostano molto sia dal protocollo TCP che dallo stesso
ICE, su cui è basato il codice reale di IDM.
Conclusioni e sviluppi futuri
Comparando le tabelle della simulazione con quelle del prototipo, le quali
promettono dei miglioramenti in prestazioni, si può concludere dicendo che il
protocollo IDM a livello di prestazioni è ottimale. Non si discosta molto dai
protolli come il TCP, inoltre i test usati fin’ora hanno sempre penalizzato le
prestazioni di IDM sia nel test del codice reale, che utilizza solo EP di tipo
TCP, sia la simulazione che offre in ogni caso risultati approssimativi che dipendono soprattutto dall’hardware in uso. Per queste ragioni, se IDM venisse
implementato completamente offrirebbe sicuramente prestazioni migliori.
Uno sviluppo futuro, è testare il funzionamento di IDM sfruttando il framework INET o anche INETMANET. Soprattutto quest’ultimo framework
che simula le reti MANET, come spiegato nel Capitolo 1, una rete MANET
è il terreno più fertile per poter implementare al meglio una rete IDM.
68
Conclusioni e sviluppi futuri
A prima vista, la progettazione e l’implementazione di un protocollo di rete
incluso il livello di trasporto, può sembrare un concetto contraddittorio e
uno sforzo vano, ma resta il fatto che le prestazioni che offre IDM possono
risultare molto produttive in molti scenari. Alcune fra le più importanti sono:
• Instradamento logico universale indipendente dalla tecnologia
• Trasporto trasparente da estremo ad estremo
• Prestazioni addizionali trasparenti e disaccoppiate dal trasporto come
cifratura, contabilità, autenticazione, autorizzazione.
• Routing funzionale
• Migrazione di nodi e router
Approfittando delle possibilità che offre IDM, viene valutata la sua applicabilità in vari settori:
• Reti MANET. Ogni nodo della rete ad-hoc può includere un router
IDM,
omogeneizzando l’accesso dalla rete principale. Tutto ciò permette di
costruire reti ad-hoc ibride, ad esempio una rete IP e una rete di sensori.
• Implementazione del router IDM nei sistemi embedded basati su microcontrollori e/o in FPGA per lo sviluppo di router di reti SAN.
• Reti virtuali che forniscono servizi QoS.
[9]
Riferimenti bibliografici
[1] http://arco.esi.uclm.es/idm.
[2] http://www.omnetpp.org.
[3] http://www.ece.gatech.edu/research/labs/bwn/actors/.
[4] http://it.wikipedia.org/wiki/Storage Area Network.
[5] http://it.wikipedia.org/wiki/Tunneling.
69
[6] http://it.wikipedia.org/wiki/Wireless sensor network.
[7] F.Moya G. Urzaiz-F.Rincòn D. Villa, F.J.Villanueva and J.C.Lopez.
Object oriented multi-layer router with application on wireless sensoractuator networks. In 16th IEEE International Conference on Networks
- Nuova Delhi(India), 2008.
[8] Jesús Martı́n de la Cruz. Estudio de algoritmos de enrutado en redes
móviles ad-hoc. Master’s thesis, Universidad de Castilla-La Mancha
Escuela superior de informàtica, 2007.
[9] ARCO Research Group Università della Castilla-La Mancha. Integraciòn
de redes heterogéneas, chapter 7. 2008.
[10] ARCO Research Group Università della Castilla-La Mancha. Interdomain messaging. http://arco.esi.uclm.es/en/idm, 2008.
[11] Angelo Dell’Aera. Quality of service:
discipline. Linux & co., (70), 2010.
introduzione alle queueing
[12] F.J.Villanueva F.Moya F.Rincon-J.C.Lopez and L.A.Munoz G. Urzaiz,
D.Villa. A novel communication platform to enable the collaboration of autonomous underwater vehicles. In 16th IEEE International
Conference on Networks - Nuova Delhi(India), 2008.
[13] Object Management Group. CORBA Messaging in Common Object
Request Broker Architecture Specification, chapter 17. 2008.
[14] Francesco Melillo. Modellazione dello standard omg rtps mediante omnet++. Master’s thesis, Università degli Studi di Napoli - Federico II,
2007.
Elenco delle tabelle
1
2
3
Tabella di routing . . . . . . . . . . . . . . . . . . . . . . . . . 37
Latenza su Socket, ICE, IDM . . . . . . . . . . . . . . . . . . 41
Throughput su Socket, ICE, IDM . . . . . . . . . . . . . . . . 42
Elenco delle figure
1
2
Una inter-rete IDM composta da 4 differenti network IDM . . 7
Elenco di protocolli di rete secondo ISO/OSI . . . . . . . . . . 10
70
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Esempio di instradamento . . . . . . . . . . . . . . . . . . .
Livello IDM . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gerarchia di classi in QoS . . . . . . . . . . . . . . . . . . .
Mappatura delle varie tipologie di traffico nelle bande messe
a disposizione della qdisc pfifo fast . . . . . . . . . . . . . .
Token bucket filter queueing discipline: i token arrivano a
cadenza regolare ed ogni pacchetto inviato ne consuma uno .
Scenario possibile . . . . . . . . . . . . . . . . . . . . . . . .
Scenario possibile . . . . . . . . . . . . . . . . . . . . . . . .
Il nodo in IDM . . . . . . . . . . . . . . . . . . . . . . . . .
Invocazione dell’oggetto remoto . . . . . . . . . . . . . . . .
File Omnet++ . . . . . . . . . . . . . . . . . . . . . . . . .
Componenti Omnet++ . . . . . . . . . . . . . . . . . . . . .
Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scenario 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statistiche . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
. 20
. 21
. 25
. 27
.
.
.
.
.
.
.
.
.
.
.
.
28
32
34
36
39
48
54
59
60
61
61
67