<DIV>when i designed my hashing system i gave up trying to understand all the academic stuff. i don't get it....i don't even know why you need hashing in peer to peer systems. I used it for search and db entries to make it supper fast; cause somparing strings would be slow; the only real requirements are 1) speed (fast hashing), 2) wide distribution (little collision) and 3) all software running on my netowrk use the same function (not hard since you need software to search). I then found one on the internet; and now just use that.</DIV>
<DIV> </DIV>
<DIV>so <BR><BR><B><I>Cortland Klein <me@pixelcort.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">This design proposal aims to describe a DHT system which has both a <BR>functional mutable hash table and a replicating static content hash table.<BR><BR>The problem I see with traditional DHT systems is that they can not <BR>easilly replicate data without making it much more difficult to maintain <BR>up-to-date state. In addition, it becomes impossible to provide an <BR>immutable reference to particular data.<BR><BR>A Hybrid DHT System would have two subsystems, the traditional dynamic <BR>mutable hash table and the added replicating static content hash table.<BR><BR>The static content hash table is a simple table where the keys are the <BR>SHA-1 of the content and the content is a length prefixed amount of data <BR>limited to 256KB. When a key is requested, it's value is automatically <BR>cached among the path of nodes to the node requesting the data. Nodes <BR>maintain their own
caches and replace old keys with new keys as they <BR>pass through. Old keys are chosen based not only on their last request <BR>time, but also how close the key is to the node's ID. If the node is <BR>'responsible' for a key, it remains in the cache indefinitely. Thus, we <BR>can achieve replication while ensuring at least one copy is always on <BR>the network. Data larger than 256KB is split up into chunks and a <BR>splitfile containing a list of the static content keys for each chunk is <BR>used to represent the data.<BR><BR>The dynamic mutable hash table provides for each key a revisioned list <BR>of pointers to static content keys. Thus, each dynamic key's content has <BR>a table with datestamps and static content keys. To get the current <BR>value for a dynamic key, the system then does a lookup for the static <BR>content key. The node responsible for the key maintains this revisioned <BR>list and updates it when a put is made on the key. It can then expire <BR>old revisions
after both a set number of revisions and at least a <BR>certain amount of time have passed.<BR><BR>My reasoning behind having two tables is that dynamic data cannot <BR>easilly be replicated due to its mutability, however it can point to <BR>static data which can be replicated. By having the static data retain a <BR>'responsible' node, we can ensure that at least one copy of the static <BR>data is available.<BR><BR>Any thoughts?<BR><BR>-- <BR>Cortland Klein <ME@PIXELCORT.COM>(XMPP/SMTP)<BR>nuWeb Project Founder - http://nuweb.org/ "Infinite Scalability"<BR>Journal - http://pixelcort.com/ "Ranting and Raving"<BR>The geeks shall take over the world and the bits shall be set free!<BR>_______________________________________________<BR>p2p-hackers mailing list<BR>p2p-hackers@zgp.org<BR>http://zgp.org/mailman/listinfo/p2p-hackers<BR>_______________________________________________<BR>Here is a web page listing P2P
Conferences:<BR>http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences<BR></BLOCKQUOTE><BR><BR>You don't get no juice unless you squeeze<br>Lemon Obrien, the Third.<p>
<hr size=1>Do you Yahoo!?<br>
Yahoo! Small Business - <a href="http://us.rd.yahoo.com/evt=31637/*http://smallbusiness.yahoo.com/resources/">Try our new resources site!</a>