> > > From: > Matthew Toseland <toad at amphibian.dyndns.org> > Date: > Sat, 15 Mar 2003 19:11:26 +0000 > > >Hmm. It is possible that your node is suffering from the increased >aggressiveness of the ARK resolution code; I changed it from 20 >consecutive failures to trigger a lookup to 10... is it a very slow, or >very busy node, or one with a very large rtMaxNodes? >
As a matter of fact, I am running non-default rtMaxRefs=20 and rtMaxNodes=200 in an attempt to have my node learn a little bit about a lot of nodes rather then letting an ubernode dominate my routing table (as could happen with the 50/50 settings that are default now). Looking at my routing table now that change could be the reason. My node is trying to look up 44 ARKs currently. Trying to retrieve my own ARK is unsuccessful (likely since I haven't changed IPs in quite some time). I have switched back to an old build 678 and while I can now get fproxy showing up it is still much busier then normal. Once the ARK lookup process is triggered for a node IP will it continue to try getting it through a node restart? Are you limiting the resources used to grab ARKs? What is the failure mode if a node just isn't there anymore rather then moved to a different address? A "maximum percentage of threads to use for ARK lookups" setting might be necessary. /Mike _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
