Martin Stone Davis wrote:
We need to reduce the number of queries coming from nodes which don't
use QR-backoff. A few ways to do this are:
1. Keep track of each node and punish those who don't back off.
Now I'm sorry I ever used the word punish! It implies countering an
intentionally bad (malice) behavior . Perhaps it would be better in
this context to substitute 'block' for punish. I agree with you Martin,
that "we need to reduce the number of [uncontrollable] queries..." ,
for the *sole purpose* of load-balancing. If it is beneficial to the
network in any other manner, then so be it... This is an _active_ ,
versus _passive_ ("i sure Hope they back off"), solution. The cost
of implementation will purchase a guarantee that this will NOT be a
problem, now or in the future . I would be glad to assist Toad in the
coding of this! Or do it myself, but I would need some (day or three)
learning/ramp-up time. Perhaps while the currently excessive backoff
problem is solved, and integrated, into the network for evaluation ?
Call this an optional upgrade, that people would evaluate, vote on,
and then the project would commit or trash as necessary. I am firmly
behind this solution, and most willing to demonstrate my commitment.
It is compatible with requestor backoff as well. So please let your
representative know,if you support this effort; Oh wait, that's YOU!
* PRO: Would protect us from evil nodes who pretend to be upgraded but
don't back off. (The following two ways would not.)
<strong words>
I believe this is *at least as* important for effective load-balancing,
as it is for countering malicious behaviour within the network. We seem
to be discovering that when ONE node beats another node over the head
with too many requests, in too short of a time period, that this is Bad.
Then again, some people may never be convinced of this. In which case
I would like to redress them with an aggressive clubbing (of queries),
causing them to become unbalanced :)
</strong words>
2. Increase lastGoodBuild.
* PRO: Very simple to implement.
* CON: Ian says that users in China hate it when we do that. I guess
because they have trouble obtaining an upgrade.
Didn't Ian recently say that Chinese users operate a completely separate
freenet network of nodes, possibly using 0.4 ? The protocol version
(1.xx vs 1.47) alone should be a sufficient obstacle for them, no ?
"Sometimes it is necessary to break something really badly before you
can fix it" --(mine) so i guess we are halfway there!
3. Before sending a QR, check the version of the requestor. Then, if
it's a version w/o QR backoff, simply drop request. That way, we would
stall them, their tSearchFailure would go up, and NGR would encourage
them to try another node. (Of course, if we can handle the request,
handle it regardless of the version.)
I think this is an elegant and easy approach for now. A little too easy.
I'd rather do things "right" the first time, even if I have to do it
myself... but for all practical purposes, I concede this would solve the
immediate problem.
<sarcasm>
Plus, if this weakness is abused sparingly in the future (in the form
of greedy or malicious behavior), it will remain unnoticed for a nice
long time! And then it will cost the project a fair amount of time to
be properly identified, and then addressed !! so I'm laying the roadmap
for that "super hacked extra cheaty version of fred" that will come out
*after* Freenet achieves internet domination :)
</sarcasm>
well that's my 8 cents ,
ken
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
