[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mldonkey-users] Possible Idea for simultaineous inter-network trans
From: |
vnc |
Subject: |
Re: [Mldonkey-users] Possible Idea for simultaineous inter-network transfers |
Date: |
Wed, 21 May 2003 12:33:59 +0200 |
Hi,
> Say we are downloading a file from client A on ed2k,
> which has ed2k md4_hash AAAA, and we notice that the
> same IP has a gnutella2 client/plugin running on it,
> (because it's mldonkey, sharaza etc) with the same
> file shared (same by filesize anyway..) with gnutella2
> "hash" BB:BB. Can we safely assume that if the client
> is mldonkey or sharaza, these two sources are the same
> file?
this has already been thought of, sure :).
There exist two possible solutions to that problem: A decentralised approach
which you mentioned and a central database (not a very good idea IMHO).
The problem we have is that we have to put a big amount of trust in the peer
from which we get the associated hashes. If a file has been spread already we
could broadcast a request to send us associated hashes. We then count how many
different hashes we receive, the one which comes in most often is possibly the
correct one. After successfully having downloaded the file, we put the
hash-association in our database for further information. Effectively we build
a distributed hash-association database (which content should remain intact
even if we delete the downloaded files).
The general problem is trust: You have no definitive source which you can
trust, so there are several possibilities for malicious nodes to exploit these
circumstances (constantly sending wrong hashes etc). This is particularly nasty
with new files if you use the amount of similar incoming hashes as a
rating-system.
You don't have this problem with the ed2k-chunk-hashes which you get from your
ed2k-peers, as the master-hash is the hash of the concatenated chunk-hashes.
Any more ideas on how to reliably get associated hashes/identifiers?
-vnc