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

[mldonkey]

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

Ok, so let's call it "source hash" or whatever. :)
I called it client hash to differentiate between MD4 hashes which 
identify clients and MD4 hashes which identify files.

> 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 wouldn't do that, because of NAT (or several different clients running 
on the same machine), as you already mentioned.

> 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.

ACK

> "client hash" (in the traditionnal meaning ;) ) may be
> considered; but carefully, because of hash stealers. 

I think that's the best option (IP + "source hash" ;-) ). There should 
be no problem with NAT or multiple clients per IP, because if they are 
different, they should use a different source hash. That's the point of 
an unique idetifier, right? *g*
Hash stealing also shouldn't play into it here, because the only thing 
we change is storing one client instead of two for the same IP. No 
change of stored IP which could help a hash stealer.

> eMule peers use
> a "secure hash" when available, but that's not implemented in MLdonkey.

...yet? ;-))

> 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...

Let's just consider clients which connect to Overnet and Edonkey at 
once. AFAIK, there is only the "official" hybrid client and MLdonkey so 
far. And the "official" client doesn't connect to multiple servers and 
uses the same "source hash" on overnet and edonkey. That should solve 
our problem for most other clients.


Best regards,
phoenix