Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nachbarnebenan]

The following have been on my list for quite some time. Since I don't have any programming skills (yet), I don't know if they are easy, difficult or even impossible to implement. Some of them might even be in already.

* randomize downloads; when requesting a part to download, choose the one with the fewest sources (out of the parts the peer has of course); if there is more than one with the same amount, choose randomly; this _could_ improve spreading of files
* non-exclusive friend-upload slot/part-time friend upload slot; this behaves just like a normal upload slot, until a friend want's to downlaod from you; when the download starts, the slots stays locked for your friends, until they are done, then it returns to normal operation
* scanning of shared files in regular intervalls, every 2h or something like that; if a shared file is not found, the scan is started instantly to prevent the upload from failing (dunno if the slot can be hold open long enough)
* a button or hotkey, which dumps the list of all shared files to the log or a specific file (for debug)
* dump the statistics to log or file every 24h (for debug)
* "force complete file upload"; one (or at least only very few) file(s) can be set to this, so if anyone (no matter if friend or not) starts downloading this file, he/she will keep the slot, until the file is done, no matter how many parts; this feature should be limited to one upload slot
* "soft shutdown"; server disconnect, no more sources are shared, no new part downloads are started (currently running ones are completed); no new uploads into the queue, but all waiting ones are finished; when everything is done, aMule closes
* files with high download priority can "steal" download bandwidth from low priority files, when given dl bandwidth limit is reached
* row "last seen complete" could get a color indicator: red: never seen complete; orange: seen complete more than 7 days ago; light blue: seen complete less than 7 days ago; dark blue: less than 1 days ago; green: all parts are available at the moment; white (simply no text): file completed

That's all for the moment. Please comment on this.

[nachbarnebenan]

> * randomize downloads; when requesting a part to download, choose the one with the fewest sources (out of the parts the peer has of course); if there is
> more than one with the same amount, choose randomly; this _could_ improve spreading of files

* Of course, first priority are already started parts (since only completed ones can be shared).
* always upload 9.28MB to a peer, no matter how many parts are affected (I believe, this is already the case)
* maybe an command line option to set the listening port could be useful, especially when debugging, so you don't have to edit .eMule every time. Something like "--port xy".

[Kry]

/me taking notes

[nachbarnebenan]

> maybe an command line option to set the listening port could be useful, especially when debugging, so you don't have to edit .eMule every time. Something like "--port xy".

while we are at it, maybe it's easier to just have "--config-file aMule-2.config" or so. Whith this, no only the port but everything (dl/tmp dirs, shared dirs) can be set.

If you have an empty adresses.dat (or it is missing) aMule displays a message box and waits for the user to close it. When you run aMule from a script, maybe even in a VNC (as I do), it won't start right away but wait and wait and wait... until the user notices the missing bandwidth usage.

Two more suggestions from my daily work with aMule:
* if the given upload limit cannot be saturized with the active upload in an intervall of maybe 90s, add temporary upload slots to prevent waste of bandwidth capacity; the number of temporary slots should be limited to not more than those of normal slots, to prevent DoS attacks;
this could prevent the very common situation, where you get a bunch of modem-users who can't dl more than 1 or 2k/s and most of your bandwidth goes to waste instead of being used for the several hundred people waiting in your queue. Manual adjusting the number of upload slots every few hours is not reasonable.
* companion files; it's hard to explain and I don't know if is is even possible or will hurt more than help, but let's assume someone just downloaded one of the 700MB debian isos from you and now want's the accompaning gpg-signed md5 file for it. Even if it is set to PowerShare (like I do for all this files), he will have to wait in the queue, probably days before getting the file and verifying the iso. by grouping the gpg- with the iso-file, he will keep the upload slot to get this second file too, even when the 9.28MB limit is already reached. of course, this should be limited to very small files, probably <1kb or so.
and, as already told, I don't know whether this will help or make it worse

[t0xrico]

i think about one thing that could be improved, a fonction that i only saw in the emule mod LSD, it is the "Save sources/Load Sources" buttons above the "file transfer" list ; IMO it's a great tool to help sarting a "session" !