Gianni Johansson <[EMAIL PROTECTED]> wrote: > > You can get the "rake the entire routing table" behavior back by setting > maxRoutingSteps = 100 > > That should give you behavior as good (as bad?) as before 467. > > Maybe the right thing to do is to implement a separate, higher > clientMaxRoutingSteps for local client requests, at least temporarily. > > PRO: > -Intra-node requests from still get routed with the shorter maxRoutingSteps, > which helps specialization, we hope. > -Client apps (frost, fproxy, fmb) get less RNF's like pre 467, we hope > - We might be able to avoid doing a mandatory upgrade if enough people > migrate to 468+ builds because its in their best interest to do so. > > CON: > - Evil or clueless people can more easily flood the network by running overly > aggressive client apps (like pre 467). > > Truly evil people will just hack up the source anyway....
Hi, Gianni :-) Of course, I only hacked up FMB so it didn't keep trying to insert data with 20 HTL (ouch... inserts almost never completed, even with maxRt...Steps=40) With only 40 or so nodes in my routing table, doesn't 20 HTL try to insert to at least half of them? Haven't attempted to touch Freenet node code. I think my node's running at 45 maxRoutingSteps, and specializes quite well now. Build 468. Number of keys: 240 (yeah, it used to be 3000 (with no real peaks), but I had to reset the datastore in order to get 468 to route things again. I may restore the datastore from backups some time, so my old inserts (which apparently didn't get off the node) might be available again) peaks in datastore table(count/mean) 1 --> (0.8) 5 --> (2.2) 8 --> (2.9333334) c --> (1.5333333) e --> (1.3333334) peaks in request table(count/mean): 1 --> (1.1052072) 5 --> (1.4821112) 8 --> (3.5678356) e --> (1.5586256) Reqs per hour: 409, down from an average of 2000 3 days ago. Note that peaks in request and datastore histograms sort of match. This is a good thing, I think. Is restoring a datastore a bad thing? Yes, and no, I think. Yes, in that data becomes available again. Bad, in that the routing table is thrown back to the old state. I have no idea which is worse for freenet, though I do know that data going missing is a known problem with freenet (well, _I_ know about it). Is there some way of reseting only the routing table? Would this help other nodes, or hurt? -- G _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
