[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mldonkey-users] Bug in Overnet source handling causes being banned
From: |
mldonkey |
Subject: |
Re: [Mldonkey-users] Bug in Overnet source handling causes being banned |
Date: |
Sat, 07 Feb 2004 12:44:29 +0100 |
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
- [Mldonkey-users] Sha1 implementation benchmark, Fortin Denis, 2004/02/04
- Re: [Mldonkey-users] Sha1 implementation benchmark, kami petersen, 2004/02/04
- Re: [Mldonkey-users] Sha1 implementation benchmark, Fortin Denis, 2004/02/04
- [Mldonkey-users] Bug in Overnet source handling causes being banned, mldonkey, 2004/02/06
- Re: [Mldonkey-users] Bug in Overnet source handling causes being banned, Pierre Etchemaite, 2004/02/06
- Re: [Mldonkey-users] Bug in Overnet source handling causes being banned, mldonkey, 2004/02/06
- Re: [Mldonkey-users] Bug in Overnet source handling causes being banned, Pierre Etchemaite, 2004/02/06
- Re: [Mldonkey-users] Bug in Overnet source handling causes being banned,
mldonkey <=
[Mldonkey-users] Re: Sha1 implementation benchmark, spiralvoice, 2004/02/04
- Re: [Mldonkey-users] Re: Sha1 implementation benchmark, Fortin Denis, 2004/02/04
- [Mldonkey-users] Re: Re: Sha1 implementation benchmark, spiralvoice, 2004/02/04
- Re: [Mldonkey-users] Re: Re: Sha1 implementation benchmark, b8_bavard, 2004/02/05
- [Mldonkey-users] Re: Re: Re: Sha1 implementation benchmark, spiralvoice, 2004/02/05
- Re: [Mldonkey-users] Re: Re: Re: Sha1 implementation benchmark, Fortin Denis, 2004/02/05
- [Mldonkey-users] [PATCH] new Sha1 implementation, Fortin Denis, 2004/02/07
[Mldonkey-users] Re: Re: Sha1 implementation benchmark, spiralvoice, 2004/02/05