On Wed, 12 Apr 2000, Brandon wrote:
>
> > You'll notice that for an online node, most of the time connections
> will
> > succeed, so a constant factor might want to be a little lower than
> > 0.1. Doubling the factor each time might be a bad idea, since a
> possibly
> > unreliable node could become 'reliable' too quickly. A server
> should have
> > to 'prove its love' before being respected as reliable again.
>
> In our particular case, however, most unreliable nodes are probably
> unreliable because they are switching IPs, or, at least, they will
> probably switch IPs if they crash. Modems, cable modems, and ADSL all
> use
> DHCP and so switch IPs on reboot/disconnect, oftentimes.
>
> So in this case the reliability formula should be one such that nodes
> which are around a lot are always on top, but nodes which reappear
> jump
> quickly back up to pretty high, but still under truly reliable nodes
> and
> nodes which have been dead for a while get deleted fairly quickly. I
> think
> the way to solve this is to have two classes, very reliable and
> somewhat
> reliable. It takes a lot to move from one class to another. So a very
> reliable node can go for days without being downgraded to a somewhat
> reliable node, but a somewhat reliable node will be deleted after a
> day of
> down time. On the other hand, a somewhat reliable node will have to
> have a
> marathon of uptime to become a very reliable node.
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.
>
> Of course, we are entirely ignoring closeness. The algorithm for
> choosing
> nodes needs to taken into account both closeness and reliability for
> them
> both to have meaning. A simple multiplication of the two values might
> be
> good enough, with a constant weighing the outcome towards one value
> or the
> other.
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.
-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
