![]() |
![]() |
| News | Introduction | User's Guide | FAQ | Publications | Mailing List | People |
While many research prototype DHT implementations are available today, a would-be developer cannot easily deploy a DHT. First, for a deployed DHT to scale to heavy request workloads, and be robust under node failures, the DHT code must be run on a large collection of hosts. Non-researcher developers seldom have such host resources at their disposal. Second, maintaining a DHT deployment requires significant effort: keeping the DHT code running on all the DHT's constituent hosts, and on occasion, debugging a complex DHT's implementation both are tasks many application developers may be unwilling to take on. OpenDHT frees application developers from these two burdens, and thus eases their use of DHTs.
So far, we've implemented a chat client, a FreeDB cache, a new lookup layer for i3, and a CFS-like file storage layer. A number of other research projects are using OpenDHT as well. The most mature is Octopod.
A key in OpenDHT is any 20-byte value. There are no other restrictions. If one or more clients put more than one value under the same key, OpenDHT stores them all. On a get, all of the values are returned. (If there are many values, only some are returned at a time. Subsequent gets can fetch the rest. See the User's Guide for details.)
Currently, there's a 1024-byte limit on values in OpenDHT. To store larger values, you'll have to break them into blocks as in (for example) CFS.
Yes! See the discussion of the new, secure rm function in the User's Guide. In essence, when you perform a put, you may now also specify the SHA-1 hash of a secret. Later, you may remove the value by revealing the secret. The security of this scheme relies on the difficulting of inverting SHA-1.
That depends on what you mean by broken, but basically, no. It is getting weaker by the day, however, so we plan to support other hash algorithms in the future.
Believe it or not, that's not a bug. Bear with me here.
What we do with a remove is store it--key, value hash, and secret--just like any other put. Then if we ever see a put with the matching key, value, and secret hash, we throw it away.
If you send me a remove for which I don't have a matching put, though, it may just be because I'm not up to date as a replica, so I take it anyway. I could let you know if I don't know what you're talking about, but it would be my fault some of the time, and your fault others, so I just say success to let you know I've stored the remove.
In other words, there's always going to be the case where I don't think you've given me a meaningful remove, so long as OpenDHT is an eventually consistent (not strongly consistent) system. So I figure it's better to make you deal with that up front than to have it surprise you much later on.
| Last modified 2006/03/13 15:13:50 GMT. | ![]() |