This may well help the performance of the network but publicity isn't always that easy to predict. I don't think the developers should be wasting their time releasing customised versions of Fred every single time freenet sees a bit of publicity. I would much rather see their time improving other things in Fred which will help performance in the long run.
Simon > Date: Mon, 25 Nov 2002 03:18:11 -0800 > From: Ben Hannigan <drduck at usa.net> > To: devl at freenetproject.org > Subject: Re: [freenet-dev] Getting rid of transient and ipaddress settings > Reply-To: devl at freenetproject.org > > A proposal for how to deal with a publicity based onslaught, and an > increased maxHTL: > > Note I'll use the current proposed increase to 35 HTL for example, and the > build > numbers I'm using are also just examples. > > 1) Prior to publicity, increase the maxHTL to 35. > 2) Make it well known on devl, and support lists that the maxHTL has been > raised and > that it's at 35; encourage node operators to increase their setting. > 3) For the build (call it build 550) that will exist when the publicity > hits, reduce > the maxHTL to, say 25, also set the minimum build number to the build > (build 549) > just prior to this one. > 4) For the following, say one week (builds 550-557), don't make any > changes to > builds, except show-stoppers, increasing the build number, and > incrementally > increasing the maxHTL, till it's back up to 35. > 5) At this point (build 558) make it well known that the maxHTL setting > should be set > to 35. > > This should make the batch of new un-specialized nodes which join the > network less > tenacious, and slowly bring them up to speed, as they learn the network. > > Is there a possibility of setting a minimum preferred build number along > with minimum > required? > If so, then because of step 4-5, you could set this so that builds 550-557 > all > "prefer" build, 558. My thought was to make routing to a "preferred" > build more > likely than to a non-preferred build. i.e. if the preferred build > increase is, say, > 0.1, and if for some key the likelihood of routing to node A (build 555) > is 0.60, and > the likelihood of routing to node B (build 558, preferred) is 0.55, then > the request > would actually get routed to node B first. I should point out that I only > understand > how routing works at a fairly conceptual level, so this idea needs to be > adjusted for > the realities of the implementation, but it seems IMHO to be a good basis > for dealing > with situations where you have a reasonably predictable milestone > situation. > Also, this "preferred" idea could be implemented in a more generic manner: > the > "preferred" adjustment could be calculated something like: > ( [the potential contacted node's build] - [my node's build] ) * > [some > constant, say 0.01?] = [routing likelihood adjustment] _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
