Upload speed limiting patch...
Moderator: Moderators
Upload speed limiting patch...
Loved the upload speed limiting patch on DC++ 0.18 cause it meant our whole flat could still use the internet like it would be if we weren't leeching hardcore. However, with the newer verisons of DC++ there seems to be no speed limiting patches around and you need to have the newer software to connect to some of the hubs. I have spent a couple of hours looking around for a solution but can't find anything. Can anyone help?? Can something be added into the code like it could for version 0.18??
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
You can ry to download a mod like DC++k, it supports upload speed limiting.
-
- Posts: 184
- Joined: 2003-05-26 11:29
- Location: UK
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
re
Yes mate , l understand what you are saying , but people will put the brakes on hard , thinking that its going to give them more dl speed the harder the brakes are on , this will result in a dog slow system over all ,
not that its super fast now , but some speed is still there on some connections , but these tools will in time stop that , maybe , maybe not , l just think they are to easy to abuse , after all DC is about sharing and not just one way traffic .
Rod
not that its super fast now , but some speed is still there on some connections , but these tools will in time stop that , maybe , maybe not , l just think they are to easy to abuse , after all DC is about sharing and not just one way traffic .
Rod
-
- Forum Moderator
- Posts: 1420
- Joined: 2003-04-22 14:37
Re: re
Hence the reason why arne will not include this feature in the DC++ client.Roadblock wrote:l just think they are to easy to abuse
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: re
And why BCDC and DC++k are so popular.TheParanoidOne wrote:Hence the reason why arne will not include this feature in the DC++ client.Roadblock wrote:l just think they are to easy to abuse
Face it, limiting uploads is about the least destructive behavior you can enage in in the DC protocol. There are many other ways to abuse the system. Search for the "Ratings System" threads for ideas on how that might be fixed.
Re: re
This is the biggest problem IMO! ppl that don't know how to use the UL limiting correctly. It's not a question of "abusing" or trying to "cheat", they simply don't know better.Roadblock wrote:but people will put the brakes on hard , thinking that its going to give them more dl speed the harder the brakes are on
A automatic UL limiting system should be implemented, some feature that cuts down the uploads a few kB and fixes the ADSL problem!
There are so many experienced developers working in DC++, surely you must be able to work out some solution to prioritize the acks. *wink wink*
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: re
Actually, I'm fairly certain it is out of our hands. The system I have coded IS the current upload throttling code. It works well for intelligent users. If users cannot be bothered to understand it properly (or read the units in which they're throttling) it's not my problem. I am not going to go wasting my time just to have some clever idiot come along and show me yet another way the stupid can defeat my overly elaborate code...cyberal wrote:There are so many experienced developers working in DC++, surely you must be able to work out some solution to prioritize the acks. *wink wink*
A discussion repeated over and over again
This discussion about possible upload limiting has been going on for years!
I was once moderator at the official eDonkey2000 forum (and Overnet at it's early start, plus the official Danish eD forum), and there we came to the conclusion that some up-load limiting would be benificial for most users, and we just had to live with the foolish leechers, whom would just use a modded version anyway.
The solution implemented by Overnet, eDonkey2000, eMule and others are infact working: Up to a 10Kb/s ´the d/l speed is limited, but >=10K it's not.
- The values has been choosen to let all the users with +256/128kbps xDSL and cable connections use the network, and still force them to share at least some of the files.
I've been using DC++ for about a year, only connecting to a private hub, and as long as I can't limit the u/l I won't expand my use of the network.
- The reason for this is I am using another filesharing program (eMule), and I want to be sure I have enough bandwith free for video-chat, gaming, voice-chat, my ftp-server and http-server.
Futhermore I do know several others who just won't use DC++, because they don't want to be bothered by having to shut it down, whenever they need the bandwith for something else.
Thus the discussion should be about what kind of users is wanted, and not wether or not a u/l limit option will be misused by leechers.
PS. For my use a thirdparty controlling app. would be perfect, for controlling the bandwith-usage dynamic, based on my personal priorities
I was once moderator at the official eDonkey2000 forum (and Overnet at it's early start, plus the official Danish eD forum), and there we came to the conclusion that some up-load limiting would be benificial for most users, and we just had to live with the foolish leechers, whom would just use a modded version anyway.
The solution implemented by Overnet, eDonkey2000, eMule and others are infact working: Up to a 10Kb/s ´the d/l speed is limited, but >=10K it's not.
- The values has been choosen to let all the users with +256/128kbps xDSL and cable connections use the network, and still force them to share at least some of the files.
I've been using DC++ for about a year, only connecting to a private hub, and as long as I can't limit the u/l I won't expand my use of the network.
- The reason for this is I am using another filesharing program (eMule), and I want to be sure I have enough bandwith free for video-chat, gaming, voice-chat, my ftp-server and http-server.
Futhermore I do know several others who just won't use DC++, because they don't want to be bothered by having to shut it down, whenever they need the bandwith for something else.
Thus the discussion should be about what kind of users is wanted, and not wether or not a u/l limit option will be misused by leechers.
PS. For my use a thirdparty controlling app. would be perfect, for controlling the bandwith-usage dynamic, based on my personal priorities
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
Re: A discussion repeated over and over again
Why not download netlimiter? With it you can limit uploads and dowloads for any specific program.Snoozer wrote:I've been using DC++ for about a year, only connecting to a private hub, and as long as I can't limit the u/l I won't expand my use of the network.
Automatic speed limiting
The best way to do speed limits is to make automatic speed limiting which will balance upload and download to approx. same speed.
It will be hard to code, because it must have some inteligence, so it will not waste the bandwidth. The only thing the user will set will be the maximum combined speed.
It will be hard to code, because it must have some inteligence, so it will not waste the bandwidth. The only thing the user will set will be the maximum combined speed.
Re: Automatic speed limiting
There are alot of 512/128k and 1MB/128k so you can't really balance the two on all connections.Let_Me_Be wrote:The best way to do speed limits is to make automatic speed limiting which will balance upload and download to approx. same speed.
It will be hard to code, because it must have some inteligence, so it will not waste the bandwidth. The only thing the user will set will be the maximum combined speed.
The starter of this thread need bandwidth limiting to make sure all users of his connection has some bandwidth, for this I think netlimiter is the best (althought it seems some what buggy, sometimes corrupting data).
The other reason to have UL limiting, to solve the problems with the Asymetric DSL connections would not exist if we could prioritize ack packets. I belive the linux app WonderShaper does just that, is there something like it for win?
The other reason to have UL limiting, to solve the problems with the Asymetric DSL connections would not exist if we could prioritize ack packets. I belive the linux app WonderShaper does just that, is there something like it for win?
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
I've now tried out Netlimiter for a couple of days now, and to my experience it is more like constantly producing corupted data, both for up and downstream transfercyberal wrote:The starter of this thread need bandwidth limiting to make sure all users of his connection has some bandwidth, for this I think netlimiter is the best (althought it seems some what buggy, sometimes corrupting data).
No, and I don't even think MS believes it might be a problem, so this kindda control/prioriticing feature isn't implemented in any of their workstation products (dunno about the specialized server OS).cyberal wrote:The other reason to have UL limiting, to solve the problems with the Asymetric DSL connections would not exist if we could prioritize ack packets. I belive the linux app WonderShaper does just that, is there something like it for win?
I have taken notice to a mod solution for eMule called ZZUL, and it actually tries to make the UL dynamic.
If this solution can be adapted by DC++, it might be the solution for both ack packet jam, and need for using other apps, beside DC++?ZZ UploadSpeedSense: Automatically finds the best upload speed for your connection!ZZUL now works right out of the box, without need for configuration of upload speed. Just set the upload speed limit to 0 (unlimited) in prefs and then relax. If you use other programs that wants bandwidth, ZZ UploadSpeedSense will automatically lower the upload limit for eMule while the other transfer is going on. When the transfer is done, ZZ UploadSpeedSense raises the upload limit back to normal speed. ZZ UploadSpeedSense will not work for multihomed hosts. UploadSpeedSense is based on the DynUp idea, and in fact uses a few lines of code from DynUp.
the fact that uploading slows downloads to a crawl may be one of the most beneficial (although unintentional) aspects of the network. think about it- most download connections are capped at 2-4 times the upload connection. If these speeds were realized, it would be impossible to download at all because everyone would be sucking data four times as fast as they were serving it.
daven wrote:the fact that uploading slows downloads to a crawl may be one of the most beneficial (although unintentional) aspects of the network. think about it- most download connections are capped at 2-4 times the upload connection. If these speeds were realized, it would be impossible to download at all because everyone would be sucking data four times as fast as they were serving it.
the faster the transfer will end the faster you will have a chance to have a slot.
keep in minds, that the file you want, might be from the same one he is downloading, and not actualy dl from him.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: A discussion repeated over and over again
This is the model that I initially went with when coding the upload limiting code... BCDC++ uses a similar ratio system, and I think DC++k might as well.Snoozer wrote:The solution implemented by Overnet, eDonkey2000, eMule and others are infact working: Up to a 10Kb/s ´the d/l speed is limited, but >=10K it's not.
You can limit speeds on clients using the DC++ source base, and you've been able to for a year or so (as far back as my usage of the program extends).I've been using DC++ for about a year, only connecting to a private hub, and as long as I can't limit the u/l I won't expand my use of the network.
Or... informing users that they already have several choices (all using the same code) for limiting uploads, since Arne - the DC++ head honcho - has made it pretty clear that upload/download limiting is not going into DC++ any time soon.Thus the discussion should be about what kind of users is wanted, and not wether or not a u/l limit option will be misused by leechers.
What about the AMUC feature in one of the eMule mods? It wasn't clearly documented when I tried to investigate it, but if I could get more information on it, I might amend my upload limiting patches/PS. For my use a thirdparty controlling app. would be perfect, for controlling the bandwith-usage dynamic, based on my personal priorities
Case in point.
I have a line with approximately 300KB/s bandwidth.
I am currently running 1 download at approx 70KB/s, and there is a couple uploads at around 5-10KB/s each.
Now, somebody connects to me and starts to download with 200KB/sec, and I watch his speed growing!
Soon enough he is d/loading at 280KB/s and the rest of uploads and downloads have slowed down to around 2KB/s each.
That does not sound very balanced to me. If I disconnect the fast uploader, I can see the rest of my U/Ds growing back to their old values.
I would say, that the mechanism for calculating allowed speeds should take into account the number of U/Ds going on and make it so that the total speed of uploads is not taking the bandwidth from downloads, IF it is already faster than downloads. And the other way round.
Not sure if it is possible to implement , but perhaps some analysis of speeds might take place -- if we give this U or D more bandwidth, do others drop in speed?
I have a line with approximately 300KB/s bandwidth.
I am currently running 1 download at approx 70KB/s, and there is a couple uploads at around 5-10KB/s each.
Now, somebody connects to me and starts to download with 200KB/sec, and I watch his speed growing!
Soon enough he is d/loading at 280KB/s and the rest of uploads and downloads have slowed down to around 2KB/s each.
That does not sound very balanced to me. If I disconnect the fast uploader, I can see the rest of my U/Ds growing back to their old values.
I would say, that the mechanism for calculating allowed speeds should take into account the number of U/Ds going on and make it so that the total speed of uploads is not taking the bandwidth from downloads, IF it is already faster than downloads. And the other way round.
Not sure if it is possible to implement , but perhaps some analysis of speeds might take place -- if we give this U or D more bandwidth, do others drop in speed?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
NetLimiter does work...
Well I have been using the NetLimiter (version 1.22 now) and have had no problems with it. I believe that the earliest beta versions have had some problems with corruption but none any longer. I actually liked it so much I bought it (I also sent some money to Arne via PayPal...). There are of course million other reasons why packets could suddenly be getting corrupted - one of them being the firewall.
I suppose that the topic of uplimiting has been debated to death. I use netlimiter because it is undetectable. Many hubs ban uplimiting versions of the DC++ on sight. I suppose it is a good thing. I use the netlimiter to turn a university department 10 Mbit LAN connection into a 1500/500 DSL connection and also advertice it as a DSL connection (I don't want to clog up the network too much). Of course the fact that there is so much spare capacity in the network could help packet integrity - I am no expert on that.
The only problems that I have had are related to the so called 100% CPU problem. Every so often one download some how jams and DC++ uses 99% of my 2.8GHz pentium 4 processor. All network traffic also stops immediately (upload/download). The problem goes away when the offending download is terminated (for some reason it is always a download - and a pretty speedy one at that) or terminates itself. So this could have something to do with netlimiter or it is some obscure bug in the program itself. Since other people have been complaining about it as well I suppose it could be a bug in the program. It happens pretty rarely so I am not really complaining. I suspect that maybe there is a problem in the connectÃÂon and the program is constantly reguesting a re-do of the download and gets jammed - don't know. This however does not cause a corrupted file.
By the way I am using Win XP with all updates and a 3Com 100 Mbit network card. I have 1 Gb of memory.
I suppose that the topic of uplimiting has been debated to death. I use netlimiter because it is undetectable. Many hubs ban uplimiting versions of the DC++ on sight. I suppose it is a good thing. I use the netlimiter to turn a university department 10 Mbit LAN connection into a 1500/500 DSL connection and also advertice it as a DSL connection (I don't want to clog up the network too much). Of course the fact that there is so much spare capacity in the network could help packet integrity - I am no expert on that.
The only problems that I have had are related to the so called 100% CPU problem. Every so often one download some how jams and DC++ uses 99% of my 2.8GHz pentium 4 processor. All network traffic also stops immediately (upload/download). The problem goes away when the offending download is terminated (for some reason it is always a download - and a pretty speedy one at that) or terminates itself. So this could have something to do with netlimiter or it is some obscure bug in the program itself. Since other people have been complaining about it as well I suppose it could be a bug in the program. It happens pretty rarely so I am not really complaining. I suspect that maybe there is a problem in the connectÃÂon and the program is constantly reguesting a re-do of the download and gets jammed - don't know. This however does not cause a corrupted file.
By the way I am using Win XP with all updates and a 3Com 100 Mbit network card. I have 1 Gb of memory.
-
- Forum Moderator
- Posts: 587
- Joined: 2003-05-07 02:38
- Location: Sweden, Linkoping
-
- Posts: 3
- Joined: 2003-11-15 16:35
I think this is a serious issue that needs attention, quite frankly. Consider, I get about 15K in upload with my cable connection. As I am sharing nearly 50GB (and growing every day), my slots are constantly full and my upload bandwidth pegged.
The problem, of course, is that the rest of my Internet connection is useless. Requests for web pages take 20-30 seconds to go through. SSH connections are useless - it's 5 to 10 seconds to get a character through. Hell, I can't even keep up in DC chat because it takes so long to get data out.
The end result is I don't share unless I'm downloading. When my downloads complete I close the client. If I could cap uploads @ 10K collectively, leaving 5K available for my personal use, I'd leave DC++ open 24/7 and more people would be able to download from me. But I won't make my $70/month Internet connection useless.
Netlimiter sounds great, but it doesn't solve the problem of the DC chat being bogged down, not to mention it's $30 and from what I hear, it's a bit buggy. I'd rather donate the $30 to the DC++ developers to get solid upload limiting built in. As was already stated, using a hacked client will get you banned from most hubs, so that's out.
I propose the following:
1. Allow users to set any limit on uploads and downloads. Don't tie one to the other, or otherwise try to come up with some scheme to force people to share. You can't do that. If someone doesn't want to play fair, they'll find an easy way around your limits. Meanwhile the rest of us have to suffer with restrictions that may not apply to our situation. Why cap my downloads just because I choose to cap my uploads? I've got plenty of downstream bandwidth. It's just the upstream I'm short on.
2. Leave the default installation settings as "unlimited" in both directions (all bandwidth limiting turned off). That way people who don't know or don't care will automatically play fair.
3. Here's how you solve the fairness problem: Include a simple function that will allow anyone (ops, bots, dc hubs, other users) to obtain your current upload speed settings. You can build it right into whatever function tells them how many slots a user has open. Then hubs can place restrictions on people ("10KB minimum upload") like they currently do with hub/slot & sharing ratios. Then if I log into a hub with my uploads capped at 1KB, they can kick me right back off (as they should).
Essentially, my argument is: Put bandwidth limiting in place and make the settings available to others. Let the hub owners decide what is fair, rather than trying to build some elaborate "fairness" mechanism into DC++.
The problem, of course, is that the rest of my Internet connection is useless. Requests for web pages take 20-30 seconds to go through. SSH connections are useless - it's 5 to 10 seconds to get a character through. Hell, I can't even keep up in DC chat because it takes so long to get data out.
The end result is I don't share unless I'm downloading. When my downloads complete I close the client. If I could cap uploads @ 10K collectively, leaving 5K available for my personal use, I'd leave DC++ open 24/7 and more people would be able to download from me. But I won't make my $70/month Internet connection useless.
Netlimiter sounds great, but it doesn't solve the problem of the DC chat being bogged down, not to mention it's $30 and from what I hear, it's a bit buggy. I'd rather donate the $30 to the DC++ developers to get solid upload limiting built in. As was already stated, using a hacked client will get you banned from most hubs, so that's out.
I propose the following:
1. Allow users to set any limit on uploads and downloads. Don't tie one to the other, or otherwise try to come up with some scheme to force people to share. You can't do that. If someone doesn't want to play fair, they'll find an easy way around your limits. Meanwhile the rest of us have to suffer with restrictions that may not apply to our situation. Why cap my downloads just because I choose to cap my uploads? I've got plenty of downstream bandwidth. It's just the upstream I'm short on.
2. Leave the default installation settings as "unlimited" in both directions (all bandwidth limiting turned off). That way people who don't know or don't care will automatically play fair.
3. Here's how you solve the fairness problem: Include a simple function that will allow anyone (ops, bots, dc hubs, other users) to obtain your current upload speed settings. You can build it right into whatever function tells them how many slots a user has open. Then hubs can place restrictions on people ("10KB minimum upload") like they currently do with hub/slot & sharing ratios. Then if I log into a hub with my uploads capped at 1KB, they can kick me right back off (as they should).
Essentially, my argument is: Put bandwidth limiting in place and make the settings available to others. Let the hub owners decide what is fair, rather than trying to build some elaborate "fairness" mechanism into DC++.
-AR
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Ever since I started using DC++ a year ago at 0.181, there have been limiting solutions. Alyandon's was the first I used, then I adopted the code from DC++k. BCDC and DC++k both have limiting features... Please, use a client with limiting, it will not be added to DC++ properalternatereality wrote:The end result is I don't share unless I'm downloading. When my downloads complete I close the client.
Indeed, this is the most popular way to handle the situation - linking upload and download limits. And people will potentially find a way around them, if they have access to a compiler and some knowlege about C++.1. Allow users to set any limit on uploads and downloads. Don't tie one to the other, or otherwise try to come up with some scheme to force people to share. You can't do that. If someone doesn't want to play fair, they'll find an easy way around your limits.
I don't understand how this jives with your "they will find a way around your protection scheme" statement above.3. Here's how you solve the fairness problem: Include a simple function that will allow anyone (ops, bots, dc hubs, other users) to obtain your current upload speed settings.
You cannot convince me, I'm in favor of users limiting however they want, and eventually using a ratings system to reward people who upload a lot. However, your argument seems to have a pretty big hole in it. :-/
-
- Posts: 3
- Joined: 2003-11-15 16:35
Would love to, but don't want to get banned from my favorite hubs for running a "hacked client". Are BCDC or DC++k generally considered to be 'hacked clients" in the DC community, or are they respected?Please, use a client with limiting
Simple, it moves the decision from the client to the server. If you force speed sharing ratios within the client, people will use another means to limit their bandwidth. And I'm not thinking rewriting the code - they'll just tell DC to not limit anything, and use Netlimiter, etc, to do what they want. End result, the people who want to "cheat" still do, and you just annoy those of us who will use speed limiting properly.I don't understand how this jives with your "they will find a way around your protection scheme" statement above.
Instead, let the users do whatever they want, and the hub operators can decide what is acceptable on their server. No, providing a query of your settings to the hubs isn't foolproof, but it helps. The slot reporting seems to work well, so there's no reason this can't.
I like your idea of a ratings system, though I don't think it works within the client. Individual hubs should store the data, otherwise, it is trivial to cheat the system. Yes, this means you would have different ratings on different hubs, but it would keep people from artificially inflating their ratings. Small price to pay for the security of knowing the data is (probably) valid.
(Edit: fixed quote tag - GargoyleMT)
-AR
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Well, anything other than DC++ itself is probably considered hacked by some people. BCDC has emulation modes precisely for this.alternatereality wrote:Would love to, but don't want to get banned from my favorite hubs for running a "hacked client". Are BCDC or DC++k generally considered to be 'hacked clients" in the DC community, or are they respected?
When limiting clients want to say that they're limiting, they report it with a B: L: or U: addition to their ++ tag. I think this is pretty much what you're asking for... (Perhaps it's not hidden deeply enough, but it is a basic sanity check and reporting facility.)No, providing a query of your settings to the hubs isn't foolproof, but it helps. The slot reporting seems to work well, so there's no reason this can't.
Well, the flip side is: do you want the hub to know about each transfer? A karma system in the client works well for eMule, though it might not be as accurate/nice as one inside a DC++ client - since there are typically more and shorter transfers in eMule than in DC++ (since they're servince file fragment, instead of the whole file, or a directory of files). I'll have to more properly revisit the ratings system threads later, but neither sarf nor volkris seem to be active in the forum right now.I like your idea of a ratings system, though I don't think it works within the client. Individual hubs should store the data, otherwise, it is trivial to cheat the system. Yes, this means you would have different ratings on different hubs, but it would keep people from artificially inflating their ratings. Small price to pay for the security of knowing the data is (probably) valid.
This topic is getting old and nothing seems to ever push it in either direction. But i'm going to put in my 2 cents because i can.
The biggest argument for integrating a speed limiter is that any one who wants to do it will just install netlimiter. If DC++ were to integrate it and put restrictions on it such as the ones listed above (displaying limit in tag and having servers set their requirements) it would be much "fairer" to it's users.
I personally have stopped contributing to the public hubs and now only go to a few private ones that I either host (and there fore don't kick for BCDC++ and it's limiter) or the host themselves doesn't care about speed limiters.
The only time I find it usefull to place a cap on my uploads is when i want to go play a game. I personally have a 32KB upload and cap it to 20KB when i want to go play a game or need the connection for something else. People give me the arguement that i should just close the client all togather. Why? if i leave it going at a slightly slower speed the file will still get to you sooner then it would if i were to take all of my bandwidth away by leaving.
Being able to throttle has alowed me to be on 3 private hubs who understand the values of throtteling 24/7 for the last 4 months. Uploading over 500GB.
If some one wants to be a leech they are going to be a leech there is no stopping that. The only thing you have done by making upload throtteling a "hacked" feature is make them work a little harder and force honest users who cap for a legitimate reason to hide off in the private hubs where they arn't shunned for trying to contribute 24/7.
The biggest argument for integrating a speed limiter is that any one who wants to do it will just install netlimiter. If DC++ were to integrate it and put restrictions on it such as the ones listed above (displaying limit in tag and having servers set their requirements) it would be much "fairer" to it's users.
I personally have stopped contributing to the public hubs and now only go to a few private ones that I either host (and there fore don't kick for BCDC++ and it's limiter) or the host themselves doesn't care about speed limiters.
The only time I find it usefull to place a cap on my uploads is when i want to go play a game. I personally have a 32KB upload and cap it to 20KB when i want to go play a game or need the connection for something else. People give me the arguement that i should just close the client all togather. Why? if i leave it going at a slightly slower speed the file will still get to you sooner then it would if i were to take all of my bandwidth away by leaving.
Being able to throttle has alowed me to be on 3 private hubs who understand the values of throtteling 24/7 for the last 4 months. Uploading over 500GB.
If some one wants to be a leech they are going to be a leech there is no stopping that. The only thing you have done by making upload throtteling a "hacked" feature is make them work a little harder and force honest users who cap for a legitimate reason to hide off in the private hubs where they arn't shunned for trying to contribute 24/7.
-
- Posts: 3
- Joined: 2003-11-15 16:35
Thank you. My point exactly.The only thing you have done by making upload throtteling a "hacked" feature is make them work a little harder and force honest users who cap for a legitimate reason to hide off in the private hubs where they arn't shunned for trying to contribute 24/7.
I switched to BCDC. I've since been banned from a major sci-fi hub because the powers that be have their heads too far up their asses to understand this simple equation: Let me set a reasonable limit and I'll share 24/7. Otherwise, I'm downloading what I need and turning the client off immediately afterward, everyone else who wants my files be damned. Sharing over 50G of high quality sci-fi and a polite email to the hub's owner did nothing to change the situation: I'm obviously a no good stinking leech.
So screw 'em. I'll keep using BCDC because it's the only way I can share and get any reasonable use out of my Internet connection at the same time. The idiots who can't understand this and insist on banning people like me will just miss out on accessing the half terabyte array I'm filling up.
-AR
and you dont supose that could be due to the >80 limit people having better connections?deadude32 wrote:You definatally need to be able to limit sharing while trying to do stuff. But if you put it as a simple feature in the setting dialogue people wil abuse it, look at how slow kazaa is.
another thing is funny how slow the <20GB limit hubs run vs. the >80 limit hubs.