[tahoe-dev] Google Summer of Code 2010 -- Ideas Needed!
Jeremy Fitzhardinge
jeremy at goop.org
Fri Mar 12 14:44:35 PST 2010
On 03/12/2010 02:29 PM, Zooko Wilcox-O'Hearn wrote:
> On Friday, 2010-03-12, at 15:20 , Jeremy Fitzhardinge wrote:
>
>> Not sure how they'd find out about each other; perhaps the
>> introducer could do it, but it might be interesting to build a DLM-
>> like thing on top of a general chordish DHT.
>>
> That might be related to #68 (implement distributed introduction,
> remove Introducer as a single point of failure) and #295 (distributed
> control of access to nodes).
>
Yes, and yes.
>> Adding a DHT to Tahoe would be a worthy GSOC project in itself; has
>> it been mentioned?
>>
> Well there is #869 (Allow Tahoe filesystem to be run over a different
> key-value-store / DHT implementation), but I guess that's not what
> you mean. What do you mean?
>
I'm thinking in handwavy terms that a DHT would be a useful piece of
infrastructure to operate in parallel with Tahoe, and as a something
future Tahoe-related features could be built on. I'm thinking that the
DHT would be for ephemeral information which may be updated
moment-to-moment, vs data stored on nodes with proper caps (but perhaps
I'm making a distinction without a difference).
Off the top of my head:
* distributed introducer is an excellent first step, which is
probably justification on its own
* automatic discovery of helpers
* real-time grid-wide stats
* facilitate node-to-node communication (for write coordination,
messaging, etc)
Look at my hands go!
Would there be any value in (or even possible to) make use of an
existing DHT (like the BT distributed trackers) to get more strength in
numbers?
J
More information about the tahoe-dev
mailing list