Bug 50776

This would be great; I suspect this is typically handled via
iptables (?) options in the kernel itself, but if kget could
either provide download throttling itself, or indicate how to
tweak the iptables options dynamically, or even just document
how to tweak the iptables, that would help a bunch.

*** Bug 55467 has been marked as a duplicate of this bug. ***

By the way, d4x provides you with 3 bandwidth 'quick' selection buttons, plus (I
believe) a way to specify a bandwidth with a smaller granularity.  Not the same
as dynamic bandwidth use via priority ordering, but something that might provide
a manual stopgap. 

Either being able to limit the download speed and making kget use the unused bandwith are good ideas.  I'm for now using d4x when I don't want the full bandwith to be used...

I've searched for the same feature, and found the following tool:
http://monkey.org/~marius/pages/?page=trickle
Basically it allows to shape/limit the traffic of every application. It would
be great, if KDE would do this automatically for programs using KDE's
framework, and provide a trickle-like tool, to shape non-KDE programs. (as has
been done for arts: artsdsp).
The optimum would be a window, where I could tune the bandwidth for every
PID/program (hierarchically?), and en/disable shaping for each of them.

Why not go another step forward and put a "priority" value for each file being downloaded? Sometimes I'm downloading a big file that doesn't needs to be used right now and it's throttling down another smaller file that I need NOW. Maybe a priority a-la mldonkey (very high, high, normal, low, very low) could help.

a simple way of a user controlling kget's banwidth usage may be setting a lower & upper limit ...

obviously, kget could use no more than the upper limit ( of bandwidth availble to all applications ) ...

the lower limit means "if you need it, use at least this much, unless other applications are using it" ... 

the lower limit allows the user to browse at a reasonable speed, but makes sure the download of an important file isn't stopped completely by their browsing ...

the upper & lower limit could be set on a per session basis & optionally as a default for all future sesions ...

in addition, perhaps as an "advanced option", it would be nice to set a lower or upper limit for a specific file(s) as a percentage of the bandwidth available to kget ...  

a lower limit on an important file would prevent it being delayed by lots of other files ...

an upper limit on a big file would mean lots of little files would not be delayed ...

to prevent this feature becoming instrusive, the user doesn't have to set a limit on each files, unless they chose to ...

*** Bug 88823 has been marked as a duplicate of this bug. ***

AFAIK kget uses wget as a backend, so both teams should work together in this one, maybe the kde people would contribute some enhancements to wget? wget should have the possibility to limit is bandwidth, and to receive commands on-the-fly to alter its priorities.
Brainstorming:
We would have a .wget directory at home folder, with global settings (.wget/global.wget), and per-instance settings for each download (sourceurl.wget). 
valid values would be like this:
xxxx <MB|Mb|KB|Kb|B|b|%> (per second, default bits per second - bps)
available options could include (but not limited to):
upload speed = (% not valid)
download speed = (% not valid)
upper limit = 
lower limit = 
max simultaneous downloads = (global.wget only)

The several wget instances would have to be able to communicate with each other   and coordintate themselves, like placing themselves 'on hold' if past the 'max simultaneous downloads' setting.

This wishlist is here since 2002, it has collected 1060 votes, still the developers don't seem to be interested. It's a pity.

This feature is interesting indeed. Some download managers have different options to shape the traffic - d4x, as it was mentioned earlier, has 3 modes - unlimited, medium speed and low speed (speed limits for the last two can be set in the config). A long ago, when I was using widows, I saw a program that allowed to set DL limits on-the-fly using a trackbar placed below the queue window. Creating something like that in kget would make it more handy to use (especially for those who have low bandwidth).

Please be patient.

I wrote this wish several years ago becouse I thought it was a really great idea. In those days I didn't have a lot of programming experience.
Now I'm developing the make_kget_cool branch, but there is still lots of work to do before we start adding these super cool features.

This wish isn't really very easy to implement properly (I mean, not like a hack).

It requires, in my vision, lots of things:
1) a clean and versatile architecture
2) a good abstraction of the concept of "transfer"
3) transfers available as plugins
4) transfer plugins that can handle commands such as "limit your speed at xx kbyte/s". Note that we need *all* the transfer plugins with these capabilities.
5) a bandwidth manager

When I started my work on the new kget architecture (make_kget_cool branch) I kept well in mind my wish and so I can say that, up to now, the points 1), 2) and 3) are nearly finished.

The problem is that we now have only two plugins, one based on the kde kioslaves (that can't support bandwidth management) and a bittorrent one (and this, with a few modifies, should be ok).

So what slows us down with this feature is mostly the availability of very good plugins.

If someone wants to help with this, feel free to contact us at kget@kde.org.

Best regards,
   Dario

On Monday 07 November 2005 19:37, Gleb Litvjak wrote:
> This feature is interesting indeed. Some download managers have different
> options to shape the traffic - d4x, as it was mentioned earlier, has 3
> modes - unlimited, medium speed and low speed (speed limits for the last
> two can be set in the config). A long ago, when I was using widows, I saw a
> program that allowed to set DL limits on-the-fly using a trackbar placed
> below the queue window. Creating something like that in kget would make it
> more handy to use (especially for those who have low bandwidth).


BTW, "wget --limit-rate=500" downloads at 500 bytes per second and the effect 
on my 28K connection is not perceiveable even when working over an SSH 
connection contending for the same bandwidth.  1 KB/s is perceivable however.

I can't wait to see this work in kget :)

For me, the "killer" feature of kget is the fact that it supports kioslaves, thus practically supporting every kind of download that konqueror understands (and some of them cannot be found in other download managers). Unfortunately, its lack of bandwidth management is a serious drawback -- for now, I just pause or stop/start downloads manually when they eat up all my bandwidth...

After reading the comments above, here is my perspective on this issue: 

From comment #11, it seems unrealistic to wait for kioslaves to support bandwidth management, thus this enhancement could, for the most part, be considered impossible.

On the other hand, implementing *global* bandwidth management (much like the wget option mentioned in comment #12 or the program Trickle, mentioned in comment #5) seems much more realistic to me, since many similar programs already implement it. Thus, I would suggest that this feature be implemented first, while the fancy per-download bandwidth management options be left for the future.

actually Trickle is not just a 'global' solution. If every download (or plugin) would be started in its own Trickle environment it should be possible to manage their bandwidth. If a plugin is responsible for more than one download (for instance a bittorrent plugin), the plugin itself should of course manage the bandwidth of the assigned downloads.
It might be easier to implement this feature at lower levels. If all KDE programs open their network connection using a KDE library (which is AFAIK the case), the bandwidth-management could be done at this level. KGet (and or other programs) could than manage the bandwidth over an exposed interface.