| Summary: | It should be possible to set maximum speed of the ftp transfer | ||
|---|---|---|---|
| Product: | [Unmaintained] kio | Reporter: | krzyko |
| Component: | ftp | Assignee: | Thiago Macieira <thiago> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | adawit, alpha_one_x86, expendable.0, miguel |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | RedHat Enterprise Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
krzyko
2001-06-14 14:26:07 UTC
Yes please - or maybe a more generic implementation so that it could be applied to any kioslave? (Or at least any kioslave that pops up a 'progress' dialogue). Often I'm downloading some big bit of software (e.g. KDE 3.4!) and it uses all my bandwidth - which means I have to stop the transfer if someone rings me on Skype or if I want to ring out on VOIP, etc. Rather than stopping and restarting, it would be nice to be able to scale down the bandwidth. At the moment I "solve" this problem by opening up a terminal and using wget. Maybe the kio dialogue could have a little link text "reduce" next to where it shows the current speed. The kio dialogue could remember the maximum speed so far attained - and when you click on "reduce" it would bring up a little window with a little slider where you could select a smaller speed. Obviously it's not just the dialogue, but the underlying kio process, which needs somehow to be able to control its speed.... is that difficult? Presumably it can be done somewhere in the shared code, with micro-sleeps?!? Or would every kioslave have to be hacked? (I'm no expert here!). I'm sorry, but if you run bandwidth sensitive applications, you should add QoS rules to your network. To not do so would be a grave problem on your part. This does not negate the wish, though. But it doesn't make it any more a priority. < dfaure> thiago: for 27212 - if wget can do it, shouldn't we be able to do it too, in a similar way? :/ Yes, we can do it. I meant that having bandwidth limiter in our FTP, or in all kioslaves, doesn't mean a proper QoS isn't necessary for bandwidth-sensitive applications. Therefore, it isn't an argument for implementing it. Reassigning to myself. You're right, it's not a great example. A better example would be a common one that I have at work. The office shares 512kbps. Say I want to download a big bit of software via HTTP during the course of the day, but slowly so as not to slow down other users of HTTP (including myself). I can't use QoS to distinguish between one Konqueror download and another, so this would be a place where the feature would be useful in KDE. (As I say, currently I just drop down to the shell and wget). Of course, not everyone knows how to do QoS! e.g. Home networks with ADSL modems - not everyone's a network technician! My vote for it also. It's quite hard to implement QoS on a desktop computer connected directly to an ADSL modem or a simple wireless router. Bandwidth limiting would be great for <1Mbps connections used by more than one device, where downloading a file at full speed causes total network jam. Best idea, IMHO, would be to add a limiter slider to every kioslave download dialog. It would be also a good idea to support a global per-download limit in KDE Control Center. *** Bug 77932 has been marked as a duplicate of this bug. *** this seems very similar to https://bugs.kde.org/show_bug.cgi?id=134821 Same for all protocol via the KDE API (sftp, ftp, ...) for KDE 4.4 or more |