Hi, I had something along the lines described below - then ran out of time...
What I did was track what requests we were answering either with data or a DNF reject. I used this data to increase the probability that the node would respond to requests (histogram keyspace wise) that it was able to answer previously. I did find my node specializing when doing this. I also tracked the number of requests that got lost. ie my node did not respond at all (it got an exception...). Typically 2-4% of requests were falling into this hole. How does fn respond when requests are just lost??? Ed Tomlinson On June 7, 2002 06:49 pm, Gianni Johansson wrote: > 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/ProposalPrefilterReque > > >st 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: > ---------------------------------------- _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
