|
From: | B. Fallenstein |
Subject: | Re: [Gzz] hemppah's research problems document |
Date: | Sat, 14 Dec 2002 21:49:19 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.2) Gecko/20021204 Debian/1.2.1-1 |
Tuomas Lukka wrote:
Some systems, such as DHTs cannot let other people use this "mirror" becausethe files are not in the location the DHT would place them in.So if we think about a 5GB / 100MB split between my mirrored data / DHT area (which is quite reasonable), most of the potential capacity in the networkis not getting used!I don't understand at all. As I have been so adamant about in my statements to hemppah, the DHT is for *locating* the data in thenetwork.No, that raises entirely different set of issues.An entirely different set of issues than what?Your machine would, when going online, place into the DHT mappings (blockid -> your-ip-address), so if any computer tries to download the RFCs, they would in the DHT get your machine's address, andthen contact your machine to download from there.The problem is that this puts in more steps to the algorithm and makes it MUCH more vulnerable to attacks: simply placing bogus data will be a prettygood attack.More vulnerable to attacks than what? Are you *seriously* suggesting that the DHT should store the actual blocks?What I'm seriously saying is that1) DHT storing the actual blocks is + pretty well understood
Pointers?There are loads of p2p systems with a location step and a download step in actual use (Napster, Gnutella, Kazaa, eDonkey, Overnet, Circle...); some of them are based on DHTs. I don't know any off the top of my head that are storing the files as DHT values, and no research projects, either.
+ quite efficient, robust and not too attackable
Efficient? I've just joined the network, please push the 100MB of data I'm supposed to host on my machine down my 56k link.
Not too attackable? Please store this 5TB block for me, your node is responsible for its key.
- Benja
[Prev in Thread] | Current Thread | [Next in Thread] |