TWiki Home TWiki . IT . ICSI (r1.2 vs. r1.3) TWiki webs:
BG| DE | ES | FI | FR | Glossary | HU | IT | JA | Know | Main | NL | PT | Pub | RU | SL | TWiki | Test | ZH-CN? | ZH-TW? |
IT . { Home | Changes | Index | Search | Go }
 <<O>>  Difference Topic ICSI (r1.3 - 02 Feb 2002 - MarcoCalamari)
Changed:
<
<

Architecture

>
>

Architettura

Changed:
<
<

Freenet 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.

>
>

Freenet è implementato come una rete adaptive peer-to-peer di nodi che si interrogano l'un l'altro per conservare e recuperare files di dati, che hanno un nome dato da chiavi location-independent. Ogni nodo mantiene il suo datastore locale che è reso disponibile alla rete in lettura e scrittura, come una tabella di routing dinamica che contiene indirizzi di altri nodi e le chiavi che si pensa che loro conservino. È sottointeso che una gran parte degli utenti del sistema faranno girare dei nodi, sia per dare garanzie di sicurezza contro l'uso involontario di un nodo esterno ostile, sia per incrementare la capacità di immagazzinamento dell'interno network.

Added:
>
>

Il sistema può essere considerato come un filesystem cooperativo distribuito che incorpora indipendenza di locazione e una lazy replication transparente. Semplicemente come i sistemi come distributed.net[15] che à la possibilità a utenti ordinari di condividere i cicli di CPU non utilizzati sulle loro macchine, Freenet dà ai suoi utenti la possibilità di condividere lo spazio sul disco che non usano. Comunque, mentre distributed.net usa questi cicli di CPU per i propri scopi, Freenet è direttamente utile agli utenti stessi, comportandosi come un'estensione dei loro dischi rigidi.

Il modello di base è che le richieste di chiavi sono passate da nodo a nodo attraverso una catena di richieste proxy nella quale ogni nodo fa una decisione locale su dove mandare dopo la richiesta, nello stile del routing IP (Internet Protocol). A seconda della chiave richiesta, i percorsi cambieranno. Gli algoritmi di routing per conservare e richiamare dati descritti nelle seguenti sezioni sono progettati per aggiustare adattivamente i percorsi nel tempo per dare performance efficienti mentre si usa una conoscenza solo locale, piuttosto che globale. Questo è necessario poichè i nodi conoscono solo gli upstream e downstream delle immediate vicinanze nella catena dei proxy, per mantenere la privacy.

A ogni richiesta viene dato un limite di hops-to-live, analogo al time-to-live dell'IP, che viene diminuto ad ogni nodo per evitare le catene infinite. A ogni richiesta viene anche assegnato un identificatore casuale pseudo-unico, così che i nodi possano prevenire i loop rifiutando le richieste che hanno già visto. Quando questo accade, il nodo immediatamente precedente semplicemente sceglie un altro nodo a cui passare la richiesta. Questo processo continua fino a che la richiesta viene soddisfatta o supera il suo limite di hops-to-live. Quindi il risultato di successo o di fallimento viene ripassato indietro lungo la catena fino al nodo inviante.

Nessun nodo è privilegiato rispetto a nessun altro, quindi non esiste gerarchia o un punto centrale di errore. Unirsi alla rete è semplicemente una questione di trovare per prima cosa l'indirizzo di uno o più nodi esistenti attraverso mezzi di fuori banda, e poi iniziare a mandare messaggi.

Changed:
<
<

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).

>
>

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).

Changed:
<
<

Una transazione di Freenet inizia con un messaggio di Request.Handshake da un nodo a un altro, che specifica l'indirizzo di ritorno desiderato del nodo inviante.[*] (L'indirizzo di ritorno del mittente può essere impossibile da determinare automaticamente per il transport layer, o il mittente puo` desiderare di ricevere risposte a un indirizzo diverso da quello usato per mandare il messaggio.) Se un nodo remoto è attivo e risponde alle richieste, risponderà con una Reply.Handshake che specifica il numero di versione del protocollo che esso riesce a capire. Le handshakes vengono mantenute in memoria per qualche ora, e nelle transazioni seguenti tra gli stessi nodi durante questo tempo si potrà saltare questo passaggio.

>
>

Una transazione di Freenet inizia con un messaggio di Request.Handshake da un nodo a un altro, che specifica l'indirizzo di ritorno desiderato del nodo inviante.[*] (L'indirizzo di ritorno del mittente può essere impossibile da determinare automaticamente per il transport layer, o il mittente puoò desiderare di ricevere risposte a un indirizzo diverso da quello usato per mandare il messaggio.) Se un nodo remoto è attivo e risponde alle richieste, risponderà con una Reply.Handshake che specifica il numero di versione del protocollo che esso riesce a capire. Le handshakes vengono mantenute in memoria per qualche ora, e nelle transazioni seguenti tra gli stessi nodi durante questo tempo si potrà saltare questo passaggio.

Changed:
<
<

questo caso, Request.Continue è un risultato di fallimento che significa che non è stato possibile contattare tanti nodi quanti sono stati richiesti. Questi messaggi verranno passati come nel caso della richiesta. Entrambi i messaggi terminano la transazione e lasciano ogni risorsa che occupavano. Comunque, se l'inserzione scade senza incontrare una collisione, il nodo remoto risponderà con un Reply.Insert, indicando che l'inserzione può andare avanti. Il nodo inviante passer` la Reply.Insert e aspetterà che i suoi predecessori inviino un Send.Insert che contenga i dati. Quando riceve i dati, lo conserverà in locale e inoltrer` il flusso Send.Insert, concludendo la transazione.

>
>

questo caso, Request.Continue è un risultato di fallimento che significa che non è stato possibile contattare tanti nodi quanti sono stati richiesti. Questi messaggi verranno passati come nel caso della richiesta. Entrambi i messaggi terminano la transazione e lasciano ogni risorsa che occupavano. Comunque, se l'inserzione scade senza incontrare una collisione, il nodo remoto risponderà con un Reply.Insert, indicando che l'inserzione può andare avanti. Il nodo inviante passerà la Reply.Insert e aspetterà che i suoi predecessori inviino un Send.Insert che contenga i dati. Quando riceve i dati, lo conserverà in locale e inoltrerà il flusso Send.Insert, concludendo la transazione.


Topic ICSI . { View | Diffs | r1.3 | > | r1.2 | > | r1.1 | More }
Revision r1.2 - 22 Jan 2002 - 22:02 GMT - MarcoCalamari
Revision r1.3 - 02 Feb 2002 - 15:22 GMT - MarcoCalamari
This website is distributed under the GNU Documentation License