dht

I'm looking for recommendations for a simple open source implementation of a Distributed Hash Table in Java to play around with. No fancy features, just for learning purposes, no production functionality needed. It should be simple to set up (e.g. 1 physical machine with n-JVMs) and well documented preferably with some examples, tutorials or starting guides. Research yields these candidates: FreePastry and OpenChord but I'm not fully convinced they meet my criteria simplicity-wise. Have you got any experience with these or other implementations? Recommendations? Thanks & adios Maybe JDHT will

I am looking for a reasonably well tested library+server to store a persistent distributed hash table. I am hesistant to use SQL-based solutions as the data is highly document oriented, consisting of millions of ~64KB blobs with only a single index (computed by hash of said BLOB) - and needs to be able to be distributed for long term scaling prospects. Due to expense and bandwidth considerations, external solutions such as S3 are not an option. Something like CouchDB or Project Voldemort would be ideal - however there is a noticable lack of .NET bindings for both (PV can be IKVMC'd from Java -

I can't quite wrap my brain around the joining process of Kademlia DHTs. I've seen a few tutorials and presentations online, but they all seem to say things the same way and all psedo code etc is the same in most (actual copy/paste). Can somebody give a high level walk through on this? Joshua Kissoon I'm assuming you've read the Kademlia paper . Here's an excerpt from my article An Introduction to Kademlia DHT & How It Works Some background information: When you have a Kademlia network running, there should always be a node that every other node knows about in order for them to join the

Which Distributed Hash Table (DHT) is easiest to implement in Python? Any good example that is not bloated? I not am looking for a definition of DHT because I am more oriented and focused on design and implementation of such. If you are focused on implementation, rather than looking for an out-of-the-box solution, this article might help a bit: http://www.linuxjournal.com/article/6797 In my job I'm working with entagled . I can't say it's great code, but it seems to be the only Kademlia implementation for Python around. I think Kademlia has become the default DHT for most applications today,

I'm coding a p2p implementation that I would like to make decentralized however I'm having some trouble grasping how DHT in protocols like bittorrent work. How does the client know where the peers are if there is no tracker? Are peers stored in the actual torrent file? With trackerless/DHT torrents, peer IP addresses are stored in the DHT using the BitTorrent infohash as the key. Since all a tracker does, basically, is respond to put/get requests, this functionality corresponds exactly to the interface that a DHT (distributed hash table) provides: it allows you to look up and store IP

Could any one give an explanation on how a DHT works? Nothing too heavy, just the basics. Ok, they're fundamentally a pretty simple idea. A DHT gives you a dictionary-like interface, but the nodes are distributed across the network. The trick with DHTs is that the node that gets to store a particular key is found by hashing that key, so in effect your hash-table buckets are now independent nodes in a network. This gives a lot of fault-tolerance and reliability, and possibly some performance benefit, but it also throws up a lot of headaches. For example, what happens when a node leaves the

I'm working on implementing yet another bittorrent client and at this time struggling with DHT. It is implemented accordingly to this specification http://www.bittorrent.org/beps/bep_0005.html but starting debugging it I noticed that other nodes' responses on the network vary. For example, find_node is supposed to return either target node info or 8 closest nodes. Most of the nodes reply with 34 closest nodes and usually only 1 - 3 nodes from those 34 successfully reply to the consequent ping request. Is there another document with better implementation recommendation? May be it is already