Not necessarily. Maybe it's bias put in specifically to make new nodes get more hits. On the other hand, maybe we should handle that differently. Proposal:
We initialize the node estimators to something realistic, and not heavily biased. This may be from data from the seednodes or from the StoreData Source field, or we may make it up from averages etc.
We have a function E(node), which gives a rough estimate of the experience level of a node. When it is below some critical threshold, we randomly fork requests occasionally to that node, as that node won't be getting much other traffic (the established known good nodes will therefore get all requests - we don't sacrifice routing efficiency on a given request in order to test out a new node, we simply start another request occasionally). Could produce more traffic, but on the other hand the basic issue with traffic is routing effectiveness, and this might improve that and therefore thoroughly compensate for the extra traffic (which we would limit to some sane fraction)...
I think I really like this concept- primarily because it preserves the routing choices that have been grown, while still learning. But we should impose a hard upper limit on how often this is done. (1% of incoming requests may be used for this purpose?) There are definitely security concerns to the dual-request notion (what information might a downstream, common provider glean?). And it is wasteful (thus the need for hard upper limit). On the other hand, if we just "improperly" route 1% or less of our requests, will it really hurt our externally estimated specializations ? I rather doubt it. It could be good to select requests within a certain HTL range - I'll ask you, the reader, to think of reasons why!
Also give recognition (comment in code) that the cause of this special behavior is the appearance of new nodes joining the local node's RT. The permitted join rate may someday want to have a hard upper limit. The appropriate limit on join rate would be different for every node, based on its unique internet link's performance characteristics.
If dual-requests are chosen, it might help to favor requests for smaller data objects, to boost the efficiency (ie. what if the key references a huge object) ? But: this colors the information we are trying to obtain. I'm thinking about the waste of dual-downloading a huge object.
Ken
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
