mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How to fight abuse of mldonkey [Was: Re: [Mldonkey-users] Emule]


From: Goswin Brederlow
Subject: How to fight abuse of mldonkey [Was: Re: [Mldonkey-users] Emule]
Date: 04 Sep 2002 13:07:56 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

MLdonkey <address@hidden> writes:

> > What do you think of it? I've heard, that it is COMPLETELY
> > OpenSource, so that everyone can see Edonkey protocol in plain c++.
> 
> Yes, and, as a consequence, mldonkey protocol files will be released
> in next snapshot.

Great. I just made an ITP for mldonkey for debian saying that I would
probably port emule to be a free donkey core for mldonkey, but now you
safe me a lot of work.

> > Is that dangerous for the Edonkey network? (just because MLdonkey
> > said, that it would be dangerous for Edonkey, if he makes the
> > edonkey part of MLdonkey OpenSource)
> 
> Well, it depends on how we react. If we decide to change the protocol
> to detect cheating clients, it will not be dangerous. Cheating clients
> will not be better than other ones, and people will prefer the other
> ones. 
> 
> Currently, I have two ideas:
> - Recommandations for good uploaders, propagated between clients when
>     needed, for them to gain priority for download.

You mean a web-of-trust style or some monetary system?

I'm thinking about a monetary system. Each action costs something.
Each client accounts for the actions. If you upload the same you
download the money balances and you don't have to pay and don't get
payed. Thats the easy case.

If there is a inbalance the clinets have to exchange some monetray
token. This could be a simple random number cryptographically
signed (public/private key method). By knowing the public key of a
client you can verify the signature.

The money tokens could then be passed on to other clients, they don't
have to be the clients own tokens. As long as the recipient knows the
right public key the token can be verified. The keys itself could
carrie signatures about how trustworthy that clients tokens are. (Your
idea of propagation of good clients).

Secondly the amount of money a client is willing to pay for something
should set the priority of an upload. Of cause you would want to
upload to the client paying you the most and download from a client
that charges least. If you have a low download limit you wouldn't pay
a extra fee for speedier download, since your limit would be maxed out
anyway. and so on.

> - Special servers, communicating to detect clients connected to too
>     many servers, and propagating a black-list to all servers to
>     get rid of these clients...

Servers could function as a kind of bank. Since they don't download
they would suck money out of the system. That money could then be
exchanged (in case some client doesn't accept someone elses money
directly) and if money of a certain client builds up that client
would get a lower and lower score and then get no conects.

> >  Will Emule and MLdonkey perhaps cooperate? 
> 
> Yes, they will. We are now in contact to see how ...
> 
> - MLDonkey

Another thing that hasn't been addressed is clients that send out bad
files, bad checksumms and/or bad data.

For bad blocks other p2p protocols download the same random chunk from
many clients and take the chunk that the majority gives back as the
true file. All other clients are then ignored for that file.

Bad checksums could be handled in a similar way.

MfG
        Goswin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]