Before anyone (else) turns their contact probabilities into NaN's; change
the suggested line to have .0's
eg:
contactProbability =
(float)((contactProbability-1.0/5.0)/(4.0/5.0)*(19.0/20.0));
My appologies
Trevor
----- Original Message -----
From: "Trevor Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, May 27, 2002 1:48 PM
Subject: Re: [freenet-dev] Partial solution for overload
>
> > promoting my change for. The thing that my change does is decrease
> > the chances of a node becoming saturated with QRej's and handling 0
> > requests because of it. I'm interested to see how many connections
> > your node refuses, because that's the only effective way (at the
> > moment) for a node to get others to send it less requests.
>
> I've done some looking through the code -- looks like the last effort to
> control requests was a little agressive IMHO; I would guess that rather
than
> sending a node fewer requests; that it would give up on the node
completely.
> (Yes it ends up that the node gets fewer requests as it has fewer clients;
> but I've increased the load on the other nodes I talk to; and if they get
> overloaded I'll end up with no node references - or rather extreamly few
as
> there is a safety to not ever toast the last three by this means) -- I
> suspect that encourging a node to go into a refuse connections mode might
> have a similar effect if deployed to a large enough audiance.
>
> Might I propose a gentler means of control; being that we add the line
> contactProbability =
> (float)((contactProbability-1/5)/(4/5)*(19/20));
> into the backoffRouting method of CPAlgoData. (I choose this formula as it
> negates the successful routing that caused an increase to probability and
> then decreases the probablility with about half of the effect of a
complete
> failure)
>
> My thinking is that it means that we don't drop the node off our list
> completely; just reduce the chance of sending a request to it (hense fewer
> requests); if a node gets saturated for whatever reason into a just query
> reject mode; we backoff to sending very few requests, but once the cause
of
> the saturation is over, it is able to spring back.
>
> Unfortunately; something like this is difficult to actually test without
> deploying it out to the masses...
>
> Thoughts?
>
> Trevor
>
>
>
> _______________________________________________
> devl mailing list
> [EMAIL PROTECTED]
> http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
