On Thu, Apr 20, 2000 at 01:22:05PM -0700, hal at finney.org wrote: > > This does seem to be a good model. But consider an ant inserting a new > data item into the net using this same key. It creates a sugar trail and > goes HTL hops into it, probably merging with some other trail at some > point. > > Now consider a request for that same key. Suppose it traverses the full > HTL hops and gathers all the instances of data under that key from all > the nodes in that HTL-long path. > > Will it find the new data? I say it will, if Freenet works. Here is why: > > Consider inserting new data that is not actually the same key, but a very, > very similar key. So it follows the same closeness algorithm and takes > the same path. Then consider a request for that same key. It will be > found, by the assumption that Freenet works. But the insert and request > use the same routing as the insert and request for the original key we > were considering. Therefore the new data inserted under the same key > will be found by a request for that key, if the request routes for the > full HTL. QED. > > This means that each new data inserted leaves a path which gets crossed > by each data request for that key (at least, for almost all of them). > Therefore if we consider each route extending for the full HTL (as does > happen on inserts, and as would have to happen on requests which will > return all matches), almost all such inserts and requests for a given > key will meet. And once met, they will follow to the same point. > > While you are right that requests and inserts will spread the data in > different directions, this argument seems to show that the different > trails will in fact converge. > > Hal >
If I understand this, the endpoints are only going to be the same if the nodes are the same number of hops away from that endpoint, and use the same HTL on inserts and requests. (or is the same node). This would be true for any keys that are close in 'keyspace'. So, the question becomes what happens when the distribution of the keys are compressed, which also opens up the question of what does the distribution of the output of SHA look like. (later). I still can't get the image out of my head that the result is going to look like a blob, an amoeba with shifting boundaries, extending pseudopods at random. Popular data that is further away from other popular data in keyspace will form large, slowly expanding blobs. Popular data that is closer to other popular data in keyspace will form smaller blobs, but more of them. This is why I was thinking that it might actually be harder to route a request successfully (need more hops) when lots of popular keys that are close in keyspace are used. The answer to this when you're inserting on a common key might be to 'turn' when you get a match on the common part of the key, or get too close in keyspace. (kind of like an incest taboo). Am I understanding your argument? David Schutt _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
