(I'm crossposting this into the p2p-hackers list, since it isn't freenet-dev stuff.)
On Tue, 27 Feb 2001, Theodore Hong wrote: > Oskar Sandberg <md98-osa at nada.kth.se> wrote: > > I didn't think the Oceanstore paper was very interesting. Like you say, > > the naming scheme is like ours (and that is pretty much the obvious way > > of doing it). The interesting part is the paper they reference for their > > global routing system (which I first thought was just a hypercube mesh, > > but which is actually a lot more complicated): > > > > http://www.cs.utexas.edu/users/plaxton/ps/1999/tocs.ps > > yeah, what you told me at the conference didn't sound that great, but it is > more sophisticated -- from what I gather, the network is covered by a large > number of overlapping trees. Each tree, which corresponds to some object > GUID, covers all the nodes, but with different orderings. To find an > object, you traverse the appropriate tree upwards to its root, and then > downwards to the location of the object. Along the way, however, if you > encounter a downwards reference to the location of the object, go straight > there. Thus the root can be corrupt, but it doesn't matter -- the > important thing is that requests will converge towards the root and > hopefully intersect a storage reference. Actually, it doesn't seem that > dissimilar to Freenet, if you substitute "epicenter" for "root". I need to > go actually read the Plaxton paper, though, since they didn't lay out that > many details. Upon further thought, the actual protocol is not very different from what I told you. It is basically a hypercube type search, though they modify it to allow for arbitrary dimmensions (not hard) and the ability to decrease the number of hops by increasing the size of the table at every node (I don't know how to describe that geometrically). The further complication, that of going downward in the tree once the root for an object is found is there, as far as I can tell, to satisfy their objective of minizing a certain cost function in the final transfer - something that we do not deal with. I'm not sure that their model is so fault tolerant to the roots of objects falling out at all. And to the extent that it is, it has the problem that it is easy to identify the level of "rootiness" of any node for a piece of data - making targetted attacks easy. Also, for Oceanstores big words about mobility of data, this offers little or no such thing as far as I can tell (which the Oceanstore people get around by adding the second Bloom filter level, but large parts of the web are being served by Bloom filter using Squid caches already - that hardly makes the data mobile). It is a nice model, but the routing within such a system feel uncomfortably rigid to me. I do have to look at it in more detail before passing any final judegement. > They also had a reference to some type of searching in encrypted data, > without revealing the search string? Presumably I guess you present some > encrypted string, and the algorithm tells you whether the string is present > in the data without decrypting either? That could be useful. I read the paper they reference some time ago, and it is interesting but 100% useless. Basically it is just encrypting every word as a seperate block and having the searcher encrypt the search terms with the same key (but modified heavily so as to not suffer from the million holes in that version). The only application it might be useful for are ASP like systems that keep the data secret from the ASP itself (which would be a cool thing, though not very related to what we are doing). In fact, the fact that they presented this as a workable alternative for searching REALLY did a disservice to the Oceanstore paper in my eyes (they obviously had not really considered it). > > theo > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://www.uprizer.com/mailman/listinfo/devl > _______________________________________________ Devl mailing list Devl at freenetproject.org http://www.uprizer.com/mailman/listinfo/devl
