Oskar Sandberg wrote: > > How do we want the discouraging of nodes that don't reply to work? Should we > simply remove the the reference in question (which doesn't mean removing all > references to that node, only one at a time) or should we include some sort of > extra blacklisting system where nodes that have bad uptimes are avoided by > some > probability, or is it time we did a complete redesign of how the node chooses > nodes to forward to so that, together with closeness, it also considers the > reliability, locality, and speed of the other node. > > Can we decide this now?
We could implement this in stages, as all of these changes will be backward compatible with the current system. Initially I would suggest that when a connection to a node fails, all references to that node are replaced with the address of the node corresponding to the closest key to the key associated with the failed node. This may seem harsh, but duff nodes are so frequent now that I think we should have a zero-tolerance policy. I think that we can then start to think about how we can incorporate a bias towards sending messages to closer nodes / nodes with lower ping-time - the strength of this bias should be configurable. We could even measure speed of connections to particular nodes on-the-fly as we retrieve data from, or send data to, those nodes. Perhaps a hashtable mapping node addresses to data through-put rates, although we shouldn't forget to remove data about nodes we no-longer reference. Nodes we don't know anything about should be assumed to have an average through-put. As for reliability, that is not an issue with a one-strike-your-out policy, and I think locality is probably irrelevant provided we are measuring throughput. Ian. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
