> It is better to route data though other nodes even when there is a more > direct path between two nodes?
Sometimes, yes; it's entirely workload-dependent because you can't predict where the next access will come from. It's also important to remember that "more direct" can mean different things in the overlay network (such as Freenet) and the underlying physical network. Just yesterday, there was an article posted on Slashdot whose author had obviously forgotten that the two might not be congruent, and the whole proposal pretty much falls down once that is realized. > In particular do you think that this > strategy is flawed: > > I also believe that by simply transferring data from one node to another > a lot of the benefits of freenet's caching algorithm can be retained. > Because, once node A transfers a key from node B nodes close to A (say > B,C,D) can transfer data from node A instead of having to download it > from node S which is farther away. What you're suggesting is merely a subset of what Freenet already does - i.e. the final recipient caches the data rather than all recipients in the path. Why is it better for one to cache than for all to cache? > The more > nodes that download the data the less chance there is that *all* off > them will be inaccessible to other nodes. What you should be saying is "the more nodes that *have* the data...". Why limit it to nodes that initiated new requests for the data? > However, if for some reason nodes A,B,C,D and completely inaccessible to > other nodes, node S will notice that it is getting a large number of > requested from far away and will upload the data to some other nodes > which are closer to the origin of the requests. I think you'll find that the algorithms by which S "notices" these request patterns either require huge amounts of memory and computation or don't work very well...or both. Ditto for the algorithms for deciding where to "upload" the data (a.k.a. replica placement). As I said, a lot of smart people have worked on these problems, but it's remarkably difficult to come up with anything better than sheer opportunistic caching like Freenet does. _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
