> FROM: Scott G. Miller > DATE: 04/20/2000 08:34:07 > SUBJECT: RE: [Freenet-dev] Proposal for the Near Future > (Searching, CHKs and > > Hal says, > > Furthermore, the routing algorithm is the same for inserts as > for > > requests, so overlaps occur for inserts as well. If someone > inserts under > > key "mp3" it goes onto 5-10 nodes. Assuming we allow multiple > docs per > > key, every such insert will overlap with each other on at > least one of > > those 5-10 nodes. (And once the two paths cross they will > probably join > > and stay together for the remainder of the HTL.) Therefore > there will > > be nodes which will have at least 1/5 to 1/10 of all "mp3" > keys stored > > in Freenet.
You are right here when you are talking about a network where each node knows about every other node (or at least is "near" every other node). However, I see this as being less and less true as freenet grows up. Like a said before, as each node references less of a proportion of the freenet, the more diversly this information will be spread. Sure, there will be popular keyword streams but they will be somewhat local. Also, the data requests will get satisifed early in the nodes that have overlapping insert streams so the request load will pool in a ring around the *the best* IP match for a keyword hash. > Yep.. Thats my concern as well. And it follows from the way > freenet > operates. You may have 5-10 hops, but those hops are designed > to traverse > as much of freenet as possible since each server makes its `best > guess` as > to which server has the data. We don`t want data clustered. > This is why > storing by CHK is appealing to me. Ummm... storing and routing are two completely different things to me. Currently both things are done by the KHK but in the future this is likely to change. As has been stated by many people in the past, the ideal future development will bring both concepts (KHKs and CHKs) in where they are most appropriate since each have their benefits. > The hash of any two documents is > likely to be wildly different, even if they themselves differ by > only a > single bit. Inserting your data under a random number hashed up will also distribute your data nicely (even if the data is exactly the same) however this does nothing to help searching for it (just like routing via CHKs). > Thus like files will be scattered over the network so there > is no one point of failure. > Nor will any one find them unless there are references inserted under some guessable, indexable or searchable key strategy. Distribution of files is at issue ... it is the finding them later that we need some method for. And I have yet to hear a solid argument against hashed keywords that cannot be simply (and, from my estimates, sucessfully) circumvented. Am I out to lunch on this or am I making any sense to people? Mike _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
