So, there seems to be a mistaken assumption out there that some nodes
get to have more references in your data store because they are
"ubernodes" and have high bandwidth and data storage. This may
actually be something of a possibility, BUT there's a much more
important reason why one or two nodes shows up as having the vast
majority of references in your data store. It has to do with how
Freenet does routing and it's perfectly natural and harmless.
The way Freenet routing works is essentially this: every key that a
Freenet node knows about is stored internally into a big honking
number. That number is associated with an address for another
node. When you ask Freenet for a key (like "[EMAIL PROTECTED]"), it converts
it into a number, and then finds the closest number it already has
stored to that number. It then asks the node at the address mapped to
the stored number for the new key.
Consider this simple example. I'll use numbers 1-100 for keys and
letters A, B, and C for node addresses. Let's say that we start off
with only 3 keys in the node, perfectly spaced apart, like this:
16 50 83
|-----|----------|----------|-----|
A B C
Now, let's say that we ask the node for a key that converts to, say,
31 on our little chart. Because the closest value to 31 that we
already have is 16, the node contacts node A and asks for the data for
31. If it comes back, we cache it, and now we've got the following
data store:
16 31 50 83
|-----|----|-----|----------|-----|
A A B C
Now, suppose we ask for key that converts to 40. Before, it would have
been closest to the key at 50 (mapped to B), but now it's closer to
the key at 31, mapped to A. So we ask A for it, and get the data, and
now our node looks like this:
16 31 40 50 83
|-----|----|--|--|----------|-----|
A A A B C
Looking at this closely, we can see that, as of right now, any request
that comes in for a value less than 45 will be mapped to A. That's
almost half of all keys! Note that we said nothing about the
reliability of the nodes, how fast they respond, how much data they
actually have (or can get). It's just a property of simple math and
linear "closeness" that makes have more items in the node. A very well
might be _less_ connected, big, and fast than B or C, but it's having
more "success" and appears to be "hogging up" the entire network (from
our little node's point of view).
There's a few things that actually will balance this out. First of
all, let's say that we've just received simultaneous requests for
items at 4, 21, and 34, all of which get forwarded to node A. However,
node A has finite resources. If it can't accept the request for 21
(for example), we need to send that request to the next closest
node. Even though there are items at 31 and 40, we skip those and go
to the next item with a different node address, at 50. So we ask B for
21, and it returns it, and now we have a node that looks like this:
16 21 31 40 50 83
|-----|--|--|--|--|----------|-----|
A B A A B C
Now, a request that came in for 19 or 24, which would have gotten
forwarded to A previously, will be forwarded to B instead. So we get
more refs to B in our data store.
Another thing is that sometimes when we request data, the upstream
node will return an address to associate with that data. So, let's say
that our request for 4 comes back with a new address, D, attached:
4 16 21 31 40 50 83
|--|--|--|--|--|--|----------|-----|
D A B A A B C
Now, anything less than 10, which would have before been sent to A
before, will be sent to D instead.
Finally, if you restart your node each day, you'll get a fresh pack of
new addresses from inform.php, pretty much randomly spread across the
address space. So, if we restarted our node above, we might get the
following:
4 16 21 31 35 40 50 63 83
|--|--|--|--|--|--|--|----|-----|-----|
D A B A E A B F C
The new node addresses, E and F, will receive new routed messages.
So, the upshot is this: having a ton of refs to a particular node in
your data store is a natural thing. Freenet nodes are like fine wine:
they improve with age. As long as you make sure to:
1) Restart your node each day to get more addresses
2) Request a lot of stuff
3) Try to keep other "healthy" nodes in your nodes.config
You shouldn't have a problem with "ubernode syndrome."
~Mr. Bad
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mr. Bad <[EMAIL PROTECTED]> | Pigdog Journal | http://pigdog.org/
"Your description of coffee is how you interpret Sex."
-- "Personality Quiz" chain letter
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Chat mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/chat
