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
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
