[p2p-hackers] Hybrid Static/Dynamic DHT Systems

Bernard Traversat Bernard.Traversat at Sun.COM
Wed Apr 20 20:14:06 UTC 2005


You should look at JXTA (www.jxta.org). We have implemented a
loosely-coupled DHT that uses a lazy synchronization
mechanism to reduce the DHT re-synchronization issues you
are describing.

Hth,

B.

Cortland Klein wrote:

> This design proposal aims to describe a DHT system which has both a 
> functional mutable hash table and a replicating static content hash 
> table.
>
> The problem I see with traditional DHT systems is that they can not 
> easilly replicate data without making it much more difficult to 
> maintain up-to-date state. In addition, it becomes impossible to 
> provide an immutable reference to particular data.
>
> A Hybrid DHT System would have two subsystems, the traditional dynamic 
> mutable hash table and the added replicating static content hash table.
>
> The static content hash table is a simple table where the keys are the 
> SHA-1 of the content and the content is a length prefixed amount of 
> data limited to 256KB. When a key is requested, it's value is 
> automatically cached among the path of nodes to the node requesting 
> the data. Nodes maintain their own caches and replace old keys with 
> new keys as they pass through. Old keys are chosen based not only on 
> their last request time, but also how close the key is to the node's 
> ID. If the node is 'responsible' for a key, it remains in the cache 
> indefinitely. Thus, we can achieve replication while ensuring at least 
> one copy is always on the network. Data larger than 256KB is split up 
> into chunks and a splitfile containing a list of the static content 
> keys for each chunk is used to represent the data.
>
> The dynamic mutable hash table provides for each key a revisioned list 
> of pointers to static content keys. Thus, each dynamic key's content 
> has a table with datestamps and static content keys. To get the 
> current value for a dynamic key, the system then does a lookup for the 
> static content key. The node responsible for the key maintains this 
> revisioned list and updates it when a put is made on the key. It can 
> then expire old revisions after both a set number of revisions and at 
> least a certain amount of time have passed.
>
> My reasoning behind having two tables is that dynamic data cannot 
> easilly be replicated due to its mutability, however it can point to 
> static data which can be replicated. By having the static data retain 
> a 'responsible' node, we can ensure that at least one copy of the 
> static data is available.
>
> Any thoughts?
>


-- 
--http://weblogs.java.net/blog/tra
"As Java implies platform independence, and XML implies language
independence, JXTA implies network independence."





More information about the P2p-hackers mailing list