Re: [Mldonkey-users] Bug in Overnet source handling causes being banned

[Pierre Etchemaite]

Le Fri, 06 Feb 2004 19:08:05 +0100, address@hidden a écrit :

> Yes, but I'm not talking about my mldonkey's own hash, but about the 
> hash of sources that MLdonkey learns about.

Ah, this is clear now. The problem is the use of the term "client hash",
that is already used with another meaning.

> [...]
>
> And now comes the bug: MLdonkey treats this client as a NEW SOURCE, 
> without checking if there is already a source with the same IP and 
> client hash. MLdonkey assigns client number 16655 to that source.

In the case of eDonkey and Overnet, sources are stored together, with a
boolean flag to tell Overnet peers from eDonkey peers. A peer can still be
seen as two separate sources, because sources are indexed by (address, port)
couple, and ports are different. I think it could be fixed by indexing on
address alone, if bad side-effects aren't too bad (nat ?). I don't like much
the idea of using"client name" for indexing, as nothing guarantees that a
peer will use the same name on all networks; client name can also be
modified on the fly."client hash" (in the traditionnal meaning ;) ) may be
considered; but carefully, because of hash stealers. eMule peers use
a "secure hash" when available, but that's not implemented in MLdonkey.

But there's more.

They're eDonkey peers known under several identities, because they're
connected to several servers at once (are there clients known to connect to
several servers at once, beside MLdonkey ?), and have either a highid and a
lowid, or several lowids. That case may be solved by checking client's
hashes, an easy task, again if there was no hash stealers...

And of course, they're all the other networks combinaisons, now that several
clients feature multi net supports, or even swarming. And with networks
using "virtual" peers identifiers, it will become impossible to check
whether two sources identities on two networks are only one peer, or several
(on the other hand, the same would certainly be true from that peer point of
view, too... So we can just forget about that problem)


To keep it short, maybe swarming will require that "client identity" is
rethinked, so that all sources can be put in a pool common to all
network supports, or at least pools, one pool for each favorite way to
identify sources in the supported networks (IP address, identity "cookies"
-of several sizes ?-, secured hash,...)