On Tue, Aug 22, 2000 at 12:38:26PM +0200, Neil Barsema wrote: <> > No, it is not about storing data in more places I can imagine using an > unrequest feature to stop the losing path from actually caching the data > (or a commit to the winnig path) although I'm not sure its worth it. > Its not that the data gets stored in more locations just in better locations > and the fact that a particular route can deliver it quicker proves to me > that > it is better you are right its not about weighing the connection its about > weighing > the total performance of a given node/route. > It is at least as good as the current aproach since it uses the same > criteria to select the nodes.
The problem is that if no reference are being set to you, then having the data is actually not worth that much. The relation between Charles getting the data and Charles footprint on Freenet growing (unless he reset the DataSource to himself) is only a two step relation - next time he'll get a request for that data, if there is a next time before he looses it, he has it and will get DataSources for it. I ran a test with Serapis where I only had the node put the data in the datastore on the nodes where where it reset the DataSource to point at themselves. I was reseting every 10th hop, so I was only adding on 1/10 nodes, yet the success rate for 10 htl request was only 20-25% less. And that was on network that wasn't saturated with data, so all the nodes had plenty of extra room. > > Obviously you would have it so that if two branches reached the same node > > one after the other the latter would simply be dropped, since it can't > > possibly win the race (unless you are doing the forking just to put data > > in more places which is silly and dumb). Trying to bounce the later fork > > back would be ridiculous since it would it's "forced" route of being > > pushed off where it naturally wants to go (because the faster fork got > > there first) would keep trying to converge with the natural route (doing > > no good and causing lots of work for the nodes). > > > I don't think it is that obvious that the slower branch can not win the race > but you're probably right. > If a quickest branch gets stuck in some local maximum the slower one could > end up finding the data > sooner but I'm not sure this is desirable behaviour. If your afraid of gravitating toward a "local maximum" (I'm not even convinced those exist) then you have to step off it by moving far away from it - having a message that bounces isn't enough (After all, if even the "maximum" will send the message somewhere, and if that somewhere goes back to "maximum" you have the same sort of bounce that the later fork would experience right there). -- \oskar _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
