> 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
