On Friday 07 June 2002 17:25, you wrote: > > > 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.
Faster == in fewer hops. When the network is overloaded most hops get consumed by QRs from busy nodes so more hops translates into a lower probability of success. Also HTL isn't infinite so requests that are farther along the chain should have a higher chance of not DNFing for any given starting HTL. I don't have empirical data from when the network was sort of working, but I would be quite astonished if past success as a function key didn't at least approximately predict future success. > 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. It would help by favoring well routed requests over poorly routed requests. > > 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. The thread issue is better addressed by non-blocking IO. Rejection connections at the transport level is cheap locally but expensive globally. I think you will just push the problems that we are now seeing at the application layer back down into the tranport layer, where they are harder to deal with. Don't you remember Freenet before application level rejection? > 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/ProposalPrefilterRequest > >sUnderOverload > > > > Thoughts? > > > > --gj > > > > -- > > Freesite > > (0.4) freenet:SSK@npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage// > > > > _______________________________________________ > > devl mailing list > > [EMAIL PROTECTED] > > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl ---------------------------------------- Content-Type: application/pgp-signature; charset="us-ascii"; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description: ---------------------------------------- -- Freesite (0.4) freenet:SSK@npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage// _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
