Progetto e prototipazione di
una infrastruttura di
comunicazione per il supporto
al monitoraggio distribuito del
traffico di rete
Progetto di Reti di Calcolatori LS
di
Paolo Battarra
Obiettivi del lavoro

Creare un supporto che:





rendesse semplice controllare il traffico di una macchina
fisicamente lontana;
fornisse dati significativi con pochi comandi;
mascherasse per quanto possibile all’utente interessato a
queste informazioni la complessità dei passaggi che hanno
portato al loro ottenimento.
Ottenere una architettura che garantisse portabilità,
affidabilità e che assicurasse performance accettabili
dal punto di vista di un utilizzatore.
Possibilità di avere un monitoraggio il più dinamico
possibile, ove l’utente:


non dovesse possedere alcuna informazione pregressa
sulla struttura della specifica rete locale;
potesse spostare il suo controllo e la sua attenzione su
altri host senza troppo sforzo e con costi contenuti.
Reti di Calcolatori LS
2
Il monitoraggio


Tutto il lavoro deve sempre tenere in considerazione
il contesto particolare nel quale si vuole operare:
trattare tutto nell’ambito del controllo e del
monitoraggio
Punti fondamentali da tenere in considerazione:





Concetto di minima intrusione;
La garanzia della fornitura ed il mantenimento della
qualità del servizio;
La dinamicità delle operazioni legate al monitoraggio;
Architettura logica di base con la quale sviluppare il
lavoro: il ruolo del monitorante e quello del
monitorato.
Sviluppo di una soluzione rispetto ad un caso
particolare, ma ragionamenti di carattere generale
che permettono di avere la possibilità di
generalizzare i risultati ottenuti ed adattarli a
contesti diversi, allargando in questo modo lo
scenario di utilizzo.
Reti di Calcolatori LS
3
Architettura Logica e Sistema di Nomi
Necessità di trovare:
 Uno schema architetturale,
basato sul paradigma clienteservitore;
 Un protocollo di
comunicazione che permetta
di supportare e garantire il
corretto flusso dei messaggi
tra tutte le entità del sistema;
 Un sistema di nomi dinamico,
flessibile, portabile, scalabile
e con costi accettabili,
tenendo in considerazione
tutte le possibili soluzioni:


Statico vs Dinamico;
Centralizzato vs Distribuito.
Reti di Calcolatori LS
4
Architettura - il Servitore

Il sistema dalla parte del
servitore deve rispettare il
principio della minima intrusione
del controllo:


Introduzione di un meccanismo
di replicazione a livello del
monitor:


Dovrà essere previsto un
procedimento di istanziazione e
rilascio dei monitor, a seconda
delle richieste di monitoraggio
ricevute sul monitor.
Con 3 monitor si correggono
errori singoli e si identificano
quelli doppi.
Necessità di prevedere un’entità
deputata al controllo dei risultati
dei monitor, un gestore che ne
coordini il funzionamento e ne
controlli i risultati.


Esigenza di avere una entità che
rimanga sempre attiva in attesa
di richieste di broadcast da parte
di clienti remoti, in modo da
rendere possibile il sistema di
nomi distribuito e dinamico.
Avere una sorta di stub che ci
permetta di incapsulare le
funzionalità di comunicazione con
i clienti remoti.
Reti di Calcolatori LS
5
Architettura - il Cliente

Dalla parte del cliente la struttura è
affine, quasi duale a quella lato-server,
con l’aggiunta dell’interfaccia utente
per:







facilitare gli utilizzatori;
mascherare la complessità sottostante;
fornire un elenco coi servizi disponibili;
raccogliere le richieste dall’esterno;
restituire i risultati ben formattati.
Un gestore per la coordinazione di
quelle azioni legate al reperimento delle
informazioni riguardanti il traffico di
rete di un particolare nodo remoto.
Un gestore della QoS che ci permetta di
negoziare determinati SLA,
direttamente collegati alla frequenza
con la quale si stimola il monitoraggio
remoto e la decisione delle politiche
atte a garantire questi livelli di servizio:


Tecniche di real-time;
Monitoraggio locale.
Reti di Calcolatori LS


Un gestore con la
responsabilità di farsi
carico di tutte le domande
di ottenimento della lista
degli host attivi;
Il secondo end-point di
comunicazione, un proxy,
con compiti analoghi allo
stub server-side.
6
Il protocollo di comunicazione

Protocollo a 6 fasi
1.
2.
3.
4.
5.
6.

Discovery
Reply
Start
Request
Result
Stop
Possibilità di calcolarsi
time-out dinamicamente
a partire dalle prime tre
fasi in modo da rendersi
conto di possibili
problemi sul
collegamento
Reti di Calcolatori LS
7
Recuperare informazioni sul traffico di
rete: Il protocollo SNMP

Il protocollo SNMP (Simple Network Management Protocol):





Possibilità di ricorrere, per ottenere i dati che ci interessano, a
tool già pronti che sono disponibili in rete e che fanno uso del
protocollo SNMP, in modo da semplificare e velocizzare la
successiva fase di prototipazione, integrando il nostro codice
con queste librerie.
Opportunità di ottenere un numero molto elevato, variegato
ed eterogeneo di informazioni grazie alla struttura del MIB
organizzato per tipi di traffico a seconda dei protocolli di
trasmissione utilizzati.
Problemi tipici:



Standard de facto per la comunità internet;
Portabilità e nessun problema di compatibilità.
Quali informazioni sono rilevanti per lo scopo del mio
monitoraggio?
Come organizzare i dati da far transitare sulla rete?
Necessità di personalizzazione, a seguito di uno studio sulle
informazioni ottenibili dal protocollo, in modo da:



Ottimizzare l’impiego di risorse;
Ridurre l’overhead di comunicazione;
Avere performance e QoS superiori.
Reti di Calcolatori LS
8
La fase realizzativa (1/2)

Prototipo scritto in linguaggio Java:




Meccanismo di discovery (prime 2 fasi del protocollo), realizzato
implementando una sorta di “ping” su tutti gli indirizzi “interessanti”,
servendosi di una comunicazione cliente – servitore senza connessione:




Supporto alle applicazioni distribuite (package java . rmi);
Supporto per le applicazioni grafiche (packages java . awt e javax . swing);
Familiarità dello sviluppatore 
Ogni nodo che dichiara attivo il servizio ha un servitore datagram in ascolto
su una determinata porta;
Il numero di questa porta è l’unica nozione che il cliente deve possedere per
il corretto funzionamento del meccanismo;
Si deve stabilire un time-out ed un giusto compromesso accuratezza/tempo
di risposta.
Realizzazione delle ultime 4 fasi del protocollo di comunicazione
mediante strumenti propri di Java ed in particolare utilizzando il
meccanismo del RMI (Remote Method Invocation) e definendo una
interfaccia remota che dichiari le funzionalità necessarie:



Un comando di Start che provoca l’istanziazione di tre monitor SNMP e di un
gestore per il loro controllo e coordinamento;
Un comando di Request con cui il cliente interroga il servitore e che incarna
anche la successiva fase di Result tramite il relativo valore di ritorno;
Una richiesta di Stop a fronte della quale si rilasciano tutte le risorse.
Reti di Calcolatori LS
9
La fase realizzativa (2/2)

Recupero delle informazioni di
rete attraverso il protocollo SNMP
e l’utilizzo delle librerie SnmpApi
realizzate e sviluppate da
AdventNet:




Semplici da utilizzare e da
integrare con il codice del
prototipo;
Basate sulla semplice scelta delle
informazioni rilevanti tramite OID
ed operazioni sul MIB.
Astrazione del pacchetto
informativo ottenuta tramite la
classe ReportSNMP.
Il gestore della qualità del
servizio realizzato come un
demone che stimola
periodicamente il controllo a
seconda della frequenza stabilita:
comunicazione realizzata con un
sistema ad eventi.
Reti di Calcolatori LS
10
Applicazione di prova e testing

Piccola applicazione grafica per la fase di testing e la prova
del comportamento dinamico del sistema sviluppato,
articolata su due finestre:

La prima per settare i parametri del controllo da concretizzare:




Host da monitorare;
Livello di QoS;
Tipo di traffico (informazioni rilevanti).
La seconda per visualizzare i risultati.
Reti di Calcolatori LS
11
Conclusioni e sviluppi futuri


L’architettura che abbiamo descritto risponde ai requisiti propri delle del
problema del controllo e del monitoraggio distribuito in generale e di
quello sul traffico di rete in particolare.
E’ pensata per essere:






Distribuita e per nulla centralizzata;
Portabile;
Resistente ai guasti;
Poco intrusiva, per realizzare al meglio le politiche di controllo e non andare
ad utilizzare inutilmente risorse.
La scelta di ricorrere al protocollo SNMP ha facilitato la realizzazione del
prototipo, dal momento che risulta essere molto funzionale e la sua
diffusione permette l’uso di tools già pronti per il reperimento locale su
un nodo remoto delle informazioni riguardanti il traffico di rete.
Ci sono diverse possibilità nell’ottica di sviluppi seguenti sul prototipo:


Si potrebbe realizzare un tool che facilitasse ed automatizzasse la fase
iniziale di personalizzazione;
Inoltre si potrebbero apportare miglioramenti incrementali al fine di
incrementare le prestazioni del sistema, nell’ottica di:



Garanzia della QoS;
Resistenza ai guasti;
Aggiunta di funzionalità ulteriori.
Reti di Calcolatori LS
12