Hello, Ebener, You can try kelips that is a two-hops DHT system.
1) only one handles my STOREINFO, 2) this one peer redistributes the changed data to all these k peers, 3) all replicas are updated, 4) no other peer stores data on this key while operations 1-3 are performed. You can accomplish these operations base on the kelip system easily. Kelips: Building an Efficient and Stable P2P DHT Through Increased Memory and Background Overhead, IPTPS 2003. regards, Chi-Jen Wu Karl Ebener wrote: > Hi, > > I am trying to develop/improve a DHT for my thesis and I seem to have > come up with a problem I would love to discuss/hear your thoughts on: > > I want different peers to store information using the same key. Let's > say, peer1 performs a Store-Operation with arguments (key, > <information1>), where <information1> is the data load. When a second > peer peer2 performs another Store-Operation with argument (key, > <information2>) I do not want <information2> to replace <information1>. > Instead, I need *one* peer to take the "old" <information1>, add > <information2>, perhaps just add <information2> as a second element of a > list, or even perform some calculations on it first, and then distribute > the complete result (e.g. a list <information1, information2>). More > peers will add to this list and elements will have to be removed, too. > Since a DHT is mainly just like a Java-Map, I need the map to store a > list denoted by the key, thus like > > List<String> myList; > Map<Integer, myList> distributedList; > > I am currently thinking of this as a special DHT-operation, e.g. > STOREINFO or STOREDATA or the like that uses the original > Store-information to publicize the aggregated data after adding it up. > > What I do not want, is to store just a link to a list which is then > stored on *one* peer (=store just the peers address in the DHT) and then > let this one peer handle everything, which would be like storing > documents in a DHT, because I want to retain the data even if this *one* > peer leaves the network (with performing Leave-Operation or without), I > need this data to be distributed and replicated. > > Now, I am trying to think of ways and of DHTs to easily accomplish this. > I was very impressed with Kademlia in general, there are some nice > Java-implementations out there that would greatly help (e.g. Mojito, > Plan-X). > However, Kademlia stores the information at the k peers, that are > closest to the "address" denoted by the key. When I want to update this > information, I have to make sure 1) only one handles my STOREINFO, 2) > this one peer redistributes the changed data to all these k peers, 3) > all replicas are updated, 4) no other peer stores data on this key while > operations 1-3 are performed. This sounds complex and will most likely > fail in a distributed environment. It would no be a problem if it takes > some time until the new information is distributed and peers looking it > up get the old information until then, but I do not want the list to be > corrupted. > I am thinking of changing to Chord (OpenChord) where I imagine I might > have more control - but losing the advantages of Kademlia, unfortunately. > > Does anyone here have a clue if I can accomplish this operation in a > "smarter" way, with a "smarter" DHT to build upon asf.???? > I am grateful for any tips you have for me! If I am running completely > wrong and/or should just look at it another way or anything, I would > also like to hear it ;-) > > Thanks very much > Karl > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
