On Wed, Apr 18, 2001 at 03:24:27PM +0200, Oskar Sandberg wrote:
> I mean, if you are going to assign one single node a task of taking care
> of the list - then why do you want to go through Freenet at all
Let me see, um, anonymity? As long as public keys are evenly distributed
over the keyspace, publicly writable lists will be evenly distributed over
the nodes. It's not like one single node is going to be handling all the
mail on Freenet.
> (for the hundreth time: Freenet does not work by routing requests to
> the data, it works by moving the data to where the requests are)?
Then why aren't requests routed randomly? Because Freenet *does* work in
part by routing requests to data.
Look at it this way:
For a given key k, Freenet forms a weighted directed graph where each
vertex is a Freenet node and an edge from a to b is a reference in a's
routing table pointing to b, with a weight equal to the distance between
k and the reference's key.
To find k, we start at our own node and follow the edge with the lowest
weight until we find a copy of k. We never follow an edge that leads to
a node we've already visited. If there are no suitable edges, we backtrack
to the last node we visited. This is an example of routing requests
towards data.
When we find k we travel back along the visited edges. For each node n
that we backtrack through, we add an edge from n to the previous node we
backtracked through with weight 0, and we give n a copy of k. This is an
example of copying data towards requests.
Now we want to find a key k' that's very close to k. The graph for k' is
derived from the same routing tables as the graph for k, so the path to
the node that supplied us with k has very low weights in the graph for k'.
We follow that path first. This is an example of routing requests towards
data.
When we find k', we leave copies of it on the same nodes where we left
copies of k. This is an example of copying data towards requests. Etc.
We assume (although I don't think anyone's proved it) that over time this
combination of routing and caching will cause the network to
self-organise, so that a reference for k will tend to be a good reference
for k' as well. That means that a reference for k that was created by my
search for k might help another user, starting from another point in the
network, to find k' (or k'').
The network is organised to the extent that another user and I "agree"
on where to look for a key - we agree if our routes converge at some
point. If self-organisation works perfectly, any given user will agree
with me on where to look for any given key. Even if it works less than
perfectly, we will agree for some keys.
This means that if I insert a key on a single node (as in the case of a
publicly writable list), another user's chance of finding the key will
depend on the network's degree of organisation. Using a handful of lists,
I should be able to receive submissions to *at least one* of my lists from
any user. In other words, every user should agree with me on where to look
for at least one of my lists. If the network were perfectly organised, I
would only need one list (although I would still use at least two to
protect my mail from malicious nodes).
Michael
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
