eDonkey stupidity

ethan on 2003-11-04T10:36:38

The eDonkey protocol appears to have something like an upload:download ratio which prevents you from downloading with full speed when only allowing an upload rate of, say, 2K. Today I was looking for a temporary replacement for my standard eDonky client (xMule) since it is a little out-of-date with respect to the latest changes in protocol. So I tried aMule which just appears to be a fork of xMule.

In the forums of the aMule webside I saw someone asking why they didn't change the UL:DL ratio so that it's more useful for downloaders. I imagined I knew the answer: "This is a server-side thing and clients can't change it". However and to my surprise, the poster harvested a snippish comment from one of the developpers (going along the way of "this is give and take etc."). So I became curious since that sounded as though this ratio is controlled on the client-side.

I grepped through the src/ directory and after a while pinned the setting of the ratio down to this code (sorry for the inconvenient wrapping):

if (app_prefs->prefs->maxupload != 0 && app_prefs->prefs->maxupload != UNLIMITED) { if (app_prefs->prefs->maxupload < 4 && (app_prefs->prefs->maxupload*3 < app_prefs->prefs->maxdownload)) { app_prefs->prefs->maxdownload = app_prefs->prefs->maxupload*3; } if (app_prefs->prefs->maxupload < 10 && (app_prefs->prefs->maxupload*4 < app_prefs->prefs->maxdownload)) { app_prefs->prefs->maxdownload = app_prefs->prefs->maxupload*4; } }


Since I wasn't sure which of the above two if-branches gets executed under which condition I changed the thing to

if (app_prefs->prefs->maxupload != 0 && app_prefs->prefs->maxupload != UNLIMITED) { if (1) { app_prefs->prefs->maxdownload = app_prefs->prefs->maxupload*10; } if (app_prefs->prefs->maxupload < 10 && (app_prefs->prefs->maxupload*4 < app_prefs->prefs->maxdownload)) { app_prefs->prefs->maxdownload = app_prefs->prefs->maxupload*10; } }


and was eager to see what happens. It looks as though this indeed changed the ratio. I couldn't quite confirm it since aMule crashed before it came to download anything (but not because of the above change; something to do with previewing files in mplayer). So I've returned to xMule and wait till they update their client. Since aMule's and xMule's code are the same save for the UI stuff, I know what I have to do when I want to tune the whole thing just a little.

Ethical, you may ask? No, but protocols that are implemented client-sidedly are just waiting for abuse. Secondly, I think this is still better than simply hiding all my shares (I still grant people 9K which is 75% of my whole upload-capacity).


You can't measure upload rates on the server ...

samtregar on 2003-11-04T18:14:59

... unless all upload streams pass through the server. And you don't really want that. Most p2p servers are just matchmakers for their clients. Since the actual data transfer works point-to-point there's really no way for the server to restrict the flow.

-sam

Re:You can't measure upload rates on the server ..

ethan on 2003-11-04T18:57:49

Yes, this is probably the explanation behind this whole matter.

I don't even know whether the ratio-thing is implemented in the original eEule client since I never used it. What did however surprise me is that the programmers of a GPL-projects would even bother to implement such a mechanism. Considering the targeted audience it's rather easy to predict that some people will circumvent it making the whole thing probably worse than it would have been without it in the first place. The honest (or clueless) people will now have a disadvantage against the cheaters.

The Real Thing

shiflett on 2003-11-05T04:43:11

Have you ever considered using the real thing? We have a Linux command line client, and there is an open source GUI frontend that works with the command line clients of both eDonkey2000 as well as the serverless (and overall better) client, Overnet.

What's cool is that because the Linux market is so small, there are no banners or anything of the sort, and it's still free (as in beer). We make our money off of all the Windows users.

My mistake (was: Re:The Real Thing)

ethan on 2003-11-05T08:46:23

I think when I wrote eDonkey, each time I meant eMule. Those two aren't the same, or are they? Anyway, it's so confusing...

As for the original edonkey client, yes, those were the days really. I used it for a while at the beginning. At this time, the gtk-GUI already existed but I wasn't able to make it work reliably so I used the command-line interface. That was funny since this program did not use libreadline or anything like that but plan stdin and stdout. It was close to unusable, servers only had a couple of hundred people on them, movies were tricky to get...I loved it (really). :-)

I haven't ever given a try to eDonkey again ever since as I am quite happy with eMule. I heard good things about overnet though, maybe I'll try that some time.

Re:My mistake (was: Re:The Real Thing)

shiflett on 2003-11-05T14:48:26

Yeah, the two are different. eMule is the open source clone. Basically, the guy that originally wrote eDonkey says that eMule was the better client a few years ago, even though they reverse-engineered his protocol and such. Now, however, I think the official client is quite a bit better than any alternative (even those using other networks), due in part to having more programmers and using better software development methodologies. There is also a nice plugin architecture now for other protocols, and we've already added HTTP support.

Overnet is better in every way, in my opinion, since it is the same as eDonkey except that it does not rely on central servers. Of course, this gives rogue clients the potential for more power, but that's sort of what you want, right? :-)

another edonkey client

mary.poppins on 2003-11-07T03:46:11

another edonkey client is mlDonkey