<<O>> Difference Topic ICSI (r1.2 - 22 Jan 2002 - MarcoCalamari) |
Changed: | ||
< < | Si descrive qui Freenet, un'applicazione adattiva peer-to-peer in rete che | |
> > | Viene descritta Freenet, un'applicazione adattiva peer-to-peer in rete che | |
Changed: | ||
< < | Non vengono utilizzati né la ricerca broadcast né un indice centralizzato delle | |
> > | Non vengono utilizzati né la ricerca broadcast né un indice centralizzato delle | |
Changed: | ||
< < | E' impossibile scoprire la vera origine o destinazione di un file in transito nella rete, | |
> > | È impossibile scoprire la vera origine o destinazione di un file in transito nella rete, | |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < | o che, semplicemente, potrebbero rivelarsi sovraccarichi in caso d'interessamento | |
> > | o che, semplicemente, potrebbero rivelarsi sovraccarichi in caso di carico | |
Changed: | ||
< < | di disponibilità. Freenet opera come file system distribuito e indipendente dalla collocazione, | |
> > | di disponibilità. Freenet opera come file system distribuito ed indipendente dalla collocazione, | |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < | Il sistema è progettato per rispondere in forma adattiva a schemi d'uso, spostando, riproducendo e cancellando i file con modalità trasparenti, | |
> > | Il sistema è progettato per rispondere in forma adattiva all'utilizzo, spostando, duplicando e cancellando i file in maniera trasparente | |
Changed: | ||
< < | a ricerche broadcast o ad indici centralizzati delle collocazioni dei dati. | |
> > | a ricerche broadcast o ad indici centralizzati delle posizioni dei dati. | |
Changed: | ||
< < | si auspica di riunire un numero sufficiente di nodi aventi capacità di memorizzazione | |
> > | si auspica di riunire un numero di nodi aventi capacità di memorizzazione | |
Changed: | ||
< < | Freenet è attualmente in sviluppo come progetto di software gratuito su Sourceforge, e una versione preliminare si può scaricare dal sito http://www.freenetproject.org/. Il nucleo del sistema è il lavoro iniziale svolto dal primo autore | |
> > | Freenet è attualmente in sviluppo come progetto di software libero su Sourceforge, ed una versione preliminare si può scaricare dal sito http://www.freenetproject.org/. L'origine del sistema è il lavoro iniziale svolto dal primo autore | |
Changed: | ||
< < | In quest'area si possono identificare diverse branchie di attività correlate a Freenet. | |
> > | In quest'area si possono identificare diversi settori di attività correlati a Freenet. | |
Changed: | ||
< < | implementato i canali punto punto anonimi basati sullo schema mix-net di Chaum[8] | |
> > | implementato i canali punto-punto anonimi basati sullo schema mix-net di Chaum[8] | |
Changed: | ||
< < | meglio visti come complemento a Freenet dal momento che non supportano l'accesso a file e l'archiviazione. | |
> > | meglio visti come complemento a Freenet, dal momento che non supportano l'accesso a file e l'archiviazione. | |
Changed: | ||
< < | L'anonimato per gli utenti dell'informazione nel contesto web è fornito da | |
> > | L'anonimato per gli utilizzatori dell'informazione nel web è fornito da | |
Changed: | ||
< < | gli utenti dal logging del servizio stesso. Le tecniche | |
> > | gli utilizzatori dal logging del servizio stesso. Le tecniche | |
Changed: | ||
< < | agli utenti dell'informazione, ma solo per quel che concerne il nascondere quale porzione | |
> > | agli utilizzatori dell'informazione, ma solo per quel che concerne il nascondere quale porzione | |
Changed: | ||
< < | stesso. TAZ[18] estende questa idea utilizzando catene di URL | |
> > | stesso. TAZ[18] estende quest'idea utilizzando catene di URL | |
Changed: | ||
< < | Entrambi si affidano a un unico server come sorgente ultima delle informazioni. Publius[30] aumenta la disponibilità distribuendo files come porzioni ridondanti tra n webservers, dei quali solo k sono necessari | |
> > | Entrambi si affidano ad un unico server come sorgente ultima delle informazioni. Publius[30] aumenta la disponibilità distribuendo file come porzioni ridondanti tra n webserver, dei quali solo k sono necessari | |
Changed: | ||
< < | distributed.net[15] ha dimostrato il concetto di associazione | |
> > | Distributed.net[15] ha dimostrato il concetto di associazione | |
Changed: | ||
< < | ``key-squatting''--inserting junk files under popular descriptions. | |
> > | "key-squatting"--inserting junk files under popular descriptions. | |
Changed: | ||
< < | ``similar'' key (determined by lexicographic distance) will be | |
> > | "similar" key (determined by lexicographic distance) will be | |
Changed: | ||
< < | is unable to contact any other nodes and returns a backtracking ``request failed'' message to b. Node b then tries its second choice, | |
> > | is unable to contact any other nodes and returns a backtracking "request failed" message to b. Node b then tries its second choice, | |
Changed: | ||
< < | similar to that key. It is therefore likely to gain more ``experience'' | |
> > | similar to that key. It is therefore likely to gain more "experience" | |
Changed: | ||
< < | if the London node fails or is shut down. (Note that ``along the way'' | |
> > | if the London node fails or is shut down. (Note that "along the way" | |
Changed: | ||
< < | detected, an ``all clear'' result will be propagated back to the | |
> > | detected, an "all clear" result will be propagated back to the | |
Changed: | ||
< < | Tutti i sistemi di conservazione delle informazioni devono tenere in considerazione il problema della capacità finita di conservare informazioni. I singoli gestori del nodo di Freenet possono configurare la grandezza dello spazio da dedicare ai loro magazzini di informazioni. La conservazione dei nodi ` trattata come una Cache LRU (Least Recently Used, ovvero usato meno di recente ndt) [29] nella quale i singoli dati sono mantenuti ordinati in ordine decrescente per data della più recente richiesta (o data di inserimento, se una voce non è mai stata richiesta). Quando arriva un nuovo file (o grazie a un nuovo inserimento o per una richiesta andata a buon fine) che potrebbe far aumentare la dimensione del magazzino di informazioni oltre la grandezza stabilita, i file usati meno di recente sono espulsi in ordine fino a che si crea lo spazio. Il risultante impatto sulla disponibilità è mitigato dal fatto che le voci della tabella di routing create quando i file espulsi sono arrivati per la prima volta rimarranno per un certo tempo, permettendo potenzialmente al nodo di procurarsi successivamente altre copie dalle fonti di dati originali. (Le voci della tabella di routing, infine, vengono anche cancellate in maniera simile quando la tabella si riempie, anche se saranno conservate più a lungo se sono più piccole.) | |
> > | Tutti i sistemi di conservazione delle informazioni devono tenere in considerazione il problema della capacità finita di conservare informazioni. I singoli gestori del nodo di Freenet possono configurare la grandezza dello spazio da dedicare alla memorizzaione dei dati (datastore). La conservazione da parte dei nodi ` trattata come una Cache LRU (Least Recently Used, ovvero usato meno di recente ndt) [29] nella quale i singoli dati sono mantenuti ordinati in ordine decrescente per data della più recente richiesta (o data di inserimento, se una voce non è mai stata richiesta). Quando arriva un nuovo file (o grazie a un nuovo inserimento o per una richiesta andata a buon fine) che potrebbe far aumentare la dimensione del gli utilizzatori oltre la grandezza stabilita, i file usati meno di recente sono espulsi in ordine fino a che si crea lo spazio. Il risultante impatto sulla disponibilità è mitigato dal fatto che le voci della tabella di routing create quando i file espulsi sono arrivati per la prima volta rimarranno per un certo tempo, permettendo potenzialmente al nodo di procurarsi successivamente altre copie dalle fonti di dati originali. (Le voci della tabella di routing, infine, vengono anche cancellate in maniera simile quando la tabella si riempie, anche se saranno conservate più a lungo se sono più piccole.) | |
Changed: | ||
< < | A voler essere precisi, il magazzino di informazioni non è una cache, poichè l'insieme dei magazzini di informazioni sono tutte le informazioni che sono lì. Cioè, non c'è una copia ``permanente'' che viene replicata in una cache. Una volta che tutti i nodi hanno deciso, parlando collettivamente, di abbandondare un determinato file, esso non sarà più disponibile per la rete. Riguardo a ciò, Freenet è diversa dai sistemi come Eternity e Free Haven che cercano di dare garanzie sui tempi di vita dei file. | |
> > | A voler essere precisi, il datastore non è una cache, poiché l'insieme dei datastore sono tutte le informazioni che sono lì. Cioè, non c'è una copia "permanente" che viene replicata in una cache. Una volta che tutti i nodi hanno deciso, parlando collettivamente, di eliminare un determinato file, esso non sarà più disponibile per la rete. Riguardo a ciò, Freenet è diversa dai sistemi come Eternity e Free Haven che cercano di dare garanzie sui tempi di vita dei file. | |
Changed: | ||
< < | Il meccanismo della scadenza ha un aspetto svantaggioso, comunque, poichè permette che i documenti vecchi svaniscano naturalmente dopo esser stati rimpiazzati da documenti più nuovi. Se un documento vecchio è ancora usato e considerato prezioso per ragioni storiche, resterà in vita fino a quando continuerà ad essere richiesto. | |
> > | Il meccanismo della scadenza ha un aspetto svantaggioso, comunque, poiché permette che i documenti vecchi svaniscano naturalmente dopo esser stati rimpiazzati da documenti più nuovi. Se un documento vecchio è ancora usato e considerato prezioso per ragioni storiche, resterà in vita fino a quando continuerà ad essere richiesto. | |
Changed: | ||
< < | Per ragioni politiche o legali, può essere desiderabile per gli operatori dei nodi non conoscere esplicitamente i contenuti dei loro magazzini di informazioni. E' per questo che tutti i file conservati sono criptati. Le procedure di crittazione usate non mirano a proteggere il file--questo sarebbe impossibile siccome chi fa una richiesta (potenzialmente chiunque) deve essere capace di decrittare il file una volta ricevuto. Piuttosto, la finalità è che il gestore di un nodo possa credibilmente negare ogni conoscenza del contenuto del suo magazzino di dati, poichè tutto ciò che sa a priori è la file key, non la encryption key. Le encryption keys per i dati keyword-signed e signed-subspace possono essere ottenute solo con un procedimento di reverse su un hash, e le encryption keys per i dati content-hash non sono affatto correlate. Con una certa difficoltà, naturalmente, un attacco basato sul dizionario svelerà quali keys sono presenti--poichè esso lo deve fare per le richieste per poter funzionare-- ma la fatica che un tale tentativo richiederebbe è intesa a fornire una misura di protezione per i gestori del nodo. | |
> > | Per ragioni politiche o legali, può essere desiderabile per gli operatori dei nodi non conoscere esplicitamente i contenuti dei loro datastore. È per questo che tutti i file conservati sono criptati. Le procedure di crittazione usate non mirano a proteggere il file; questo sarebbe impossibile poiché chi fa una richiesta (potenzialmente chiunque) deve essere capace di decrittare il file una volta ricevuto. Piuttosto, la finalità è che il gestore di un nodo possa credibilmente negare ogni conoscenza del contenuto del suo magazzino di dati, poiché tutto ciò che sa a priori è la file key, non la encryption key. Le encryption keys per i dati keyword-signed e signed-subspace possono essere ottenute solo con un procedimento di reverse su un hash, e le encryption keys per i dati content-hash non sono affatto correlate. Con una certa difficoltà, naturalmente, un attacco basato sul dizionario svelerà quali chiavi sono presenti--poiché esso lo deve fare per le richieste per poter funzionare-- ma la fatica che un tale tentativo richiederebbe è intesa a fornire una misura di protezione per i gestori del nodo. | |
Changed: | ||
< < | Ogni messaggio include un transaction ID cosicchè i nodi possono tracciare lo stato di inserimenti e richieste. Questo design è pensato per permettere flessibilità nella scelta del meccanismo di trasporto per i messaggi, se sia TCP, UDP, o altre tecnologie come packet radio. | |
> > | Ogni messaggio include un transaction ID cosicché i nodi possono tracciare lo stato di inserimenti e richieste. Questo design è pensato per permettere flessibilità nella scelta del meccanismo di trasporto per i messaggi, se sia TCP, UDP, o altre tecnologie come packet radio. | |
Changed: | ||
< < | Usando il limite di hops-to-live scelto, il nodo inviante fa partire un timer per la quantità di tempo prevista per contattare quei nodi, dopodichè supporrà un fallimento. Mentre la richiesta avviene, il nodo remoto può periodicamente mandare indietro messaggi Reply.Restart che indicano che i messaggi si sono bloccati aspettando timeouts della rete, cosicchè il nodo inviante sa di dover estendere il suo timer. | |
> > | Usando il limite di hops-to-live scelto, il nodo inviante fa partire un timer per la quantità di tempo prevista per contattare quei nodi, dopodiché supporrà un fallimento. Mentre la richiesta avviene, il nodo remoto può periodicamente mandare indietro messaggi Reply.Restart che indicano che i messaggi si sono bloccati aspettando timeouts della rete, cosicché il nodo inviante sa di dover estendere il suo timer. | |
Changed: | ||
< < | Se la richiesta è portata a termine con successo, il nodo remoto risponderà con un messaggio Send.Data che contiene i dati richiesti e l'indirizzo del nodo che lo ha fornito (è possibile che esso sia falso). Se la richiesta non è portata a termine con successo e le sue hops-to-live sono state usate completamente cercando di soddisfarla, il nodo remoto risponderà con un NotFound?. Il nodo inviante allora decrementerà le hops-to-live del Send.Data (o del NotFound?) e lo passerà, a meno che esso sia il vero originatore della richiesta. Entrambi questi messaggi termino la transazione e lasciano ogni risorsa che occupavano. Comunque, se ci sono ancora hops-to-live rimanenti, di solito perchè la richiesta è andata verso un vicolo cieco dove non c'è nessun sentiero che non genera un loop, il nodo remoto risponderà con una Request.Continue dando il numero di hops-to-live rimanenti. Il nodo inviante allora tenterà di contattare il prossimo nodo dalla sua tabella di routing. Esso manderà anche un messaggio Reply.Restart. | |
> > | Se la richiesta è portata a termine con successo, il nodo remoto risponderà con un messaggio Send.Data che contiene i dati richiesti e l'indirizzo del nodo che lo ha fornito (è possibile che esso sia falso). Se la richiesta non è portata a termine con successo e le sue hops-to-live sono state usate completamente cercando di soddisfarla, il nodo remoto risponderà con un NotFound?. Il nodo inviante allora decrementerà le hops-to-live del Send.Data (o del NotFound?) e lo passerà, a meno che esso sia il vero originatore della richiesta. Entrambi questi messaggi termino la transazione e lasciano ogni risorsa che occupavano. Comunque, se ci sono ancora hops-to-live rimanenti, di solito perché la richiesta è andata verso un vicolo cieco dove non c'è nessun sentiero che non genera un loop, il nodo remoto risponderà con una Request.Continue dando il numero di hops-to-live rimanenti. Il nodo inviante allora tenterà di contattare il prossimo nodo dalla sua tabella di routing. Esso manderà anche un messaggio Reply.Restart. | |
Changed: | ||
< < | Performance analysis | |
> > | Analisi delle prestazioni | |
Changed: | ||
< < | We performed simulations on a model of this system to give some indications about its performance. Here we summarize the most important results; for full details, see [21]. | |
> > | Abbiamo eseguito delle simulazioni su un modello di questo sistema per ottenere alcune indicazioni sulle prestazioni ottenibili. Di seguito troverete i risultati più importanti; per avere dettagli completi, guarda [21]. | |
Changed: | ||
< < | Network convergence | |
> > | Convergenza della rete | |
Changed: | ||
< < |
To test the adaptivity of the network routing, we created a test
network of 1000 nodes. Each node had a datastore size of 50 items and
a routing table size of 250 addresses. The datastores were
initialized to be empty, and the routing tables were initialized to
connect the network in a regular ring-lattice topology in which each
node had routing entries for its two nearest neighbors on either side.
The keys associated with these routing entries were set to be hashes
of the destination nodes' addresses. Using hashes has the useful
property that the resulting keys are both random and consistent (that
is, all references to a given node will use the same key).
Inserts of random keys were sent to random nodes in the network, interspersed randomly with requests for randomly-chosen keys known to have been previously inserted, using a hops-to-live of 20 for both. Every 100 timesteps, a snapshot of the network was taken and its performance measured using a set of probe requests. Each probe consisted of 300 random requests for previously-inserted keys, using a hops-to-live of 500. We recorded the resulting distribution of request pathlengths, the number of hops actually taken before finding the data. If the request did not find the data, the pathlength was taken to be 500. | |
> > |
Per testare l'adattività del routing di rete, abbiamo creato
un network di 1000 nodi. Ogni nodo permette la memorizzazione di
50 "oggetti" all'interno del proprio datastore e, la gestione
di 250 indirizzi nella propria tabella di routing. Ogni datastore
è stato inizializzato con valori di default uguali a NULL, e le
tabelle di routing secondo una configurazione che prende il nome di
"lattice finito" in cui ogni nodo mantiene all'interno della propria
tabella, gli indirizzi dei due nodi ad esso più "vicini". Le chiavi
associate a questi indirizzi sono state create utilizzando l'hash
degli stessi indirizzi remoti. Utilizzare una funzione di hash, ci
consente di avere chiavi che sono casuali e consistenti (ogni
riferimento ad un dato nodo utilizza la stessa chiave).
Abbiamo inviato alcune richieste di inserimento di chiavi casuali ad altrettanti nodi scelti in modo accidentale, intercalate con alcune richieste (inviate sempre a nodi scelti a caso) per chiavi di cui sapevano già che era stato effettuato l'inserimento (la "profondità" del campo Hops-To-Live è stato impostato a 20 sia per i messaggi di inserimento che per quelli di richiesta). Ogni 100 "passaggi", l'intera rete è stata analizzata al fine di ricavare le prestazioni offerte dall'attuale struttura, utilizzando un set di richieste-prova. Ogni prova consisteva nella richiesta di 300 chiavi precedentemente inserite utilizzando un HTL di 500. Registrando i risultati cosí acquisiti, abbiamo potuto disegnare il grafico degli "hop" richiesti (lunghezza del percorso), prima di trovare i dati. Se la richiesta non andava a buon fine, la lunghezza del percorso la impostavamo a 500. | |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < | We can see that the initially high pathlengths decrease rapidly over time. In the beginning, few requests succeed at all, but as the network converges, the median request pathlength drops to just six. | |
> > | Possiamo vedere come la lunghezza dei percorsi iniziali, inizialmente elevata, decresca rapidamente nel tempo. All'inizio poche richieste di fatto vengono soddisfatte, ma mentre la rete converge, la media della lunghezza delle richieste, crolla a 6. | |
Changed: | ||
< < | Scalability | |
> > | Scalabilità | |
Changed: | ||
< < |
Next, we examined the scalability of a growing network. Starting from
a small network of 20 nodes initialized in the same manner as the previous
section, we added new nodes over time and measured the change in the request
pathlength.
Inserts and requests were simulated randomly as before. Every five timesteps, a new node was created and added to the network by simulating a node announcement message with hops-to-live of 10 sent from it to a randomly-chosen existing node. The key assigned by this announcement was taken to be the hash of the new node's address. Note that this procedure does not necessarily imply a linear rate of network growth, but rather a linear relationship between the request rate and the growth rate. Since it seems likely that both rates will be proportional to network size (yielding an exponential growth rate in real, as opposed to simulated, time), we believe that this model is justifiable. | |
> > |
Successivamente, abbiamo analizzato la scalabilità di una rete "nascente".
Partendo da 20 nodi, inizializzati nel modo visto prima, abbiamo aggiunto
nodi con il passare del tempo e misurato il cambiamento nelle "lunghezze
del cammino" per raggiungere i dati.
Inserimenti e Richieste sono stati simulati casualmente come visto prima. Ogni cinque passaggi, un nuovo nodo è stato creato e aggiunto alla rete simulando un "node announcement" con un HTL di 10 inviato ad un nodo già esistente. La chiave assegnata da questo "annuncio" è stata scelta come l'hash dell'indirizzo del nuovo nodo. Notate che questa procedura non implica necessariamente una tasso lineare nella crescita della rete, ma piuttosto una relazione lineare tra il tasso di richieste e il tasso di crescita. | |
Changed: | ||
< < | We can see that the pathlength scales approximately logarithmically, with a change of slope near 40,000 nodes. We posit that the slope change is a result of routing tables becoming filled and could be improved by adding a small number of nodes with larger routing tables. Section 5.4 discusses this issue in more depth. Where our routing tables were limited to 250 entries by the memory requirements of the simulation, real Freenet nodes should easily be able to hold thousands of entries. Nonetheless, even this limited network appears capable of scaling to one million nodes with a median pathlength of just 30. Note also that the network was grown continuously, without any steady-state convergence period. | |
> > | Possiamo notare come i "passi" necessari a raggiungere i dati tendono a crescere, in numero, secondo una funzione logaritmica, con un repentino cambio intorno ai 40.000 nodi. Abbiamo supposto che questo cambiamento (crollo) improvviso sia dovuto al completo riempimento delle tabelle di routing e puó essere facilmente eliminato inserendo alcuni nodi con tabelle decisamente piú "ampie". La sezione 5.4 discute queste questioni piú in dettaglio. Mentre le tabelle di routing da noi utilizzate per la simulazione sono limitate a 250 record, i nodi Freenet reali dovrebbero facilmente contenere migliaia di record. Non di meno val la pena far notare, che anche con una rete così limitata, riusciamo a scalare ad un milione di nodi con un percorso medio di 30 salti. | |
Changed: | ||
< < | Finally, we considered the fault-tolerance of the network. Starting with a network grown to 1000 nodes by the previous method, we progressively removed randomly-chosen nodes from the network to simulate node failures. Figure 4 shows the resulting evolution of the request pathlength, averaged over ten trials. | |
> > | Per concludere, abbiamo considerato la fault-tolerance del network. Partendo dalla rete di 1000 nodi ottenuta dal metodo precedente, abbiamo progressivamente rimosso (a caso...) alcuni nodi al fine di simularne il guasto degli stessi. La figura 4 mostra il cambiamento dei pathlengh dopo una decina di prove. | |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < | The network is surprisingly robust against quite large failures. The median pathlength remains below 20 even when up to 30% of nodes fail. | |
> > | La rete è sorprendentemente robusta anche dopo numerosi nodi "guasti". Il pathlenght medio rimane sotto 20 anche con il 30% di nodi falliti. | |
Changed: | ||
< < | The scalability and fault-tolerance characteristics of Freenet can be explained in terms of a small-world network model[<a | |
> > | La scalabilità e le caratteristiche fault-tolerance di Freenet possono essere spiegate in termini di un modello di rete small-world [<a | |
Changed: | ||
< < | HREF="#Albert">3]. In a small-world network, the majority of nodes have only relatively few, local, connections to other nodes, while a small number of nodes have large, wide-ranging sets of connections. Small-world networks permit efficient short paths between arbitrary points because of the shortcuts provided by the well-connected nodes, as evidenced by examination of Milgram's letter-passing experiment[<a HREF="#Milgram">23] and the Erdös number game cited by Watts and Strogatz[<a | |
> > | HREF="#Albert">3]. In una rete "small-world", la maggioranza dei nodi presenti hanno poche connessioni locali con gli altri nodi, mentre un esiguo numero di nodi possiede un numero elevato e largamente distribuito di connessioni. Una rete "Small-world" permette di avere "tracciati corti" tra punti arbitrari della rete grazie alle connessioni locali della maggioranza dei nodi (come si diceva sopra), come evidenziato dall'esperimento di Milgram [<a HREF="#Milgram">23] e il "gioco dei numeri di Erdös" spiegato da Watts e Strogatz[<a | |
Changed: | ||
< < | Is Freenet a small world? A key factor in the identification of a small-world network is the existence of a scale-free power-law distribution of links within the network, as the tail of such distributions provides the highly-connected nodes needed to create short paths. Figure 5 shows the average distribution of links (i.e. routing table entries) in the 1000-node Freenet networks used in the previous section. | |
> > | Si può affermare che Freenet è una rete "small-world" ? Un fattore chiave per l'identificazione di una rete "small-world" è l'esistenza di una "distribuzione esponenziale" del numero dei link tra i nodi della rete che induce l'esistenza di nodi "altamente" connessi a forzare brevi percorsi tra di essi. La figura 5 mostra la distribuzione media dei link in una rete Freenet di 1000 nodi utilizzata nella sessione precedente. | |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < |
We see that the distribution closely approximates a power law, except
for the anomalous point representing nodes with filled 250-entry
routing tables. When we used differently-sized routing tables, this
cutoff point moved but the power-law character of the distribution
remained the same.
In addition to providing short paths, the power-law distribution also gives small-world networks a high degree of fault-tolerance. Random failures are most likely to knock out nodes from the majority that possess only a small number of connections. The loss of poorly-connected nodes will not greatly affect routing in the network. It is only when the number of random failures becomes high enough to knock out a significant number of well-connected nodes that routing performance will be noticeably affected. | |
> > |
Possiamo vedere come la distribuzione si avvicini ad un andamento
esponenziale, eccetto per un punto "anomalo" dovuto al riempimento
delle tabelle di routing. Nel momento in cui utilizziamo tabelle di
routing di differente capacità, questo punto "critico" si sposta
rimanendo invariata il carattere esponenziale della distribuzione.
Oltre a ridurre il "cammino" minimo per raggiungere i dati, la distribuzione esponenziale da ad una rete "small-world" un alto grado di fault-tolerance. I fallimenti casuali di fatto eliminano dalla rete quei nodi che non posseggono un piccolo numero di connessioni. La perdita di nodi "poco connessi", non incidono piú di tanto il processo di routing all'interno della rete. Solo quando il fallimento (guasto n.d.t) di molti nodi comincia a crescere (eliminando dalla rete un significativo numero di nodi "ben connessi"), le performance subiscono un degrado importante. | |
Changed: | ||
< < | L'obiettivo primario della sicurezza di Freenet è proteggere l'anonimato di coloro che richiedono o inseriscono file. Inoltre è importante proteggere l'identità di coloro che fisicamente memorizzano le informazioni. Anche se chiunque può banalmente fare in modo che un nodo memorizzi un dato file, richiedendolo attraverso quel nodo, ciò che è importante è che quel file resti memorizzato anche presso altri | |
> > | L'obiettivo primario della sicurezza di Freenet è proteggere l'anonimato di coloro che richiedono o inseriscono file. Inoltre è importante proteggere l'identità di coloro che fisicamente memorizzano le informazioni. Anche se chiunque può banalmente fare in modo che un nodo memorizzi un dato file, richiedendolo attraverso quel nodo, ciò che è importante è che quel file resti memorizzato anche presso altri | |
Changed: | ||
< < | proprietà della comunicazione anonima su tre assi. Il primo asse è rappresenta il tipo di anonimato: anonimato del mittente | |
> > | proprietà della comunicazione anonima su tre assi. Il primo asse è rappresenta il tipo di anonimato: anonimato del mittente | |
Changed: | ||
< < | non può identificare chi ha originato il messaggio o chi è supposto riceverlo. Il secondo asse è il nemico in questione: | |
> > | non può identificare chi ha originato il messaggio o chi è supposto riceverlo. Il secondo asse è il nemico in questione: | |
Changed: | ||
< < | Freenet). Il terzo asse è il grado di anonimato, che varia da "riservatezza assoluta" (impossibilità di rilevare il fatto che | |
> > | Freenet). Il terzo asse è il grado di anonimato, che varia da "riservatezza assoluta" (impossibilità di rilevare il fatto che | |
Changed: | ||
< < | non ha maggior probabilità di essere identificato come tale | |
> > | non ha maggior probabilità di essere identificato come tale | |
Changed: | ||
< < | (il fatto che il vero mittente sia tale non è più probabile | |
> > | (il fatto che il vero mittente sia tale non è più probabile | |
Changed: | ||
< < | "smascherato con le prove" (il nemico può dimostrare ad altri chi è il mittente). | |
> > | "smascherato con le prove" (il nemico può dimostrare ad altri chi è il mittente). | |
Changed: | ||
< < | Poiché la comunicazione su Freenet non è diretta a destinatari specifici, l'anonimato del ricevente può essere | |
> > | Poiché la comunicazione su Freenet non è diretta a destinatari specifici, l'anonimato del ricevente può essere | |
Changed: | ||
< < | della chiave, la riservatezza della chiave non può essere ottenuta con lo schema Freenet di base (vedi però la discussione sul 'pre-routing' più sotto). L'uso di funzioni hash come chiavi permette di difendersi contro l'intercettazione casuale, ma è | |
> > | della chiave, la riservatezza della chiave non può essere ottenuta con lo schema Freenet di base (vedi però la discussione sul 'pre-routing' più sotto). L'uso di funzioni hash come chiavi permette di difendersi contro l'intercettazione casuale, ma è | |
Changed: | ||
< < | Le proprietà di anonimato di Freenet sulla base di questa tassonomia | |
> > | Le proprietà di anonimato di Freenet sulla base di questa tassonomia | |
Changed: | ||
< < | Proprietà di anonimato in Freenet. | |
> > | Proprietà di anonimato in Freenet. | |
Changed: | ||
< < | Contro un insieme di nodi maligni, l'anonimato del mittente è preservato oltre ogni sospetto poiché un nodo sul percorso di richiesta non è | |
> > | Contro un insieme di nodi maligni, l'anonimato del mittente è preservato oltre ogni sospetto poiché un nodo sul percorso di richiesta non è | |
Changed: | ||
< < | probabilità che una richiesta che arriva al nodo a sia inoltrata o gestita direttamente e della probabilità che a scelga un particolare nodo b per inoltrare la richiesta. Tale analisi non è comunque applicabile | |
> > | probabilità che una richiesta che arriva al nodo a sia inoltrata o gestita direttamente e della probabilità che a scelga un particolare nodo b per inoltrare la richiesta. Tale analisi non è comunque applicabile | |
Changed: | ||
< < | il dato richiesto nel datastore più che da fattori random. Se una richiesta viene | |
> > | il dato richiesto nel datastore più che da fattori random. Se una richiesta viene | |
Changed: | ||
< < | In ogni caso, il valore di "depth" può fornire alcune indicazioni sulla distanza del nodo di origine, anche se è nascosta dalla selezione casuale della "depth" | |
> > | In ogni caso, il valore di "depth" può fornire alcune indicazioni sulla distanza del nodo di origine, anche se è nascosta dalla selezione casuale della "depth" | |
Changed: | ||
< < | Non vi è protezione dei messaggi contro l'intercettazione sul percorso tra l'utente e il primo nodo. Poiché il primo nodo può agire da | |
> > | Non vi è protezione dei messaggi contro l'intercettazione sul percorso tra l'utente e il primo nodo. Poiché il primo nodo può agire da | |
Changed: | ||
< < | sono crittati contro l'intercettazione, ma è comunque possibile effettuare un'analisi del traffico (ad esempio si può osservare un messaggio | |
> > | sono crittati contro l'intercettazione, ma è comunque possibile effettuare un'analisi del traffico (ad esempio si può osservare un messaggio | |
Changed: | ||
< < | messaggio è stato generato localmente). | |
> > | messaggio è stato generato localmente). | |
Changed: | ||
< < | La riservatezza delle chiavi ed una più forte protezione dell'anonimato del mittente possono essere ottenute introducendo un ``pre-routing'' dei | |
> > | La riservatezza delle chiavi ed una più forte protezione dell'anonimato del mittente possono essere ottenute introducendo un "pre-routing" dei | |
Changed: | ||
< < | determinano il percorso che il messaggio seguirà (bypassando il normale | |
> > | determinano il percorso che il messaggio seguirà (bypassando il normale | |
Changed: | ||
< < | La protezione per la sorgente dei dati è assicurata dalla riscrittura | |
> > | La protezione per la sorgente dei dati è assicurata dalla riscrittura | |
Changed: | ||
< < | corso della richiesta. Non è possibile decidere se il nodo a valle | |
> > | corso della richiesta. Non è possibile decidere se il nodo a valle | |
Changed: | ||
< < | memorizzato il dato, poiché continuano con probabilità finita | |
> > | memorizzato il dato, poiché continuano con probabilità finita | |
Changed: | ||
< < | consistente numero di richieste di file correlati può fornire tuttavia una base | |
> > | consistente numero di richieste di file correlati può fornire tuttavia una base | |
Changed: | ||
< < | catena di richiesta costituisce una grave minaccia, e non solo per l'integrità | |
> > | catena di richiesta costituisce una grave; minaccia, e non solo per l'integrità | |
Changed: | ||
< < | questo non è attuabile poiché dati non autentici possono essere | |
> > | questo non è attuabile poiché dati non autentici possono essere | |
Changed: | ||
< < | Infine, si può prevedere un certo numero di attacchi di tipo denial-of-service. La minaccia più grave è che un utente cerchi di saturare la capacità di memorizzazione della rete con l'inserimento di grandi quantità di dati non significativi. Un'interessante possibilità di contrastare questi attacchi è l'uso di schemi come l'Hash Cash [<a | |
> > | Infine, si può prevedere un certo numero di attacchi di tipo denial-of-service. La minaccia più grave è che un utente cerchi di saturare la capacità di memorizzazione della rete con l'inserimento di grandi quantità di dati non significativi. Un'interessante possibilità di contrastare questi attacchi è l'uso di schemi come l'Hash Cash [<a | |
Changed: | ||
< < | inserisce un dato debba effettuare un'elaborazione complessa come ``tassa'' per l'inserimento, in modo da rallentare l'attacco. Un'altra alternativa è quella | |
> > | inserisce un dato debba effettuare un'elaborazione complessa come "tassa" per l'inserimento, in modo da rallentare l'attacco. Un'altra alternativa è quella | |
Changed: | ||
< < | per i file ``stabili'', che hanno cioè già ricevuto un certo numero di richieste. I nuovi inserimenti possono solo rimpiazzare altri file ``nuovi''. In questo modo, l'inserimento massiccio di dati non significativi può solo paralizzare | |
> > | per i file "stabili", che hanno cioè già ricevuto un certo numero di richieste. I nuovi inserimenti possono solo rimpiazzare altri file "nuovi". In questo modo, l'inserimento massiccio di dati non significativi può solo paralizzare | |
Changed: | ||
< < | file importanti. Risulta infatti difficile ``legittimare'' artificialmente | |
> > | file importanti. Risulta infatti difficile "legittimare" artificialmente | |
Changed: | ||
< < | oltre. D'altra parte, non è possibile interrogare direttamente i nodi a valle poichè non se ne conosce l'identità. In ogni caso, l'adozione di questo schema può compromettere la sopravvivenza di dati legittimi per un | |
> > | oltre. D'altra parte, non è possibile interrogare direttamente i nodi a valle poiché non se ne conosce l'identità. In ogni caso, l'adozione di questo schema può compromettere la sopravvivenza di dati legittimi per un | |
Changed: | ||
< < | Si può tentare di rimpiazzare file esistenti inserendo versioni diverse di essi sotto le stesse chiavi. Questo tipo di attacco non è possibile | |
> > | Si può tentare di rimpiazzare file esistenti inserendo versioni diverse di essi sotto le stesse chiavi. Questo tipo di attacco non è possibile | |
Changed: | ||
< < | una chiave keyword-signed, d'altra parte, può portare alla coesistenza delle due versioni nella rete. Le modalità con cui i nodi trattano le collisioni | |
> > | una chiave keyword-signed, d'altra parte, può portare alla coesistenza delle due versioni nella rete. Le modalità con cui i nodi trattano le collisioni | |
Changed: | ||
< < | da rendere questi attacchi più difficili. Il successo di un attacco a rimpiazzo può essere misurato con il rapporto tra il numero di versioni originali del file e il numero di versioni corrotte presenti nel sistema. In ogni caso, maggiore è il | |
> > | da rendere questi attacchi più difficili. Il successo di un attacco a rimpiazzo può essere misurato con il rapporto tra il numero di versioni originali del file e il numero di versioni corrotte presenti nel sistema. In ogni caso, maggiore è il | |
Changed: | ||
< < | nell'inserimento), maggiore è la probabilità che si realizzi una collisione, | |
> > | nell'inserimento), maggiore è la probabilità che si realizzi una collisione, | |
Changed: | ||
< < | anonima del sistema, è impossibile decidere con esattezza quanti utenti vi siano | |
> > | anonima del sistema, è impossibile decidere con esattezza quanti utenti vi siano | |
Changed: | ||
< < | e visualizzazione che permetterà di effettuare prove più rigorose sul protocollo e sul meccanismo di instradamento. È necessaria nna simulazione più è | |
> > | e visualizzazione che permetterà di effettuare prove più rigorose sul protocollo e sul meccanismo di instradamento. È necessaria nna simulazione più è | |
Changed: | ||
< < | variazione della capacità e della larghezza di banda dei nodi, e di dimensioni maggiori | |
> > | variazione della capacità e della larghezza di banda dei nodi, e di dimensioni maggiori | |
Changed: | ||
< < | Questo materiale è basato parzialmente su lavori patrocinati da una | |
> > | Questo materiale è basato parzialmente su lavori patrocinati da una | |
Changed: | ||
< < | S. Adler, ``The Slashdot effect: an analysis of three Internet publications,'' Linux Gazette issue 38, March 1999. | |
> > | S. Adler, "The Slashdot effect: an analysis of three Internet publications," Linux Gazette issue 38, March 1999. | |
Changed: | ||
< < | R. Albert, H. Jeong, and A. Barabási, ``Error and attack tolerance of complex networks,'' Nature 406, | |
> > | R. Albert, H. Jeong, and A. Barabási, "Error and attack tolerance of complex networks," Nature 406, | |
Changed: | ||
< < | R.J. Anderson, ``The Eternity service,'' in Proceedings of the 1st | |
> > | R.J. Anderson, "The Eternity service," in Proceedings of the 1st | |
Changed: | ||
< < | O. Berthold, H. Federrath, and S. Köpsell, ``Web MIXes: a system for anonymous and unobservable Internet access,'' in Proceedings | |
> > | O. Berthold, H. Federrath, and S. Köpsell, "Web MIXes: a system for anonymous and unobservable Internet access," in Proceedings | |
Changed: | ||
< < | D.L. Chaum, ``Untraceable electronic mail, return addresses, and digital pseudonyms,'' Communications of the ACM 24(2), 84-88 (1981). | |
> > | D.L. Chaum, "Untraceable electronic mail, return addresses, and digital pseudonyms," Communications of the ACM 24(2), 84-88 (1981). | |
Changed: | ||
< < | P. Yianilos, ``A prototype implementation of archival intermemory,'' | |
> > | P. Yianilos, "A prototype implementation of archival intermemory," | |
Changed: | ||
< < | B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, ``Private information retrieval,'' Journal of the ACM 45(6), 965-982 (1998). | |
> > | B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, "Private information retrieval," Journal of the ACM 45(6), 965-982 (1998). | |
Changed: | ||
< < | I. Clarke, ``A distributed decentralised information storage and retrieval system,'' unpublished report, Division of | |
> > | I. Clarke, "A distributed decentralised information storage and retrieval system," unpublished report, Division of | |
Changed: | ||
< < | L. Cottrell, ``Frequently asked questions about Mixmaster remailers,'' http://www.obscura.com/~loki/remailer/mixmaster-faq.html | |
> > | L. Cottrell, "Frequently asked questions about Mixmaster remailers," http://www.obscura.com/~loki/remailer/mixmaster-faq.html | |
Changed: | ||
< < | R. Dingledine, M.J. Freedman, and D. Molnar, ``The Free Haven project: distributed anonymous storage service,'' in Proceedings of the | |
> > | R. Dingledine, M.J. Freedman, and D. Molnar, "The Free Haven project: distributed anonymous storage service," in Proceedings of the | |
Changed: | ||
< < | D.J. Ellard, J.M. Megquier, and L. Park, ``The INDIA protocol,'' http://www.eecs.harvard.edu/~ellard/India-WWW/ | |
> > | D.J. Ellard, J.M. Megquier, and L. Park, "The INDIA protocol," http://www.eecs.harvard.edu/~ellard/India-WWW/ | |
Changed: | ||
< < | I. Goldberg and D. Wagner, ``TAZ servers and the rewebber network: enabling anonymous publishing on the world wide web,'' First | |
> > | I. Goldberg and D. Wagner, "TAZ servers and the rewebber network: enabling anonymous publishing on the world wide web," First | |
Changed: | ||
< < | D. Goldschlag, M. Reed, and P. Syverson, ``Onion routing for anonymous and private Internet connections,'' Communications of the ACM 42(2), 39-41 (1999). | |
> > | D. Goldschlag, M. Reed, and P. Syverson, "Onion routing for anonymous and private Internet connections," Communications of the ACM 42(2), 39-41 (1999). | |
Changed: | ||
< < | T. Hong, ``Performance,'' in Peer-to-Peer, ed. by A. Oram. O'Reilly: | |
> > | T. Hong, "Performance," in Peer-to-Peer, ed. by A. Oram. O'Reilly: | |
Changed: | ||
< < | B.A. Huberman and L.A. Adamic, ``Growth dynamics of the world-wide web,'' Nature 401, 131 (1999). | |
> > | B.A. Huberman and L.A. Adamic, "Growth dynamics of the world-wide web," Nature 401, 131 (1999). | |
Changed: | ||
< < | S. Milgram, ``The small world problem,'' Psychology Today 1(1), | |
> > | S. Milgram, "The small world problem," Psychology Today 1(1), | |
Changed: | ||
< < | M.K. Reiter and A.D. Rubin, ``Anonymous web transactions with Crowds,'' Communications of the ACM 42(2), 32-38 (1999). | |
> > | M.K. Reiter and A.D. Rubin, "Anonymous web transactions with Crowds," Communications of the ACM 42(2), 32-38 (1999). | |
Changed: | ||
< < | M. Richtel and S. Robinson, ``Several web sites are attacked on day after assault shut Yahoo,'' The New York Times, February 9, 2000. | |
> > | M. Richtel and S. Robinson, "Several web sites are attacked on day after assault shut Yahoo," The New York Times, February 9, 2000. | |
Changed: | ||
< < | J. Rosen, ``The eroded self,'' The New York Times, April 30, 2000. | |
> > | J. Rosen, "The eroded self," The New York Times, April 30, 2000. | |
Changed: | ||
< < | M. Waldman, A.D. Rubin, and L.F. Cranor, ``Publius: a robust, tamper-evident, censorship-resistant, web publishing system,'' in Proceedings of the Ninth USENIX Security Symposium, Denver, CO, USA | |
> > | M. Waldman, A.D. Rubin, and L.F. Cranor, "Publius: a robust, tamper-evident, censorship-resistant, web publishing system," in Proceedings of the Ninth USENIX Security Symposium, Denver, CO, USA | |
Changed: | ||
< < | D. Watts and S. Strogatz, ``Collective dynamics of `small-world' networks,'' | |
> > | D. Watts and S. Strogatz, "Collective dynamics of `small-world' networks," | |
Changed: | ||
< < |
| |
> > |
| |
Changed: | ||
< < |
| |
> > |
|
<<O>> Difference Topic ICSI (r1.1 - 21 Jan 2002 - MarcoCalamari) |
Added: | |||||
> > |
%META:TOPICINFO{author="MarcoCalamari" date="1011607020" format="1.0" version="1.1"}%
%META:TOPICPARENT{name="Publicity"}%
Freenet: Un sistema anonimo distribuito di memorizzazione e ricerca di informazioni
Testo approvato il 1° luglio 2000 Sunto:
Si descrive qui Freenet, un'applicazione adattiva peer-to-peer in rete che
consente di pubblicare, riprodurre e ricercare dati salvaguardando
l'anonimato degli autori e dei lettori. Freenet opera come una rete di nodi identici
che, collettivamente, mettono in comune il loro spazio di memoria per memorizzare
file di dati e cooperano tra di loro per inoltrare le richieste verso
le più probabili collocazioni fisiche dei dati stessi.
Non vengono utilizzati né la ricerca broadcast né un indice centralizzato delle
collocazioni dei dati; il riferimento ai file avviene secondo una modalità indipendente dalle
collocazioni, ed i file vengono riprodotti dinamicamente in località vicine ai richiedenti
e cancellati dalle località dove non si riscontra interesse.
E' impossibile scoprire la vera origine o destinazione di un file in transito nella rete,
ed è difficile per un operatore di un nodo determinare o attribuirgli la responsabilità
del contenuto concreto del suo nodo.
IntroduzioneI sistemi computerizzati in rete stanno acquistando sempre maggiore importanza come mezzo preferito per memorizzare e scambiare informazioni. Tuttavia, i sistemi attuali offrono ai loro utenti scarsa privacy e, di norma, memorizzano ogni elemento dei dati soltanto in uno o pochi posti fissi, creando un punto debole centrale. Gli autori ed i lettori desiderano però salvaguardare la propria privacy riguardo a vari tipi d'informazioni delicate[28], ed è inopportuno che vi siano punti deboli centrali, sui quali potrebbe intervenire chi voglia danneggiare il sistema togliendogli dati[11,27] o che, semplicemente, potrebbero rivelarsi sovraccarichi in caso d'interessamento eccessivo[1]; sono quindi necessari sistemi che offrano maggiore sicurezza e affidabilità. Noi stiamo sviluppando Freenet, un sistema distribuito di memorizzazione e di ricerca d'informazioni, che intende soddisfare queste esigenze di privacy e di disponibilità. Freenet opera come file system distribuito e indipendente dalla collocazione, attraverso numerosi singoli computer, che consentono di immettere, memorizzare e ricercare i file anonimamente. Gli obiettivi principali di questo progetto sono cinque:
Il sistema è progettato per rispondere in forma adattiva a schemi d'uso, spostando, riproducendo e cancellando i file con modalità trasparenti, secondo le necessità, per offrire un servizio efficiente senza dover ricorrere a ricerche broadcast o ad indici centralizzati delle collocazioni dei dati. Non si intende garantire la memorizzazione permanente dei file, anche se si auspica di riunire un numero sufficiente di nodi aventi capacità di memorizzazione sufficiente per poter conservare a tempo indeterminato la massima parte dei file. Inoltre, il sistema opera al livello delle applicazioni e, pur essendo indipendente dal trasporto, presume la presenza di uno strato di trasporto sicuro. Scopo del sistema è preservare l'anonimato non per l'utilizzo generale della rete ma soltanto per le operazioni con i file di Freenet. Freenet è attualmente in sviluppo come progetto di software gratuito su Sourceforge, e una versione preliminare si può scaricare dal sito http://www.freenetproject.org/. Il nucleo del sistema è il lavoro iniziale svolto dal primo autore presso l'Università di Edimburgo[12].
Attività correlateIn quest'area si possono identificare diverse branchie di attività correlate a Freenet. Il remailer Mixmaster[13] per le email, l'onion routing[19] e Freedom[32] per il traffico tcp/ip generico hanno implementato i canali punto punto anonimi basati sullo schema mix-net di Chaum[8] Tuttavia questi canali non sono in sè facilmente adattabili alla pubblicazione "uno a molti" e sono meglio visti come complemento a Freenet dal momento che non supportano l'accesso a file e l'archiviazione. L'anonimato per gli utenti dell'informazione nel contesto web è fornito da servizi di proxy da browser come Anonymizer[6], sebbene questi non forniscono protezione per chi offre l'informazione e non proteggono gli utenti dal logging del servizio stesso. Le tecniche di recupero di informazioni private[10] danno garanzie molto più valide agli utenti dell'informazione, ma solo per quel che concerne il nascondere quale porzione dell'informazione è stata recuperata e da quale specifico server. In molti casi, il fatto stesso di contattare un particolare server può rivelare ulteriori dati sull'informazione stessa recuperata, e questo sarebbe inutile solo se ogni server mantenesse tutte le informazioni (naturalmente questo ha poco peso). Il lavoro più vicino al nostro è il sistema Crowds di Reiter e Rubin[25], che usa un metodo simile di richieste proxy per gli utenti, sebbene Crowds in sè non memorizza informazioni e non protegge chi offre l'informazione. Berthold et al. propone Web MIXes[7], un sistema più forte che, per aumentare la sicurezza, utilizza il message padding (infarcimento dei messaggi), la riordinazione e i messaggi finti, ma ancora non protegge chi offre l'informazione. Il Rewebber[26] fornisce un grado di anonimato a chi offre informazioni web per mezzo di un servizio di URL criptate che è essenzialmente l'inverso del proxy da browser, ma con lo stesso limite di non fornire protezione contro la facoltà di "intervento" da parte del servizio stesso. TAZ[18] estende questa idea utilizzando catene di URL criptate nidificate che puntano a diversi server rewebber contattati in successione, tuttavia questo è vulnerabile all'analisi del traffico utilizzando il "replay". Entrambi si affidano a un unico server come sorgente ultima delle informazioni. Publius[30] aumenta la disponibilità distribuendo files come porzioni ridondanti tra n webservers, dei quali solo k sono necessari per ricostruire un file; Tuttavia, dal momento in cui l'identità degli stessi server non è anonima, un aggressore potrebbe rimuovere le informazioni forzando la chiusura di n-k+1 servers. La proposta The Eternity [5] mira ad archiviare informazioni permanentemente e in modo anonimo, sebbene manchi di specifiche su come localizzare efficentemente i files archiviati e risultando così più simile a un servizio di backup anonimo. Free Haven[14] è un interessante sistema di pubblicazione anonima che fa uso di una rete fidata e un meccanismo di scambio file per fornire una maggiore responsabilità dal lato server mantenendo l'anonimato. distributed.net[15] ha dimostrato il concetto di associazione in larga scala di risorse CPU tra i computer di molti utenti; Altri sistemi che fanno lo stesso, ma per lo spazio disco, sono Napster[24] e Gnutella[17]; il primo si affida a un server centrale per localizzare i files e il secondo impiega un'inefficiente ricerca broadcast. Nessuno dei due replica i files. Intermemory[9] e India[16] sono sistemi cooperanti di fileserver distribuito, pensati per l'archiviazione di dati a lungo termine secondo il concetto di Eternity, per cui i files sono divisi in porzioni ridondanti e distribuiti tra svariati partecipanti. Akamai[2] fornisce un servizio che replica i files nelle aree in cui si trovano gli utenti che ne usufruiscono, ma non è adeguato per chi volesse offrire il servizio a livello individuale (non come organizzazione). Nessuno di questi sistemi cerca di fornire anonimato.
ArchitectureFreenet is implemented as an adaptive peer-to-peer network of nodes that query one another to store and retrieve data files, which are named by location-independent keys. Each node maintains its own local datastore which it makes available to the network for reading and writing, as well as a dynamic routing table containing addresses of other nodes and the keys that they are thought to hold. It is intended that most users of the system will run nodes, both to provide security guarantees against inadvertently using a hostile foreign node and to increase the storage capacity available to the network as a whole. The system can be regarded as a cooperative distributed filesystem incorporating location independence and transparent lazy replication. Just as systems such as distributed.net[15] enable ordinary users to share unused CPU cycles on their machines, Freenet enables users to share unused disk space. However, where distributed.net uses those CPU cycles for its own purposes, Freenet is directly useful to users themselves, acting as an extension to their own hard drives. The basic model is that requests for keys are passed along from node to node through a chain of proxy requests in which each node makes a local decision about where to send the request next, in the style of IP (Internet Protocol) routing. Depending on the key requested, routes will vary. The routing algorithms for storing and retrieving data described in the following sections are designed to adaptively adjust routes over time to provide efficient performance while using only local, rather than global, knowledge. This is necessary since nodes only have knowledge of their immediate upstream and downstream neighbors in the proxy chain, to maintain privacy. Each request is given a hops-to-live limit, analogous to IP's time-to-live, which is decremented at each node to prevent infinite chains. Each request is also assigned a pseudo-unique random identifier, so that nodes can prevent loops by rejecting requests they have seen before. When this happens, the immediately-preceding node simply chooses a different node to forward to. This process continues until the request is either satisfied or exceeds its hops-to-live limit. Then the success or failure result is passed back up the chain to the sending node. No node is privileged over any other node, so no hierarchy or central point of failure exists. Joining the network is simply a matter of first discovering the address of one or more existing nodes through out-of-band means, then starting to send messages.
|
Topic ICSI . { View | Diffs | r1.3 | > | r1.2 | > | r1.1 | More } |
Revision r1.1 - 21 Jan 2002 - 09:57 GMT - MarcoCalamari Revision r1.2 - 22 Jan 2002 - 22:02 GMT - MarcoCalamari |
This website is distributed under the GNU Documentation License |