Il nostro obiettivo era quello di realizzare e valutare un sistema di notifica di eventi che offrisse buone prestazioni sia in termini di efficacia che di efficienza, basato sul funzionamento del protocollo multicast ODMRP.
Siamo riusciti a realizzare uno strato di servizio a livello applicativo che realizza un servizio di notifica basato su un protocollo Publish/Subscribe content based capace di operare senza il supporto di nessun protocollo di routing sottostante, basato principalmente sul meccanismo di costruzione e aggiornamento di una struttura a griglia di collegamenti di trasporto delle notifiche analogo a quello utilizzato dal protocollo ODMRP.
Il sistema realizzato è di tipo advertisement broadcast based, ovvero è basato sulla trasmissione in broadcast sull’intera rete degli advertisement relativi i tipi di eventi pubblicati.
Inoltre continua ad essere un servizio “OnDemand” come il protocollo ODMRP; infatti il servizio diviene attivo su domanda dell’applicazione Publisher, mentre le informazioni memorizzate dal protocollo sui nodi della rete non sono mantenute permanentemente ma vengono aggiornate ed eventualmente scartate dinamicamente.
Inoltre il servizio, così come il protocollo ODMRP, utilizza un approccio soft nei confronti dei nodi serviti e nessun messaggio esplicito è necessario per la cancellazione di sottoscrizioni dal servizio di notifica.
Il sistema realizzato dimostra una forte scalabilità ed efficienza e una grande robustezza alla mobilità dei nodi, addirittura superiore al protocollo ODMRP anche nel caso di non utilizzo delle caratteristica di filtraggio, riduzione ed eliminazione del traffico non di interesse.
La capacità distribuita del servizio di filtrare e scartare eventualmente il traffico non di interesse, rende il nostro protocollo capace peraltro di ridurre sensibilmente il carico totale della rete a tutto beneficio della scalabilità ed efficienza stessa, con dirette ripercussioni positive sull’efficacia del sistema di notifica.
Sono stati introdotte idee innovative rispetto al protocollo ODMRP capaci di migliorare le caratteristiche del servizio, come ad esempio il meccanismo di schedulazione ottimizzata dei pacchetti JOIN REPLY o il meccanismo di bufferizzazione degli advertisement e l’invio di pacchetti LIGHT JOIN QUERY.
Sono state svolte tutta una serie di simulazioni che hanno permesso la valutazione delle prestazioni del sistema sotto varie situazioni di carico e di configurazione, nonché lo studio dei parametri principali del sistema di notifica al fine di studiarne l’influenza e ricavarne valori ottimali.
L’analisi delle prestazioni in particolare ricopre un ruolo fondamentale del nostro lavoro e ci ha permesso di affinare le conoscenze del sistema progettato e realizzato e di ricavarne risultati sempre maggiori.
Futuri studi dovrebbero in primo luogo concentrarsi sullo studio più approfondito del comportamento del sistema al variare di alcuni parametri non analizzati a sufficienza; ad esempio non sono stati eseguiti sufficienti test riguardo i parametri MAX REPLY RETRASMISSION e REPLY ACK TIMEOUT: tutti i test sono stati eseguiti con tali parametri impostati sui valori 1 e 50ms rispettivamente eccetto che i testi comparativi della sezione [4.7], che hanno peraltro dimostrato un fortissimo aumento delle prestazioni del sistema in presenza di una configurazione più opportuna del singolo parametro MAX REPLY RETRASMISSION. Altro campo di ulteriore ricerca consiste nello studio della possibilità di utilizzare un meccanismo di adattamento dinamico dell’intervallo di costruzione e aggiornamento della mesh di trasporto (QUERY_INTERVAL) in base alla velocità di rottura dei cammini di forward. Inoltre viene riconosciuta una limitatezza intrinseca al meccanismo di selezione del path di trasporto che attualmente si limita a cercare il cammino minimo in termini di hop: tale meccanismo induce il sistema a scegliere cammini brevi ma poco robusti, capaci di minimizzare il numero di ritrasmissioni ma incapaci al tempo stesso di resistere durevolmente alla mobilità dei nodi della rete.
A tale proposito si propone di sviluppare e studiare la possibilità di utilizzare la potenza di ricezione dei pacchetti JOIN QUERY (il SignalNoiseRatio) per la selezione di cammini brevi ma al tempo stesso robusti, ovvero con potenze medie (o ancor meglio minime) di ricezione superiori.
In questo modo dovrebbe essere possibile attivare cammini più stabili, capaci di resistere per un tempo superiore alla mobilità della rete, in modo quindi da poter ridurre i tempi di ricostruzione della mesh di trasporto con conseguente riduzione del traffico e miglioramento complessivo delle prestazioni.
Altro possibile sviluppo futuro riguarda la possibilità di permettere all’intero sistema di invertire i ruoli tra i Publisher e i Subscriber, delegando in modo dinamico ai Subscriber l’onere di produrre i pacchetti JOIN QUERY: nel caso infatti di una eccedenza significativa del numero di nodi Publisher rispetto ai nodi Subscriber può divenire conveniente spostare il meccanismo di
costruzione e aggiornamento mesh sui secondi, in modo da avere un numero minore di cicli di JOIN QUERY generate da ritrasmettere sull’intera rete.
[6] APPENDICE
[6.1] Parametri ODPSRP (file “.config”)
• ODPSRP-QUERY-INTERVAL value
Definisce l’intervallo di aggiornamento e ricostruzione mesh
• ODPSRP-ADVERTISEMENT-LIFETIME value
Definisce il periodo di sopravvivenza di un advertisement all’interno di un nodo pubblicatore dall’ultima pubblicazione
• ODPSRP-FG-TIMEOUT value
Intervallo di sopravvivenza filtro su nodi intermedi
• ODPSRP-QUERY-BUFFER-INTERVAL value
Periodo di bufferizzazione advertisement sul nodo pubblicatore • ODPSRP-WAIT-FOR-REPLY-INTERVAL value
Periodo di attesa di ricezione Join Reply su nodo pubblicatore (utilizzato anche per ottimizzazione schedulazione Join Reply)
• ODPSRP-PATH-FACTOR value
Il valore di tale parametro utilizzato come potenza di di 2 definisce il numero massimo di hop da ottimizzare tramite il meccanismo di schedulazione dei Join Reply (Path Factor =4 implica una ottimizzazione fino a 2^4=16 hop di distanza)
• ODPSRP-BUFFER-FLUSH-DELAY value
Definisce l’intervallo che trascorre tra l’invio di ogni singolo frammento di pacchettI NOTIFICATION (N.B. Qualnet non supporta la frammentazione a livello IP, quindi i pacchetti NOTIFICATION contenenti molte notifiche bufferizzate potrebbero essere troppo grandi e vanno frammentati)
• ODPSRP-MAX-HOPCOUNT value
Definisce il numero massimo di hop che un qualsiasi pacchetto può sperimentare prima di essere scartato.
• ODPSRP-REPLY-ACK-TIMEOUT value
consegnato correttamente se non si è ricevuto un opportuno acknowledgement (passivo o attivo)
• ODPSRP-MAX-REPLY-RETRASMISSION value
Definisce il numero massimo di ritrasmissioni di pacchetti Join Reply in seguito allo scadere del relativo timeout
• ODPSRP-MAX-BACKOFF value
Definisce il massimo valore di BACKOFF utilizzato per l’invio dei pacchetti sulla rete
• ODPSRP-HOP-SHORTEST-PATH 1|0
Se impostato su 1 viene utilizzato un algoritmo di scelta del cammino di trasporto corrispondente al più corto in termini di hop; se impostato su 0 viene scelto il primo cammino ricevuto tramite Join Query
• ODPSRP-QUERY-METHOD WITH-NOTIF|WITHOUT-NOTIF
Se impostato sul valore WITH-NOTIF verranno utilizzate Heavy Join Query, ovvero Join Query contenenti notifiche al proprio interno; nel caso invece venga impostato sul valore WITHOUT-NOTIF le notifiche saranno di tipo Light Join Query, ovvero non conterrano notifiche ma soltanto advertisement
• ODPSRP-REPLY-METHOD BROADCAST|UNICAST Definisce la modalità di trasmissione
• ODPSRP-UNICAST-REPLY-ACK YES|NO
Definisce se devono essere utilizzati o meno pacchetti di acknowledgement unicast; nel caso sia impostato su NO e si utilizzi un JOIN REPLY METHOD di tipo broadcast verrà utilizzato il meccanismo denominato PASSIVE REPLY ACKNOWLEDGEMENT
• ODPSRP-REPLY-HELP YES|NO
Definisce se utilizzare o meno il meccanismo denominato JOIN REPLY HELP
• ODPSRP-SEED value
Definisce il valore del SEED da utilizzare per inizializzare la funzione rand() per la generazione casuale dei valori delle pubblicazioni e degli intervalli di BACKOFF