Nell’ambito delle reti semantiche, un aspetto fondamentale `e riuscire a modellare la similarit`a tra entit`a/peer. Occorre trovare un buon compromesso tra la preci- sione nel caratterizzare un utente, la leggerezza delle informazioni scambiate a tale scopo tra le entit`a, e la capacit`a di adattamento alle continue evoluzioni del sis- tema. Nella proposta data in [26] `e apprezzabile la semplicit`a dell’approccio che si limita a confrontare i tag presenti nei propri documenti. Ci`o permette un sem-
2.4. CONCLUSIONI 35 plice adattamento sia che si tratti di una condivisione di file multimediali, di testi o quant’altro. Inoltre ci`o comporta una totale indipendenza del peer da fonti esterne cosa che non avviene in [28] e in [30] dove ogni peer deve appoggiarsi a WordNet [29] per calcolare la propria similarit`a con gli altri. Una caratteristica cercata nello spazio semantico `e la rintracciabilit`a di ogni peer. Si vuole garantire la connettivit`a tra due peer presenti ai capi opposti della rete: chiunque deve poter collegarsi con chiunque allo scopo che peer simili si trovino nella stesa comunit`a pur trovandosi distanti tra loro. Tale propriet`a, non garantita da [26] `e invece ben realizzata da [30] e [43] dove il protocollo `e suddiviso in due livelli; quello inferiore tramite il protocollo rispettivamente Cyclon [24] e RPS[44], esplora tutta la rete in ricerca di nodi similari. Le soluzioni descritte in [30, 43] pur adattandosi con semplicit`a ed efficienza all’evoluzione della rete non permettono l’individuazione delle communi- ty che caratterizzano i peer uniti in una rete di interessi comuni, cos`ı come sono ben presentate in [27] dove per`o, per contro parte, vi `e una designazione statica del mondo suddiviso in categorie e sotto-categorie che non permettono dei cambiamen- ti nella struttura. Una possibile rappresentazione delle community `e fornita dalla struttura presente negli AccessPoint d i[28] dove viene utilizzata per indirizzare i nuovi peer al join del sistema. Tale struttura, basandosi su ogni singola parola che caratterizza i peer e i suoi documenti, ha il difetto di fornire una suddivisione molto dettagliata che richiede pesanti meccanismi che prediligono una rete in cui gli in- teressi dei peer siano stabili. Entrambi i protocolli presentati in [37] riescono ad identificare i medoidi con i relativi cluster che possiamo far combaciare con i leader e le rispettive community. Tali procedure per`o hanno il difetto di richiedere una sincronizzazione tra i nodi nell’esecuzione delle iterazioni del protocollo. Altri due aspetti negativi, in comune con l’algoritmo CDC [42] sono il fissare preventivamente il numero dei cluster/comunit`a creati in cui verranno suddivisi i peer di una rete, e il dover individuare degli specifici nodi che iniziano l’esecuzione dell’algoritmo.
Capitolo 3
Protocollo proposto
In questo capitolo viene presentato LEADER un protocollo asincrono che attraverso una procedura di elezione dei leader permette di far emergere dall’overlay network la suddivisione logica degli utenti in communit`a. Tale protocollo possiede al suo interno le migliori caratteristiche presenti nei lavori citati nel capitolo precedente: la semplicit`a nell’implementare il concetto di similarit`a presente in [26], la connet- tivit`a di tutta la rete e la adattabilit`a ai cambiamenti di [30], la chiarezza nella modellazione delle community in [27] con una modellazione pi`u leggera di quella gi`a proposta in [28], una buona suddivisione dei nodi in cluster/cummunity come quella presentata in [37] e la scelta autonoma del proprio leader/community da parte di ogni nodo come in [39].
L’utilizzo di un protocollo con le suddette caratteristiche permette di unire in- sieme le qualit`a e gli aspetti positivi delle reti semantiche con quelli ottenuti tramite una clusterizzazione dei dati. La struttura dell’overlay network cos`ı creata `e carat- terizzata da qualit`a di leggerezza e di buona modellazione che permettono un’ot- timizzazione nella gestione della ricerca di informazioni. La conoscenza dei soli leader permette di ottenere una visione globale della struttura dei dati e delle in- formazioni presenti nell’intero sistema. Infatti, venire a conoscenza del profilo di un leader, significa scoprire un gruppo di peer molto simili a quel profilo. Ci`o permette miglioramenti nello instradamento dei dati e delle informazioni.
3.1
Architettura generale del sistema
Il protocollo LEADER `e inserito in un sistema per la gestione dei profili di sup- porto ai peer del sistema. In tale sistema viene mantenuto un indice aggiornato dei profili delle comunit`a e degli indici di alcuni membri di ogni comunit`a, perme- ttendo di ricercare i profili per similarit`a. Essa `e basata su due DHT. La prima
`
e adibita alla memorizzazione dei descrittori delle comunit`a, coppie dalla forma (prof ilo, idendif icatore) dei leader delle comunit`a. La seconda mantiene per ogni id di comunit`a una lista di indirizzi di peer che fungono da “punti di accesso” per la comunit`a.
Figura 3.1: struttura generale del sistema
Questa struttura di indicizzazione viene utilizzata pi`u volte dal peer come illus- trato in figura 3.1:
• al momento del primo ingresso di un peer nel sistema essa ha funzione di AccessP oint. Tramite essa un peer pu`o ottenere un insieme di peer a lui simili.
• al momento della creazione di una nuova comunit`a, il leader invia al sistema il descrittore della comunit`a e gli indirizzi di alcuni membri che fungeranno da punti di accesso.
• al momento della modifica del descrittore di una comunit`a il leader compe- tente informer`a la struttura del cambiamento. Negli ultimi due casi il nuovo descrittore sar`a inviato ai nodi di accesso delle altre comunit`a per aggiornali sullo stato attuale della rete.
• nel caso di scioglimento di una comunit`a al fine di eliminare dalle DHT il descrittore della comunit`a.
3.2. L’AMBIENTE DI PARTENZA 39