> > Subject: > [freenet-dev] Builds 524 and 600 > From: > Matthew Toseland <toad at amphibian.dyndns.org> > Date: > Sat, 26 Oct 2002 00:30:35 +0100 > To: > devl at freenetproject.org > > >Trunk CVS is now build 600. Minor fix that should greatly reduce >problems with RouteNotFound; we are increasing the build number to allow >for changes to the stable version. The stable rel-0-5-0 branch is now >build 524, with the same fix. Please upgrade, especially you Debolaz. > > > > > Subject: > [freenet-dev] rc2? > From: > Matthew Toseland <toad at amphibian.dyndns.org> > Date: > Sat, 26 Oct 2002 03:46:12 +0100 > To: > devl at freenetproject.org > > >It turns out that the bug I just fixed with build 524/600 is fairly >serious. As in, it leads to constant RNFs when trying to insert, even >when using the desperation-mode-routing code I committed to the >development branch CVS. And initially RNFs when trying to fetch too. We >need a lot of nodes upgraded to 524 before 0.5.0 comes out. Thus we need >to release 0.5rc2 IMHO. The questions remaining are: >a) Do we include the desperation-mode-routing changes? This adds a >second pass in TreeRouting if the first one fails, in which it will try >backed off nodes and nodes with a low CP. >b) Do we up the minimum build, now or soon? > >It's far too late for me to be doing things this important, so I am >going to bed. But we need to deal with this tomorrow. >
I noticed quite a bit more RNFs when both requesting and inserting things. I attributed it to a sudden surge of new nodes announcing themselves and not having a clue where anything was. What makes you think that this was actually something unknown and new to be wrong in the code? Were there changes made between 522 and 523 that screwed things up? Otherwise the build 522 way of doing things seemed to work smoother if the RNFs are not traffic spike related. I have not tried build 524/600 yet. Does a node that is rejecting a request know anything about the request that it is rejecting (i.e. does it search its local store before deciding it is too busy to forward it on or does it just reject any incoming connections outright)? I know that there was a lot of talk about using HTL as a desision making mechanism for biasing the choice to cache data or to reset the datasource or not. Perhaps a more valuable use would be to have a little bit softer edge on the desision to queryreject or not. If a request comes in with an HTL below some dynamic threshold based on the average HTLs of the other queries in the queue, then it is considered desperate and is handled. This has the double benefit of virtually eliminating RNFs and encouraging using low HTLs (naturally discouraging high HTLs rather then having a hard cap on the max HTL) Just a thought, Mike _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
