On Mon, 18 Feb 2002, Jeff Darcy wrote: > > You don't consider having to route data though other nodes all the time a > > slowdown? > > There might be a latency cost for the *first node* to request data along a > path, but that's far outweighed by the latency savings when *every > subsequent requester* can get it from nearby rather than far away. If you > increase the first node's latency by 20%, and then save 50% for each of the > next nine, your overall average latency drops by more than 40%. This effect > persists even for fairly modest cache hit rates. > > There might be a lot of ways that you'd want to change away from the way > Freenet has done things, but the caching strategy is probably not one of > them. A very large number of very intelligent people have done a lot of > work trying to find better methods, but you'd be hard pressed to find any > for which there's an efficiency gain to balance the additional complexity.
It is better to route data though other nodes even when there is a more direct path between two nodes? 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. If node A is inaccessible to node B,C,D for some reason this scheme will still work because once node B downloads the data nodes C and D can transfer it from node B. The more nodes that download the data the less chance there is that *all* off them will be inaccessible to other nodes. 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. --- http://kevin.atkinson.dhs.org _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
