Programmazione.it v6.4
Ciao, per farti riconoscere devi fare il login. Non ti sei ancora iscritto? Che aspetti, registrati adesso!
Info Pubblicit� Collabora Autori Sottoscrizioni Preferiti Bozze Scheda personale Privacy Archivio Libri Corsi per principianti Forum
Alla scoperta di Informer: la scelta del modello di rete (4/7)
Scritto da Filippo Fadda il 01-12-2006 ore 17:00
Nel precedente articolo di questa serie su Informer, ho descritto con dovizia di particolari ciascuna delle peculiarit di una rete peer-to-peer: scalabilit, flooding, traffico di sistema, traffico di applicazione, bilanciamento, latenza, diametro, fanout. Tali elementi sono strettamente correlati tra loro e pertanto non debbono essere valutati singolarmente, bens vanno presi nella loro globalit. Volendo riassumere quanto gi espresso, ideale quella rete ben bilanciata ma fortemente scalabile, con flooding nullo, ridotto traffico di sistema e di applicazione, bassa latenza, diametro ristretto ed un fanout che garantisca un elevato livello di efficienza sebbene in presenza di un limitato traffico di sistema.

La scelta del modello di rete pi idoneo dipende talvolta dal tipo di applicazione che si vuole sviluppare al di sopra dell'infrastruttura peer-to-peer. Ogni modello, tra quelli conosciuti, presenta infatti alcuni vantaggi sugli altri, ma anche, ovviamente, taluni svantaggi. Inoltre, come gi detto, un modello pu rivelarsi adatto per un particolare scopo e meno per un altro. Di norma per, se un modello capace di soddisfare i requisiti di cui parlavo poc'anzi, lo si pu impiegare proficuamente negli ambiti pi disparati, laddove comunque abbia un senso usare una rete peer-to-peer.

Una delle difficolt pi evidenti alle quali siamo andati incontro la riduzione del tempo di latenza medio, ovvero il periodo di tempo che intercorre tra l'invio del messaggio e la ricezione da parte del peer pi distante; quindi, il numero di salti che un messaggio deve fare per giungere al punto estremo della rete deve essere il minore possibile. Una rete apparentemente valida, con un numero di peer limitato, pu rivelarsi assolutamente inefficiente con il crescere dei nodi.

In seguito ai numerosi studi condotti, in particolare su Gnutella - il cui creatore, Gene Kan, si tolto la vita a soli 25 anni - si deciso di scegliere un modello di rete strutturata, poich in una rete destrutturata davvero complesso aggirare il problema del flooding, altra questione piuttosto delicata.

Al fine di ridurre la latenza e di eludere il flooding sono state valutate diverse topologie di rete (sempre in ambito peer-to-peer naturalmente), tra cui quello ad anello, ad albero e successivamente ad ipercubo, in uno spazio a due, tre e quattro dimensioni. Purtroppo persino il modello ad ipercubo, ideato da una universit americana, anch'esso afflitto dal problema del flooding. Si tentato di risolverlo in vari modi e si studiato un algoritmo di propagazione dei messaggi che ha dato risultati soddisfacenti.

Il modello ad albero e quello ad ipercubo sono stati scelti per una prima fase di simulazione. Per studiare i modelli sono stati costruiti due sistemi di simulazione, uno dei quali con iThink, un software per la simulazione dinamica. La complessit del sistema ad ipercubo ha impedito di utilizzare iThink - nella versione di cui potevamo disporre all'epoca - e si dovuto costruire un programma di simulazione ad hoc, sviluppato con Borland Delphi. La limitata potenza di calcolo delle macchine a nostra disposizione ci ha impedito di fare simulazioni con oltre 250.000 nodi.

Dai test emerso che il modello ad ipercubo genera un maggior traffico di sistema rispetto al modello ad albero, ma ha una dimensione generale minore di quest'ultimo, con una conseguente riduzione dell'effetto latenza. In linea generale tutti e due i modelli si sono rilevati validi, malgrado entrambi mostrino due importanti limiti.

Il primo che non si riesce a definire a priori quanto a fondo propagare un messaggio. In una rete di 500.000 macchine infatti impensabile che un messaggio inviato da un peer venga recapitato a tutti gli altri 499.999. Inevitabilmente solo una porzione della rete coperta. Con i modelli di cui sopra non si riesce comunque a determinare quanti salti un messaggio possa fare, o almeno noi non siamo riusciti a trovare un algoritmo capace di determinarlo.

L'altro grande problema relativo al bilanciamento. Per ridurre il traffico di sistema ed anche la latenza si pensato di strutturare il network in cluster. Le simulazioni hanno mostrato che l'aggregazione di peer mediante i cluster incrementava significativamente le performance del sistema. Tuttavia l'introduzione dei cluster aumenta la complessit del sistema, poich un cluster potrebbe estinguersi e soprattutto perch deve essere stabilito in quali circostanze un cluster debba essere creato. Naturalmente vanno anche studiate strategie di bilanciamento per evitare l'estinzione, poich quest'ultima determina la creazione di buchi, con il rischio di isolare una parte della rete.

Per superare i limiti sopra descritti, ho deciso di applicare la teoria dell'autopoiesi - di cui parleremo nella prossima puntata - alle reti peer-to-peer, pi specificatamente applicata al modello ad albero.
Precedente: Minacce per il 2007? Ecco la top ten di McAfee.
Successiva: Dopo Internet, anche l'energia wireless
Intervento di Cristiano Muzi a.k.a. crism73 del 04-12-2006 ore 09:49, Genova (GE)
Plebeo
Plebeo
(33 interventi)
Iscritto il 03-04-2001
Se non ricordo male la topologia ad ipercubo non si fermava a 4 dimensioni; per la precisione, nasceva come "cubo" a 2 dimensioni, ed ogni volta che il cubo si riempiva "saltava" alla dimensione successiva.
Intervento di Filippo Fadda a.k.a. dedalo del 04-12-2006 ore 15:52, Capriata d'orba (AL)
Duca
Duca

(1994 interventi)
Iscritto il 03-04-2001
S corretto, sembra anche a me che fosse cos, hai ragione.
Copyright Programmazione.it™ 1999-2017. Alcuni diritti riservati. Testata giornalistica iscritta col n. 569 presso il Tribunale di Milano in data 14/10/2002. Pagina generata in 0.142 secondi.