[erlang-questions] [ANN] [Alpha Release] dht - a distributed hash-table
Wed Aug 12 15:07:32 CEST 2015
I've really enjoyed seeing various tweets from you on this subject as
you worked through it. I was curious if it would be worthwhile for
someone (me? No clue of the effort involved) to port etorrent to use
this in place of its existing dht implementation. That would at least
make it easy to test it in a more 'production' environment fairly
quickly, I would think. I just don't even know if it's feasible to
do, or if this application is now too different from the etorrent dht
for it to be anything less than a large undertaking to swap them out.
On Wed, Aug 12, 2015 at 6:47 AM, Jesper Louis Andersen
> Hi list,
> I'm hereby announcing an early alpha-release of the `dht` application. It is
> an implementation of the Kademlia distributed hash table for Erlang, loosely
> based on the code which is in eTorrent, which originates from Magnus Klaar a
> few years back, but it has been completely rewritten in a lot of places.
> While here, I've switched the system to use 256 bit SHA-256 hashes over
> SHA-1 160 bit hashes which should be deprecated anyway. The README.md
> contains an overview of the API as it stands now.
> The perhaps most interesting R&D feature is that the hash table is 2.2K
> lines of code including comments, but its quickcheck model is 4.2K lines of
> code, including comments. Apart from one top-level module, every module has
> been checked as an isolated component and as clusters of components as well
> through the use of Erlang QuickCheck's clustering features. This doesn't
> prove the DHT is correct, but it does create a link between the model and
> the system under test: they are likely to be synchronized.
> I believe there is at least some research-grade work in the EQC model, if
> not for anything else, it is one of the largest Open Source models I know
> of. Another feature is a submodule which is used to mock time. By using
> component callouts, timer triggering is handled by preconditions in the
> model, and time is advanced in isolation from the main component. This
> yields a very natural way to control timers from the model which in turn
> lets you test timing code precisely, even in the case where timer
> interaction between different components has relevance.
> I've only run fairly simple tests, so any bug report is appreciated. Mind
> you, I've only quickchecked this code, not run it in production :)
> erlang-questions mailing list
More information about the erlang-questions