On Wed, 12 Apr 2000, Brandon wrote:
> Date: Wed, 12 Apr 2000 03:42:10 -0500 (CDT)
> To: freenet-dev at lists.sourceforge.net
> From: Brandon <blanu at uts.cc.utexas.edu>
> Reply-To: freenet-dev at lists.sourceforge.net
> Subject: Re: [Freenet-dev] Re: Node lifetime
>
>
> > I don't see how having two classes helps. If we want to make it
> > more difficult to move up the reliability list, we should reduce
> > the bonus a node gets for answering a query. Each node can decide
> > that on it's own, and also decide how many neighbors (or the
> > minimum score of a neighbor) it wants to keep track of, depending
> > on traffic and resources on that node.
>
> Two classes helps because there are two kinds of nodes in reality, nodes
> which go down and come back up (static ip) and nodes which go down and
> never come back up (dynamic ip). This isn't a disjoint set. Some nodes
> with static ips might decide to stop running a freenet node and some
> nodes
> with dynamic ips might recover from a failure, an unplugged ethernet
> cable
> or somesuch. However, things in the first set will behave largely a
> certain way and things in the second set will behave largely a different
> way.
My argument is that these two groups will segregate themselves naturally,
given the right parameters to the reliability equation. Example:
I have four neighbor nodes. Neighbor A has a reliable, static IP, and
has > 95% uptime and for our purposes *always* replys to requests. B has
a static IP on a noisy or low-bandwidth line. 20% of our requests to
B timeout or are refused. C has a static IP but isn't always available
-- it's a home computer that gets turned off at night, for example.
C is a dialup or other dynamically assigned IP.
A will always have a reliability of 100%. We will always forward
requests to A.
B will have a reliability of 100% until the first time we timeout, at
which point our first lost request will drop it down to 50%. Assuming
we give a 5% bonus for responding, B's reliability will range between
~15% and ~35% over time.
C will have a reliability of 100% until it gets turned off at night,
then it's reliability will drop to some small number. If we assume five
requests every hour (before reliability scoring), C's reliability
will drop to ~2% before it's turned back on after eight hours. During
the day, it will climb back up to ~10%, and drop to ~2% that night.
D will start with 100% reliability until it gets disconnected. It will
take about three hours to drop to 6% reliability, another 3 to drop
to 3%, etc. In short, for the first few hours, it's behaving like C.
After that, unless it manages to connect with the same IP, it's
reliability will continue to drop.
For this set of numbers (drop by half on failure, +=0.05 on success), there
is a large gap between "absolutely reliable" (A) and "mostly reliable" (B),
and a smaller (but still present) gap between "mostly reliable" and
"unreliable" (C,D). By playing with these parameters, and taking the
amount
of traffic into account, we can get the numbers we want for different node
behaviors. In this situation we probably want the following ratings:
A 100%
B 80%
C 0% (off) thru 100% (on)
D 0%
and using the right parameters (and the right equations), we can get very
close (except possibly in the case of C).
>
> > How bout this: in addition to getting a bonus for replying, a
> > node gets a second bonus if it returns a match for the key. This
> > totally gets rid of the idea of "closeness", but I think that
> > closeness will become obsolete as we start using hashed keys and
> > encrypted data, anyway.
>
> We're using hashed keys right now. Closenss is fundamental to freenet
> routing.
Hmmm...perhaps I don't fully understand closeness, then. If the keys
we're comparing are basically random strings, what are the benefits of
closeness over random routing?
-mike
-mike
>
>
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--
"Modern electronic-rock music, inaugurated in the early 1960s, is, and
always has been, a joint enterprise of British military intelligence
and Satanic cults."
-- "The Satanic Roots of Rock"
http://www.av1611.org/othpubls/roots.html
GnuPG key available at http://devel.duluoz.net/pubkey.asc
Key ID = 1024D/9A256AE5 1999-11-13 Mike Glover <mpg4 at duluoz.net>
Key fingerprint = EF6E 8BCB 4810 E98C F0FD 4596 367A 32B7 9A25 6AE5
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
