Ximin Luo wrote: > On 01/20/2010 04:25 PM, alex wrote: > > I see all these difficulties, and then some. For example, cooperative > > index >> building. Can this be completely replaced by aggregated indexes relying >> on a WoT? I say this because I see a basic difference at work here. In >> freenet, I understand that a btree is inserted under some key, and thus >> can be authored by a single "entity" (or collection of trusted peers). >> However, in traditional p2p, distributed hash tables (e.g. kademlia) are >> built by all peers. Or I'm wrong here about how btrees will work in >> freenet? > > The b-tree works on a different layer from the DHT - it's implemented on > top of it. The node layer only knows about the DHT, the b-tree doesn't > affect it. The individual b-tree "nodes" are just normal entries in the > DHT, and these entries point to each other, these pointers forming the > "tree" structure.
Bear with me, please, my understanding of freenet is not deep. What are you referring to with DHT here? My guess would be that you refer to the keyspace that freenet manages (CHK --> Value). If that's so, I already was of the idea that the b-tree is a construction done with some clever usage of freenet keys, that of course the node is unaware of (just like frost boards, the WoT, etc). My question is more if the insertion/access is done through one single USK subspace, or several, or what. Since CHKs are immutable, I guess that the question makes not much sense for the leaves of the tree: they're what they are, with its CHK. Internal nodes, in the end, are also some data pointing to children that has an unique CHK. My guess is that one interesting property of the b-tree for freenet is that changes in its content require relatively few node modifications. In regular in-memory trees, changes stop "locally", since you can modify a node content without altering the pointers to it from the parent node. In freenet, given the direct relation from data to its reference (the CHK), I don't grasp how this doesn't propagate all the way to the root. Or it does and we are talking of an additional logarithmic cost anyway (in the number of keys to be modified)? I hope I'm not making nonsensical questions, if that's the case just tell me :) Anyway, if there's some documentation around on how this works, this is very interesting stuff to me. Another guess is that, given a "snapshot" of the tree, with few insertions you can give a new root (CHK or USK, whatever) that points to the updated data. Basically, "forking" the tree is a cheap operation. I'm on the right track? This would answer my question four paragraphs back. And the ice in the cake is that searching any of these trees is made in logarithmic count of key retrievals, right? > > X
