Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ethan (3163)

ethan
  reversethis-{ed. ... rap.nov.olissat}

Being a 25-year old chap living in the western-most town of Germany. Stuying communication and information science and being a huge fan of XS-related things.

Journal of ethan (3163)

Tuesday November 04, 2003
05:36 AM

eDonkey stupidity

[ #15548 ]

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).

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ... 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

    • 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) peo
  • Have you ever considered using the real thing? We have a Linux command line client, and there is an open source GUI frontend [sourceforge.net] that works with the command line clients of both eDonkey2000 as well as the serverless (and overall better) client, Overnet [overnet.com].

    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.

    • 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 coup
      • 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

  • another edonkey client is mlDonkey