> Keep statistics on successful requests by search key. Use them > to approximate the probability of successfully answering a > request (i.e. finding the requested data)
I am not sure how you could do this. Failure to find key "aaaaab" does not indicate that you aren't going to find "aaaaac" either, since (from a key-naming point of view) data drops out of the network randomly. The only correlation should be that the closer the sought key is to the closest key in your datastore, the faster you get an affirmative response. I am not sure that it would be good for the network for nodes at the start of request chains to be more likely to reject a requests than nodes near the end of a request chain - at least, I am not sure how it would help. I think that the core problem is that threads are being wasted, when a node is overloaded, telling other nodes that the node is overloaded - making the problem worse. This is obvious when one hears stories of nodes rejecting tens of thousands of connections per-day, but only responding to 10 or 15. When a node is overloaded, it should reject connections from any node that it is not expecting a reply from. Rejecting a connection is the right way to do it, because it is the cheapest way to do it. Ian. On Fri, Jun 07, 2002 at 04:47:17PM -0400, Gianni Johansson wrote: > >http://freenetproject.org/cgi-bin/twiki/view/Pub/ProposalPrefilterRequestsUnderOverload > > Thoughts? > > --gj > > -- > Freesite > (0.4) freenet:SSK@npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage// > > _______________________________________________ > devl mailing list > [EMAIL PROTECTED] > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl -- Ian Clarke [EMAIL PROTECTED] Founder & Coordinator, The Freenet Project http://freenetproject.org/ Chief Technology Officer, Uprizer Inc. http://www.uprizer.com/ Personal Homepage http://locut.us/
msg03229/pgp00000.pgp
Description: PGP signature
