Re: [Mldonkey-users] eMule Mod to emulate mldonkey

[Goswin Brederlow]

Jochen Radmacher <address@hidden> writes:

> Hi,
> Roland Arendes wrote:
> 
> > Hi
> >
> > FYI
> >
> > -- 
> > Added MLDonkey to the statistic
> >
> > MLDonkey Emulation
> > MLDonkey is very unfair against eMule users. It allows only one third of
> > the uploadqueue to beoccupied by eMule clients.
> 
> We need something that does not favor one particular client, or we
> will always see such mods...
> 
> How about making the distribution dynamic, dependend on " seen" or
> "downloaded" in the statistic. If the download comes mainly from one
> client Type, even it is emule( i doubt that...), this type of client
> should get the most upload.

Make it depend on the downloaded %. The client type that strays most
from an equal up/down % should get priority.

Its only fair to upload more to overnet if you download everything
from overnet.

> > Additionally it favourises MLDonkey by giving
> > them always a slot.
> >
> That's not good Style.
> The only  ones who should  always have  a slot are my Friends!
> 
> >
> > In drder not to have this disadvantage MavMule emulates a MLDonkey client
> > when he connects
> > to an MLDonkey client.
> >
> That raises one Question: Who is the first client that says: Im a
> [emule/mldonkey]-client? If it is the connecting client, we could
> "play emule" in that case. But this should only be a temporary fix...

Why not build a client that emulates a random client with each
connect? That way no matter what gets favoured a percentage of
connects with be favoured.



Come on, get serious.

Wasn't the client type protection ment to see if we could use extra
protocol options edonkey didn't have, like source sharing etc?

MfG
        Goswin

PS: I still intend to implement FEC for mldonkey. That MavMule client should 
get pretty confused recieving redundancy chunks it never heard about.