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

[mldonkey]

Pierre Etchemaite wrote:
> Le Fri, 06 Feb 2004 13:44:20 +0100, address@hidden a écrit :
> > I believe that a solution would be to check if a client with the same 
> > IP/Port and the same client hash already exists in either edonkey OR 
> > overnet sources before adding a new source. (Just checking the IP is not 
> > enough, because it is possible that more than one client run on the same 
> > machine with a different port & client hash.)
>
>
> MLdonkey doesn't use the same hash for eDonkey and Overnet, so it won't
> work.

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

Suppose MLdonkey started a source search for a specific file on the 
edonkey network. The following result is received (more or less that way):

Client name:  xwotpc
IP:           123.45.67.89
Client hash:  899F7E878C2E0A87EDE7B25CC0645095

MLdonkey assigns internal client number 37088 to this source.
Now MLdonkey searches for sources of the same file on overnet. Among the 
results, there is the same client:

Client name:  xwotpc
IP:           123.45.67.89
Client hash:  899F7E878C2E0A87EDE7B25CC0645095

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.

The result is what I can see in my file details:

Num   CS   Name   CB  O C IP address   UL   DL MD4
37088 Qued xwotpc tML F D 123.45.67.89 2.0M 0  899F7E8...
16655      xwotpc OVR T D 123.45.67.89 0    0  899F7E8...

So the SAME CLIENT (identical IP, identical MD4 hash) is stored twice, 
so we send our "reask"-packets too fast and get banned.

> client hash on eDonkey is just a peer identifier, with some bytes (6th and
> 14th or something) used as magic values to enable eMule features.
>
>
> client hash on Overnet is a peer identifier too, but it's also used to
> "locate" the peer in the xor-distance space, and used to determine what keys
> will be stored on the local database of that peer.
>
> Since each have their own semantics, it may not be a very good idea to use
> the same value for both (eMule magic bytes would restrict peers to some
> hyperplane. Not fatal, but not clean either).

You are right here. So we might not be able to properly match an 
"overnet-source-hit" and an "edonkey-source-hit" together, if the client 
is another mldonkey, which uses a different hash on each network. But at 
least for the edonkey hybrid clients it should work.


BTW: Does anybody know what client brands send the "[AUTOMATED WARNING] 
Your client is connecting too fast, it will get banned" messages? Only 
mldonkey, or emule / edonkey too?

Regards,
phoenix