On Wednesday 22 October 2003 06:54, Toad wrote: > On Wed, Oct 22, 2003 at 12:41:46PM +0100, Simon Porter wrote: > > I see five possible ways to solve the problem: > > > > 1) Everyone stops using Frost - obvious, but unlikely and wouldn't really > > solve the problem (weakness in Freenet), just cut the symptoms. > > > > 2) Radical changes in how Frost operates - again unlikely, and again > > wouldn't solve the problem. > > Could be assisted by Freenet in this. Nearer or after 1.0, there are > some protocol changes I have been keen on for a while that would make > Frost have less impact. > > > 3) Increase other traffick - if the majority of requests in the network > > are for existing keys, the disturbance caused by Frost will be smaller > > (the "good" information will drown it out). The freesites might be such > > an application since a link going nowhere is most likley an error from > > the makers part. Unfortunately, the freesites aren't really in a usable > > condition currently. Furthermore, since edition sites usually contain a > > link and an activelink image to a future edition, and since that edition > > isn't inserted yet, they also procude some nonlegitimate routing info. > > And again, wouldn't solve the real problem. > > Well, there are problems with FCP, but I have been concentrating on RNFs > and the lack of routing success recently. > > > 4) Drop pDNF from NGRouting calculations - would solve the problem, for > > Frost and any other application which might cause this. Might make > > NGRouting less effective. I recommend trying this and seeing how it > > affects the situation - the effect should be instantenous, and it can > > allways be added back with little hassle. > > Yuck. You might as well go back to traditional routing if you do this. > The whole point of NGRouting is to determine an expected time for > success, including any retries (using a global success-only estimator), > given that you route to any given node, and then choose the best one. > > > 5) Increase the size and time to last of failure tables a lot - this > > would cause failed traffick to be stopped on it's tracks, lessening it's > > effect on routing. Unfortunately, it would hinder Frost considerably, > > since a key that's failed now doesn't neccessarily stay failed for very > > long (someone might be inserting a new message this very minute...). It > > would also hinder other messaging system type programs. > > Maybe. But it may be useful nonetheless. We could perhaps reduce the > time to last a bit and increase the table size a lot... > > > The point number 4 should be the easiest to test, since any changes to > > the local node should get immediate results. Could someone out there > > please test this (I can't code Java well, and couldn't even figure out > > where the routing calculations are made, much less how to change the > > formulas :( ) ? > > I could, but I think you are wrong. > > > If you think I'm wrong, please explain why.
These are all partial solutions. The real way to fix this is to make it so that we don't need to use KSKs or try to guess keys in the first place. That means implamenting TUKs. If we have TUKs there should be no reason to use guessable keys at all. I would say given how big a role Frost and edition sites play in Freenet, that TUKs should be a fairly high priority. However lots of other things are too. (Bugs, finishing debugging NGrouting, more NIO, session v2, Firewall hopping, cancer node resistance, getting things working with GCJ now that it does NIO.) Maybe it's time that Freenet get a second full time developer. (Assuming the project can raise that kind of money) _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
