aMule Forum
English => Feature requests => Topic started by: davem on February 05, 2015, 10:11:57 PM
-
Bit torrent tends to be faster mainly because clients are seeding fewer files. Generally leeechers are seeding the pieces they have while downloading and are seeding nothing else or little else. As others do this the availble speeds increase in the swarm (at the expense of a more limited selection of files). I will leave the explanation of bit torrent at this as it is not the point of the post.
Well here is the simple idea.
Why not simply have two queues? One for files which we are currently downloading and one for files which we are currently seeding. The former (downloading) gets say 75% of the upload bandwidth and the latter (seeding) gets the remaining 25%. The effect of this then as other ED2K clients implemented this would be a bit torrent like experience while at the same time maintaining access to the same amount of file selection.
When not downloading of course the other queue would get the full upload bandwidth. The same would be true for if the downloading queue bandwidth was not being fully utilized -- it would then go to the seeding queue.
Also I will mention that while the greatest benefit from this would only come if and when other ed2k clients also implemented this it would appear to also have an immediate potential benefit to amule users due to the use of the credit system. You would be sharing more faster to clients which have the file you are downloading and would thus in theory move up their queue faster as you gain credits to to your uploads to them.
-
Your idea works in an environment where most of the clients have an incomplete version of the file. However, in the opposite case (where you're the sole 'leecher' and all the others are 'seeders') the two-queue system would reduce your download speed, because all the sources would prefer uploading to clients that have the file they want.
There's no need to reinvent the wheel, the credit system works well.
-
Your idea works in an environment where most of the clients have an incomplete version of the file. However, in the opposite case (where you're the sole 'leecher' and all the others are 'seeders') the two-queue system would reduce your download speed, because all the sources would prefer uploading to clients that have the file they want.
Well the main thing the typical user cares about is the speed with which they get the file. If you don't satisfy them they quit using the program and the network loses all their shares. Basically it is just making things more bit torrent like. Your queue would focus on the files you are downloading although there would still be some capacity left for seeding other files. If there are no other leechers looking for the file besides yourself it would go to the other seeding queue.
It might seem that it would be harder to get files but that wouldn't be the effect. In fact it is preferred that you get as many sources as possible ASAP so it is better if people can download a file as quickly as possible (and then start seeding it themselves). If it takes a week then that other seed may not be there any longer and you are stuck with an incomplete file.
There's no need to reinvent the wheel, the credit system works well.
I don't know. I think it helps but I can get a file in about 1/10th the time now with bit torrent versus ed2k. The reason for that is that overall the leechers and seeders dedicate more of their bandwidth to the file they are seeding/downloading. I use both Vuze and amule. I keep both running 24/7 but I notice the difference right away. I watch the queue positions and it just seems pretty crazy. I get 10MB of the 2 GB file and then I'm back at position 300 in the queue. My average download rate according to the statistics is about 6 KB/s. 6 KB/s, GonoszTopi! Like dialup internet speeds! That is pretty ridiculous. My average upload rate is about 30 KB/s (It's 15 KB/s in the day when I work on the computer and 60 KB/s at night). It just seems to me that we really should be doing something to be more competitive. I also feel that I ought to be able to at least download at a rate equal to that which I upload. Instead I'm stuck in queues and usually idle. Meanwhile I'm almost always uploading at full capacity according to the max I set.
It just seems broken. <shrug>
-
In thinking, a lazy way to implement this might be to simply double or triple the credit value for files which we are currently downloading (incomplete). 1 becomes 3, 3 becomes 9, 9 becomes 10 (the max), etc. It's sub-optimal but a quick way to do it without a lot of coding.
I would try to create a plugin as a proof of concept and for experimentation but it appears there is no plugin system. It would require a full mod it seems. :(
-
Would a patch for this using the simple modification factor scheme be considered if it were complete and provided all the prefs and UI modifications needed? (i.e. for downloading files the Queue ration would be multiplied by 3 making for a range between 3-10 for files currently downloading) Or would a fork or such be preferred?
I note it isn't very different than the emule system where they assign upload priorities to files ranging from 0.2 (very low) - 1.9 (release). Essentially adding a multiplication factor of three would be very similar (though not quite as radical) to setting all files to very low priority and setting the one downloading file to release. In researching I actually found several people on the emule forums who claimed they did this to get more BT like behavior. So I could not see any complaints about it being a leeching/cheat scheme.
-
I would certainly check a patch if you could provide one. I don't promise anything in advance, we can talk about it after the patch is ready.
-
I would certainly check a patch if you could provide one. I don't promise anything in advance, we can talk about it after the patch is ready.
Ok, awesome! I will see what I can do. No promises here either as It's been a while for me coding anything but it seems relatively simple once I understand the code base.