upload speed limiter
Moderator: Moderators
upload speed limiter
hi there
there is only one reason why i'm not using the latest version of dc++: it's because, as i have a cable internet connection, i cannot limit my upload speed. my available bandwith is very low so every kilobyte is precious
right now i'm using a modified version of dc++ 0.18 that has an upload speed limiter only because when i run for example the new 0.241 version i can see that there are many new features, but it still hasn't the one that is more vital for those that have "slow" internet connections.
i still can't understand why there's an download speed limiter and somehow for all this time the upload speed limiter has been forgotten, but nevertheless keep improving this fantastic piece of software.
stay cool
there is only one reason why i'm not using the latest version of dc++: it's because, as i have a cable internet connection, i cannot limit my upload speed. my available bandwith is very low so every kilobyte is precious
right now i'm using a modified version of dc++ 0.18 that has an upload speed limiter only because when i run for example the new 0.241 version i can see that there are many new features, but it still hasn't the one that is more vital for those that have "slow" internet connections.
i still can't understand why there's an download speed limiter and somehow for all this time the upload speed limiter has been forgotten, but nevertheless keep improving this fantastic piece of software.
stay cool
-
- Posts: 80
- Joined: 2003-03-21 10:17
- Location: Concepcion, Chile.
Re: upload speed limiter
Uhm.... Forgotten? Ok, you didn't search, it's true, but, still... The reason the upload limiting is "forgotten" is because people have yet to figure out a way to ensure that such an option won't be abused. Not everyone WANTS to share you know... Those leechers who don't would just love to set maximum upload to 100B/s so people get so slowly from them that the downloads will probably just time out even. (Especially DSL users are known for this because with MOST dsl connections if your upload bandwidth is full it kills the download bandwidth, somehow mine is _mostly_ exempt from this.)rockteer wrote:i still can't understand why there's an download speed limiter and somehow for all this time the upload speed limiter has been forgotten, but nevertheless keep improving this fantastic piece of software.
stay cool
well, i realy didn't quite use the search button
but this is a vital subject.
as Nazo said, leechers are a gr8 pain in the ass! but in matter of control, i think that is not a valid reason to justify why the current version has not that feature.
here's why:
the "normal" dc++ version has a description like this: bla bla <++ V:0.2xx,M:A,H:2/0/0,S:3>
the 0.18 modified version that i already said that i'm using, has a little bit different layout: bla bla <++ V:0.18,M:A,H:1,S:3,L:25>
in that example, L:25 means that the user has an upload rate limiter activated in this case to 25 KBp/s. this way any hub operator/bot has total control of how each user configure it's client. the same way that checks about the passive/active mode, it also looks if the user has a limit that does not violate the hub rules. it's the most safe way to ensure no one will abuse.
you can download it here: http://www.ptunderground.net/soft/ULDCPlusPlus.rar this is NOT the official site, if it even exists (this time i searched for it!). sorry to use that link, but i didnt' find any better.
re-think about it. this is an important feature to include in the official dc++ client.
stay cool
but this is a vital subject.
as Nazo said, leechers are a gr8 pain in the ass! but in matter of control, i think that is not a valid reason to justify why the current version has not that feature.
here's why:
the "normal" dc++ version has a description like this: bla bla <++ V:0.2xx,M:A,H:2/0/0,S:3>
the 0.18 modified version that i already said that i'm using, has a little bit different layout: bla bla <++ V:0.18,M:A,H:1,S:3,L:25>
in that example, L:25 means that the user has an upload rate limiter activated in this case to 25 KBp/s. this way any hub operator/bot has total control of how each user configure it's client. the same way that checks about the passive/active mode, it also looks if the user has a limit that does not violate the hub rules. it's the most safe way to ensure no one will abuse.
you can download it here: http://www.ptunderground.net/soft/ULDCPlusPlus.rar this is NOT the official site, if it even exists (this time i searched for it!). sorry to use that link, but i didnt' find any better.
re-think about it. this is an important feature to include in the official dc++ client.
stay cool
Hrm, like that it's not TOO unreasonable of a suggestion. Of course, people will still make modified clients that will report that they have the upload limit set to 100000000000GB/s (j/k, they'd set a believable number) when in fact they have the limit set to 1KB/s or something crappy like that because that's just how these people do. Still, as I said in my other post, there's just not really very much you can do to stop people from doing that. When you have an opensource client, it just kind of automatically implies that someone out there will screw it up, so you just can't really take into consideration that people will do that too much when it comes to deciding what features to add. Besides, if you use an external limiting program, it reports nothing and they can still limit it to crappy speeds without anything being reported wrong, so such a thing being built in would increase the number of people who just simply use the built in thing and decrease the people using external stuff, which would slightly improve the number of people who just don't feel like bothering to cheat the thing.
well, you can't really say that because nothing is absolutely secure.
upload speed limitation feature is the best way to take full advantage of the internet connection, specialy the slow ones like mine. without it, all my upload speed would be conducted to one place only, afecting not only the download bandwith, but any other upload that i may make and, of course, my navigation over everything else.
of course using an external program i could get the very same result, but that is not the solution i, and every other good intentioned users want.
that's why being open source or not, hasn't implication on this. there will always be leechers violating software and every rules.
it's absolutely irrelevant having or not that feature on the program, because if anyone wants to hack it and modify it, will not have any big problem.
the 0.18 version that i use, as you all can prove, was modified and distributed by someone with good intentions. try to guess how many guys are around there with modified versions.... but for private use only...
there will be always leechers with many weird stuff to bypass problems.
software security is not a good argument. i hope that now your convinced
stay cool
upload speed limitation feature is the best way to take full advantage of the internet connection, specialy the slow ones like mine. without it, all my upload speed would be conducted to one place only, afecting not only the download bandwith, but any other upload that i may make and, of course, my navigation over everything else.
of course using an external program i could get the very same result, but that is not the solution i, and every other good intentioned users want.
that's why being open source or not, hasn't implication on this. there will always be leechers violating software and every rules.
it's absolutely irrelevant having or not that feature on the program, because if anyone wants to hack it and modify it, will not have any big problem.
the 0.18 version that i use, as you all can prove, was modified and distributed by someone with good intentions. try to guess how many guys are around there with modified versions.... but for private use only...
there will be always leechers with many weird stuff to bypass problems.
software security is not a good argument. i hope that now your convinced
stay cool
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Faking tags, especially on something that is undetectable (like upload limiting) is... easy. Regardless, once the code is in the mainstream client, anyone with sufficient knowledge can change it to suit their purposes. That's very likely why Arne has not adopted any of the existing upload/download throttling connections and fused a crude protection method into it. Amazingly enough, this is a problem that isn't solvable in 15 minutes by non-programmers in a forum thread... But keep trying.rockteer wrote:the 0.18 modified version that i already said that i'm using, has a little bit different layout: bla bla <++ V:0.18,M:A,H:1,S:3,L:25>
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Sure it is, the last 15 minutes leading up to the solution count!sarf wrote:Just to make another thing clear - this problem is not solvable in 15 minutes by programmers, either.
I never said total time.
Think outside the box... Or something.
Who says we are trying to solve problems in just 15 minutes? We are just trying to help every bit we can in the only way we can, which is to try to think of ideas that might help the programmers who are doing all the hard work have something to try doing. That is, after all, what a feature suggestion forum on an opensource project website is for. After all.
yeah very old topic to discuss. I asked once about this feature - i was answered "too many ways to abuse it" - I suggested capping my upload ability by 1-2kb to help stay my downloads alive - don't remember the answer. With my very shitty connection ~10/10 kb/s i was really crushed with people with faster connections.
As i can see nothing changed, too much fear of those leechers.. don't know why capping DO work on edonkey network, bittorent downloads with capping are also great.
Dc community is way less anonymous then edonkey one but fear is lot greater. I think that would be the same way like share/slot fakers - people report them - ban and see ya leecher.
really no way to import rules from edonkey network? capping ratios and so on?
fishaa
As i can see nothing changed, too much fear of those leechers.. don't know why capping DO work on edonkey network, bittorent downloads with capping are also great.
Dc community is way less anonymous then edonkey one but fear is lot greater. I think that would be the same way like share/slot fakers - people report them - ban and see ya leecher.
really no way to import rules from edonkey network? capping ratios and so on?
fishaa
-
- Posts: 36
- Joined: 2003-01-19 22:22
- Location: Rochester, NY, USA
- Contact:
The problem is already solved
Thanks to Sarf.
DC++K caps DL at 4 times the upload. And doesnt report it to the hub.
That's exactly the type of feature that needs to be implemented in dc++ by default, because even though i am on a fairly decent cable connection, at one point i was on DSL with UL capped at 12K. Once that 12K was full, i got no downloads. Shit would time out, or drop from 40K down to 3K. It was fucking ridiculous. And the number of people who are getting bootfucked by this problem isnt a minor number.
In order to make sure that you can download from one more person at a decent rate, you've effectively completely fucked up people's entire connections. I dont see that as fair at all. I find it funny that the anti "rich get richer, poor get poorer" sentiment mentioned in the merit-based queueing thread is completely forgotten when this subject rolls around.
This isnt a small matter. People's experience on dc++ is complete hell if they have a DSL connection with a small UL cap. And rather than help them, they're being pissed on so that those with fast connections can download even more stuff from more people.
Fuck that. These people are being FORCED to "cheat" just so they can download. That isn't a good system in my book...
DC++K caps DL at 4 times the upload. And doesnt report it to the hub.
That's exactly the type of feature that needs to be implemented in dc++ by default, because even though i am on a fairly decent cable connection, at one point i was on DSL with UL capped at 12K. Once that 12K was full, i got no downloads. Shit would time out, or drop from 40K down to 3K. It was fucking ridiculous. And the number of people who are getting bootfucked by this problem isnt a minor number.
In order to make sure that you can download from one more person at a decent rate, you've effectively completely fucked up people's entire connections. I dont see that as fair at all. I find it funny that the anti "rich get richer, poor get poorer" sentiment mentioned in the merit-based queueing thread is completely forgotten when this subject rolls around.
This isnt a small matter. People's experience on dc++ is complete hell if they have a DSL connection with a small UL cap. And rather than help them, they're being pissed on so that those with fast connections can download even more stuff from more people.
Fuck that. These people are being FORCED to "cheat" just so they can download. That isn't a good system in my book...
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Well, anyone who comes looking for an upload modified client on the forum will be pointed at two: DC++k and BCDC.
Incidentally, I am a contributor to DC++ (I'm on the sourceforge project list), and I wrote the current generation of upload code that's in both clients.
However, DC++ is Arnetheduck's creation, and although I think there's a lot of merit in upload limiting (I couldn't live without it), you've got to respect his position on the matter.
Incidentally, I am a contributor to DC++ (I'm on the sourceforge project list), and I wrote the current generation of upload code that's in both clients.
However, DC++ is Arnetheduck's creation, and although I think there's a lot of merit in upload limiting (I couldn't live without it), you've got to respect his position on the matter.
From: http://sourceforge.net/tracker/index.ph ... tid=527768Date: 2002-12-31 15:16
Sender: arnetheduck
Logged In: YES
user_id=92266
Although it would be nice to be able to limit upload to x %,
it's not technically possible to know what maximum speed a
connection has to begin with...if your connection cannot
handle the load that dc++ puts on it with small send buffer
enabled, well, tough luck...complain with your ISP that they
have not balanced their systems correctly...btw, noone
seems to have any problems with saturating someone else's
connection to get what they're looking for faster...
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Which, frankly, sucks compared to the code in DC++k or BCDC. Plus, if you search the forum, you'll see people who had to uninstall it to get DC++ working properly again.Wisp wrote:well you can allways use www.netlimiter.com
that's fixed in the latest versionGargoyleMT wrote:Which, frankly, sucks compared to the code in DC++k or BCDC. Plus, if you search the forum, you'll see people who had to uninstall it to get DC++ working properly again.Wisp wrote:well you can allways use www.netlimiter.com
-
- Posts: 96
- Joined: 2003-04-18 05:57
- Location: Oporto, Portugal
- Contact:
About up-load limiting.
I think that it should exist but in another form.
Why not add an option in DC++ that permit reducing resources in it. Like in the tray icon we could chose using all bandwidth in dc++ (100%), 80% or 60%.
This should also reduce the download speed, even thou in generality users can download more than up-loading, but it would incentive users to use it always in 100% mode.
When we needed to use our bandwidth in other applications, we could use this option , and temporally reducing dc++ resources.
Is a suggestion…
Best regards
[PT]Devilishly
PS: Of course with netlimiter, this can also be done
I think that it should exist but in another form.
Why not add an option in DC++ that permit reducing resources in it. Like in the tray icon we could chose using all bandwidth in dc++ (100%), 80% or 60%.
This should also reduce the download speed, even thou in generality users can download more than up-loading, but it would incentive users to use it always in 100% mode.
When we needed to use our bandwidth in other applications, we could use this option , and temporally reducing dc++ resources.
Is a suggestion…
Best regards
[PT]Devilishly
PS: Of course with netlimiter, this can also be done
-
- Posts: 96
- Joined: 2003-04-18 05:57
- Location: Oporto, Portugal
- Contact:
Boas, fs é sempre bom encontrar por ká alguns Portugas
About that option in DC++K I really don’t know, because when I use that mod I usually don’t share anything…
Anyway if it’s “UP:DOWN� is 1:4, I think it should be more “UP:DOWN�= 1:1
This would work has an incentive to users using always all up-load bandwidth in DC++ and only in necessarily cases reduces its performance.
Best regards,
[PT]Devilishly
About that option in DC++K I really don’t know, because when I use that mod I usually don’t share anything…
Anyway if it’s “UP:DOWN� is 1:4, I think it should be more “UP:DOWN�= 1:1
This would work has an incentive to users using always all up-load bandwidth in DC++ and only in necessarily cases reduces its performance.
Best regards,
[PT]Devilishly
-
- Posts: 96
- Joined: 2003-04-18 05:57
- Location: Oporto, Portugal
- Contact:
Yes ender, that’s true… But what happens is that people associate up-load limiting feature as leacher feature, which isn’t necessarily true.
So with that kind of option every one knows you weren’t leaching…
May be 1:1 is a little bit to much, but if it would be done in % mode, like 100%, 80% and 60%, I think it would be more fair to everyone.
Has an example, if you are receiving in DC++ this values: Down: 270 KB/s;UP: 60 KB/s.
In 100% mode nothing would be done;
In 80% mode it would be: Down: 216 KB/s and UP: 48 KB/s;
In 60% mode it would be: Down: 162 KB/s and UP: 36 KB/s.
Best regards,
[PT]Devilishly
So with that kind of option every one knows you weren’t leaching…
May be 1:1 is a little bit to much, but if it would be done in % mode, like 100%, 80% and 60%, I think it would be more fair to everyone.
Has an example, if you are receiving in DC++ this values: Down: 270 KB/s;UP: 60 KB/s.
In 100% mode nothing would be done;
In 80% mode it would be: Down: 216 KB/s and UP: 48 KB/s;
In 60% mode it would be: Down: 162 KB/s and UP: 36 KB/s.
Best regards,
[PT]Devilishly
Hehe, digo o mesmo :P[PT]Devilishly wrote:Boas, fs é sempre bom encontrar por ká alguns Portugas :D
Well.... Search DC++k's code.... You'll find where to choose what you want instead of the 4 ;)Anyway if it’s “UP:DOWN� is 1:4, I think it should be more “UP:DOWN�= 1:1
Proud member of P2P:PT and moderator of its forum.
[PT]Devilishly wrote:About up-load limiting.
I think that it should exist but in another form.
Why not add an option in DC++ that permit reducing resources in it. Like in the tray icon we could chose using all bandwidth in dc++ (100%), 80% or 60%.
This should also reduce the download speed, even thou in generality users can download more than up-loading, but it would incentive users to use it always in 100% mode.
When we needed to use our bandwidth in other applications, we could use this option , and temporally reducing dc++ resources.
Is a suggestion…
Best regards
[PT]Devilishly
PS: Of course with netlimiter, this can also be done
HOLY CRAP you have nailed it on the head, im in.
-
- Posts: 5
- Joined: 2003-06-18 09:15
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
And that's 80% of.. what exactly? Total bandwidth? How do you measure that? You could trust the user. You could try to figure it out yourself. How can you do that robustly? It's a nice thought, of couse, but these problems haven't been solved the previous times limiting by % was mentioned...[PT]Devilishly wrote:So with that kind of option every one knows you weren’t leaching…
May be 1:1 is a little bit to much, but if it would be done in % mode, like 100%, 80% and 60%, I think it would be more fair to everyone.
-
- Posts: 96
- Joined: 2003-04-18 05:57
- Location: Oporto, Portugal
- Contact:
That’s a good point GargoyleMT
Anyway, when we connected to dc++, it could test the connection. Like making a download and an upload and get the UP and down values. After doing this, it would send a message to user saying: “your max values to download are ***KB/s and upload ***KB/s. If those are away to unrealistic, you should close all applications that are using net resources and try to enter dc again.�. If this would run properly we know could use de % values on that connection.
I really don’t know if this can be done or if it would have the expected result…
Best regards,
[PT]Devilishly
Anyway, when we connected to dc++, it could test the connection. Like making a download and an upload and get the UP and down values. After doing this, it would send a message to user saying: “your max values to download are ***KB/s and upload ***KB/s. If those are away to unrealistic, you should close all applications that are using net resources and try to enter dc again.�. If this would run properly we know could use de % values on that connection.
I really don’t know if this can be done or if it would have the expected result…
Best regards,
[PT]Devilishly
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
A test download and upload to who exactly? DSL reports, etc. al. can do this because they have the cooperation of another server. DC++ has to be able to auto-detect bandwidth all by itself. You can't really even rely on the members of the hub... Nobody might be fast enough to max out your download, and you can't force another user to accept an upload. And there's also a minor concern that people might not be able or willing to close all other network applications (for instance, what if they're sharing their DSL and getting the latest Debian Linux updates on another computer).[PT]Devilishly wrote:Anyway, when we connected to dc++, it could test the connection. Like making a download and an upload and get the UP and down values.
It's a can of worms when you start thinking about implementation details. More concerns pop up for me than seem worth it... But hey, that's just me.
What if this percentage is from current bandwidth? So when I tell DC++ to cap at 50% I am telling that at any given time, the bandwidth to upload is the same as for download. Of course if there are no uploads, downloads take all bandwidth, the same when no downloads.
Example at 50%: I am downloading at 10kB with no uploads, but dc++ opens (potential) uploads to 10kB. One upload starts and that makes I can download at 7kB only, then that upload gets 7kB aswell. Another upload makes I can download at 6kB only, then those two uploads get 6kB. This example is very sad because as you read everyone gets less speed, but don't read it emotionally, ok?
Example at 50%: I am downloading at 10kB with no uploads, but dc++ opens (potential) uploads to 10kB. One upload starts and that makes I can download at 7kB only, then that upload gets 7kB aswell. Another upload makes I can download at 6kB only, then those two uploads get 6kB. This example is very sad because as you read everyone gets less speed, but don't read it emotionally, ok?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Ah... I'm confused. A 50-50% split between upload and download bandwidth is exactly when upload limiting is needed least. Or at least that's my perspective as an ADSL user... My bandwidth is split 86-14%.mai9 wrote:What if this percentage is from current bandwidth? So when I tell DC++ to cap at 50% I am telling that at any given time, the bandwidth to upload is the same as for download. Of course if there are no uploads, downloads take all bandwidth, the same when no downloads.
The servicable response to my above question is probably to have DC++ "learn" your connection limits on its own (this would be complicated by people who use more than one internet connection - laptop users, for instance). That involves more than a little statistics, to try to get rid of high and low values. And, of course, it has to be stored on disk, you can't have DC++ try to learn every time it starts up, so it'd be vulnerable to people messing with their config files (though they could more easily get a patched binary).
-
- Posts: 96
- Joined: 2003-04-18 05:57
- Location: Oporto, Portugal
- Contact:
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
my take on it is...
Well, that's the safeguard that BCDC and DC++K both have in them to protect against "abuse" of the upload throttling code.[PT]Devilishly wrote:Ok, I understand that % is a little bit complicated to implement, but why not have the option upload limit like UP:DOWN = 1:2 ?
I think it’s fair enough, but that’s my opinion…
I had an argument when I first wrote the code, about releasing it, with a member of a hub I'm on. He's a regular, with a pretty big share - 140gb, which puts him in the top 10 of the 70-110 user hub. He has cable - but it's 1500/256. He uploads a whole lot to everyone. He doesn't download on DC much, but when he does, he has to cut his upload speed back to 5 kbye/s to download at his connection's full 1500 kbit/s. I was, at that time, using the a modified version of eMule's limiting ratio:
Code: Select all
Upload Max download
------- ------------
< 3000 3 x upload rate
< 10000 4 x upload rate
>=10000 5 x upload rate
For me, I trust Hamm enough to not abuse the system I created. I dropped the ratio. I'd rather not piss off contributors to the DC community by making software that doesn't let them do something that they're probably entitled to. (Hamm's ratio is still multiple times > 1.0.)
The real solution to abusive upload limits is the Ratings System that Sarf and Volkris (among others) talked about a while ago. I think most of the other mod authors agree with me.
Note: this is my position on the matter, and only mine. My situation is unique... only maybe 50 people use my modification, and it's in very limited release (I share it only on DC). If I "had" more users, it'd be a different story, but I'd still feel the same.
Well, the 50-50 number is just... a number. The suggestion was to use the instant speed to decide that percentage, maybe I talked too much about the 50%? maybe...GargoyleMT wrote:Ah... I'm confused. A 50-50% split between upload and download bandwidth is exactly when upload limiting is needed least. Or at least that's my perspective as an ADSL user... My bandwidth is split 86-14%.mai9 wrote:What if this percentage is from current bandwidth? So when I tell DC++ to cap at 50% I am telling that at any given time, the bandwidth to upload is the same as for download. Of course if there are no uploads, downloads take all bandwidth, the same when no downloads.
Better yet -- why not just put the feature in and be done with it? Leechers will always be there -- there's just no way to get rid of 'em. Hubs can run scripts and such to help out with that a bit of course, but as has been noted throughout the thread -- it's not hard to modify code or work around it. So even if the client were re-coded with a 1:2 or 50:50 or other ratio it wouldn't matter -- someone would find a way around it.
A better solution would be to build into DC++ the ability to check those who are downloading from you. For example, if a user is downloading from me at 50kB/s but he has one slot open and has that throttled to 5kB/s then there's obviously an issue. Build into DC++ the ability to query this from the requesting client and then act upon it accordingly. Granted, someone will modify the code, etc., etc., however the average Joe won't be getting into the code.
When you come down to it though, we desperately need this feature. I went to BCDC++ in an attempt to control uploads -- users were sapping my entire upstream bandwidth (80kB/s or so) and business services were hampered (slow loading of pages, mail, etc.). I HAD to throttle it back to keep things under control (I have about 300 gigs up). Now I can't search with BCDC++ so I've had to switch back...and I'm missing that throttle.
A better solution would be to build into DC++ the ability to check those who are downloading from you. For example, if a user is downloading from me at 50kB/s but he has one slot open and has that throttled to 5kB/s then there's obviously an issue. Build into DC++ the ability to query this from the requesting client and then act upon it accordingly. Granted, someone will modify the code, etc., etc., however the average Joe won't be getting into the code.
When you come down to it though, we desperately need this feature. I went to BCDC++ in an attempt to control uploads -- users were sapping my entire upstream bandwidth (80kB/s or so) and business services were hampered (slow loading of pages, mail, etc.). I HAD to throttle it back to keep things under control (I have about 300 gigs up). Now I can't search with BCDC++ so I've had to switch back...and I'm missing that throttle.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Because arne doesn't want it. I wrote the code in BCDC for upload limiting, you'll get no argument from me, except me protecting Arne's right to put whatever he wants into his program.jnj wrote:Better yet -- why not just put the feature in and be done with it?
The rest of your suggestions are nice, but... NMDC for OS X limits upload, and doesn't tell anything about its limit. Why should DC++ behave any differently? Why should it bother you if I limit to something unreasonable? Like 666 bytes / second in a chat-only hub?
The answer that I'm looking for is that it doesn't matter, and should not. A Ratings System would allow uploaders to reward uploaders, so those artificially limiting their speeds to unreasonable limits will not get the perks that contributing users do.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Are you using the latest version? BlackClaw goes through versions quite quickly, sometimes to patch very bad regressions. It sounds like yours might be one of them. Always use the latest, unless the latest has problems... which you won't discover until after you're running it.jnj wrote:Now if you can just tell me why BCDC++ will only search my own shared files rather than the network I can get back to using it again.
Welcome to catch-22
I'm running the 'L' version at the moment. I even went so far as to do a fresh installation and get the same results -- any searches go to my own shares rather than the network. I switched back to DC++ and the searches worked just fine. I have it behind a firewall, but it's on the DMZ and all WAS working fine.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Try looking for a new version in a little while. In the meantime, try filling in all the search options.jnj wrote:I'm running the 'L' version at the moment. I even went so far as to do a fresh installation and get the same results -- any searches go to my own shares rather than the network. I switched back to DC++ and the searches worked just fine. I have it behind a firewall, but it's on the DMZ and all WAS working fine.
reserve bandwidth
all this talk about UL limiting.. DC++ will NEVER implement a simple setting for UL speed becuase it can be abused! K, let's drop that..
To connect the download speed with the upload speed is real stupid! It won't work cause of all different bandwidths ppl have.. swe bostream 2.5Mbit DL 0.5Mbit UL... swe comhem 2Mbit DL 0.2Mbit UL... swe BBB 8Mbit DL 1Mbit UL... sure it will work for some ppl... but come on.. it's NOT a good solution.. so just forget about that one too.
What I wanna know is this:
Is it possible to take, say 3 kB of UL bandwidth and reserve that for the DC downloads? If it is, I think it should be implemented with an on/off setting... no customizeable values that can be made "leechy".
To connect the download speed with the upload speed is real stupid! It won't work cause of all different bandwidths ppl have.. swe bostream 2.5Mbit DL 0.5Mbit UL... swe comhem 2Mbit DL 0.2Mbit UL... swe BBB 8Mbit DL 1Mbit UL... sure it will work for some ppl... but come on.. it's NOT a good solution.. so just forget about that one too.
What I wanna know is this:
Is it possible to take, say 3 kB of UL bandwidth and reserve that for the DC downloads? If it is, I think it should be implemented with an on/off setting... no customizeable values that can be made "leechy".
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
Also, I would like to add one thing. When we talk about potential cheaters that would abuse the UL-limiter. I don't belive that these ppl are truly evil. The reason they turned to UL-limiting in the beginning is probably the same reason we are talking here right now. That UL slows DL. Many of the ppl that set their UL speed too low just don't know better. They set it to be sure that their downloads are not slowed down. I don't think we need to worry at all about ppl that would abuse the code and make an evil mod. What we need to worry about, is stupid users that don't know what they are doing!
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 disagree 100%. I think that you have developed a false sense of security by posting in the forums. You see, the (vast majority of) people that post here are actually concerned with the well being of DC, and, as a result, are concerned with sharing.cyberal wrote:Many of the ppl that set their UL speed too low just don't know better. They set it to be sure that their downloads are not slowed down. I don't think we need to worry at all about ppl that would abuse the code and make an evil mod. What we need to worry about, is stupid users that don't know what they are doing!
Unfornately, MANY are not like this. This is why kazaa most of the other p2p clients are so far behind DC in quality and quantity. People aren't forced to share, and therefore DON'T.
If it weren't for min. share requirements in hubs, there would be many more leechers. Granted, some fakeshare, but that is to advanced for many.
I'm not sure, cyberal, if you have any idea how many people fakeshare. About 3 months ago, I got the file lists from 25 different people (at random, not even those at the top of the share list) and 20 were faking, and 2 were sharing their PROGRAM FILES or WINDOWS directories.
Because faking is an undeniably intentional, and so many do it, imagine how many people would abuse an actual FEATURE in the client that would allow you to share data at slower speeds (and therefore less data).
If you have a problem with uploads negatively impacting your downloads, just imagine what your downloads would be like when the person that is uploading to you has a 1kb/s limit set on his machine.
I absolutely LOVE this client, and would hate to see it tainted with such an abusable feature. Please, dc programmers, do not incorporate this feature in any shape or fashion. As we all know, the reason DC is so much better than the other p2p networks is because it is different. Let's keep it that way.
first, I wanna make something clear.. I don't want an UL limiter, I want an DL optimizer.. a feature that make sure that the DL don't end up without UL bandwidth. This feature should exist hidden, without ANY user interaction.
But I think that you, in your hunt for fakesharers have forgotten why they fake. Users that fake or share their windows folder simply don't have the hdd size to get into big hubs, so they fake, and why not? They have nothing to loose. If they had the amount of data required they wouldn't share their windows folder and keep getting kicked from every hub they enter.
I've seen many ppl with the L: client setting their UL to 1 kB/s.. do you really think they would do that if they had any idea what they were doing? The risk of getting kicked & banned is like 99%...
It's a fact.. most users are STUPID & SELFISH... not evil!
Sure, users that just don't wanna share exists too, but they are very few!
anyways jbyrd... all of this talk about fakesharing is really besides the point.. fakesharing is done to get into bigger hubs with more data.. setting your UL speed to nothing will get you... nothing.
agree 100%jbyrd wrote:This is why kazaa most of the other p2p clients are so far behind DC in quality and quantity. People aren't forced to share, and therefore DON'T.
If it weren't for min. share requirements in hubs, there would be many more leechers.
But I think that you, in your hunt for fakesharers have forgotten why they fake. Users that fake or share their windows folder simply don't have the hdd size to get into big hubs, so they fake, and why not? They have nothing to loose. If they had the amount of data required they wouldn't share their windows folder and keep getting kicked from every hub they enter.
I've seen many ppl with the L: client setting their UL to 1 kB/s.. do you really think they would do that if they had any idea what they were doing? The risk of getting kicked & banned is like 99%...
It's a fact.. most users are STUPID & SELFISH... not evil!
Sure, users that just don't wanna share exists too, but they are very few!
anyways jbyrd... all of this talk about fakesharing is really besides the point.. fakesharing is done to get into bigger hubs with more data.. setting your UL speed to nothing will get you... nothing.
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
As far as I'm concerned, in the DC community, they are the exact same thing.cyberal wrote:It's a fact.. most users are STUPID & SELFISH... not evil!
What's funny is you contradict yourself in the following sentence with:
These SELFISH people that you refered to earlier are the ones that don't want to share. And you said that most users are SELFISH (and, therefore, most users don't WANT to share). These selfish users only share because they have to. If you give them a UL limiter, they will put it at zero...cyberal wrote:Sure, users that just don't wanna share exists too, but they are very few!
Setting your upload speed to nothing will give you faster download speeds. Don't you see the parallel between fakesharing and setting upload speed to zero?cyberal wrote:setting your UL speed to nothing will get you... nothing.
The similarity is that these people are trying to download more stuff. MORE MORE MORE. That's all these selfish bastards want. They want to get into hubs with more stuff (even though they have nothing to share), and surely they will set upload speed to zero if it means they will be able to download more.
GEEZ. How can you sit here and say that you can trust people. You can't!
Again, if you're reading this post, you can probably be trusted. But there are tons of leechers out there. They cannot be trusted.
No it won't, we are talking about the usual ADSL connection I suppose? Cutting back on your upload speed so the downloads get to send their ack packets WILL get you better speeds.. lower it more than that will do NO DIFFERENCE!jbyrd wrote:Setting your upload speed to nothing will give you faster download speeds.
Agree!jbyrd wrote:The similarity is that these people are trying to download more stuff. MORE MORE MORE. That's all these selfish bastards want. They want to get into hubs with more stuff.
Agree! Why should they go through the trouble of sharing some folders, they only care about that they get what they want.jbyrd wrote:These selfish users only share because they have to.
No! I belive that as long as they get the stuff they want, at their maximum speed, they won't care how much you download from them. Why would they risk getting kicked for slow speeds when they are downloading at maximum speeds themselves. They are selfish yes, which means that they only care about that they get what they want for themselves. They don't care about what you do!jbyrd wrote:These SELFISH people that you refered to earlier are the ones that don't want to share. And you said that most users are SELFISH (and, therefore, most users don't WANT to share)..
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
So, what is that speed, my friend? Do you expect these fools to experiment with the upload speed limiter to maximize both download speed while conserving upload speed? Don't count on it. The only sure way to maximize download speed is to turn upload speed to minimum...No it won't, we are talking about the usual ADSL connection I suppose? Cutting back on your upload speed so the downloads get to send their ack packets WILL get you better speeds.. lower it more than that will do NO DIFFERENCE!
(They could always try different upload speeds, and create a graph of download speed vs. upload speed. Then, simply take the first derivative of download speed with respect to upload speed and set it equal to zero. Then, simply solve algebraically for the upload speed. Of course, the result could either be an absolute maximum or absolute minimum. To find out which one it really is, simply use the second derivate test, and see if it's concave upward or concave downward. The latter is a minimum while the former is a maximum. Of course, they want the maximum. Of course, this all depends on proper curve fitting...)
Something tells me that no one will do this, and most won't even remotely experiment.
this was exactly what I was talking about when I said that "they just don't know better"... The downloads need practicly no UL speed, just a few kB... changing it up and down "to maximize both download speed while conserving upload speed" will not make any difference, all the downloads need is a few kB, then they are maximized.. it is only when the uploads are fully maximized that this problem presents itself!
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
This really should be added...
I have a 768/128 connection, and usually run 3-5 p2p programs simultaneously (DC++, eMule, mIRC, WinMX, FTP, usenet) giving me approximately 12-13k/s UL to play with. Programs like eMule eat up 10k/s on the UL immediately given the architecture of the program.
Being a dedicated releaser and/or distributor (with over 500MB of TV / cartoons active at any time), I use the remaining bandwidth to send to fast reservers, usually at 1k/s UL per p2p. Whenever I use DC++, the UL bandwidth crushes ALL other traffic, UL and DL, in all other programs. As a result, I frequent hubs with no minimum share and share little but how to find me in other p2p's, esp IRC.
I'd LOVE to be able to bleed up 1k/s to DC once again, as it was my first and favorite p2p, but I have no interest in hacking clients and/or external limiters.
My theory is that cheaters will ALWAYS cheat. Regardless of what safeguards are put into the program, as long as it is open source, those with malicious intent will succeed. Now, in my case, I see a direct benefit to being able to UL at a limited speed. I can balance the load among active p2p's, bleed up another series to a hub's fast reserver, and cross-polenate my files to a hungry audience, instead of just sending users to a different p2p.
Personally, I don't care if there are DL limitations in doing this, as I don't get many (any?) sources on DC++ any more. That being said, the program architecture is NOT dependant on marrying UL to DL ratios (like ed2k or bitt), and should be treated as such.
Ironically, IRC doesn't seem to have the concerns / issues in the channels I visit. I believe if DC++ gave the users the flexibility you'd find in mIRC, for example, the world wouldn't collapse. The DC hubs and IRC chans I visit generally DO trend towards sharing. I like the IRC feature of letting ops, "voiced users" (i.e. those who share), and "users" (i.e. those who don't share) have different tiers that can be controlled in the queueing priority. I never really liked the "forced minimum share" and "first-come-first-serve-all" mentality of DC anyway.
Oh well. Enough rambling, I guess. To summarize, the CLIENT should be all powerful / functional, and the hub operators and individual sharers should be the ones who control how / to whom files are sent / prioiritized. I guess over the last year I've almost abandoned DC in favor of IRC, but still have a lot of friends here who I'd like to share with.
Thanks for the time!
Being a dedicated releaser and/or distributor (with over 500MB of TV / cartoons active at any time), I use the remaining bandwidth to send to fast reservers, usually at 1k/s UL per p2p. Whenever I use DC++, the UL bandwidth crushes ALL other traffic, UL and DL, in all other programs. As a result, I frequent hubs with no minimum share and share little but how to find me in other p2p's, esp IRC.
I'd LOVE to be able to bleed up 1k/s to DC once again, as it was my first and favorite p2p, but I have no interest in hacking clients and/or external limiters.
My theory is that cheaters will ALWAYS cheat. Regardless of what safeguards are put into the program, as long as it is open source, those with malicious intent will succeed. Now, in my case, I see a direct benefit to being able to UL at a limited speed. I can balance the load among active p2p's, bleed up another series to a hub's fast reserver, and cross-polenate my files to a hungry audience, instead of just sending users to a different p2p.
Personally, I don't care if there are DL limitations in doing this, as I don't get many (any?) sources on DC++ any more. That being said, the program architecture is NOT dependant on marrying UL to DL ratios (like ed2k or bitt), and should be treated as such.
Ironically, IRC doesn't seem to have the concerns / issues in the channels I visit. I believe if DC++ gave the users the flexibility you'd find in mIRC, for example, the world wouldn't collapse. The DC hubs and IRC chans I visit generally DO trend towards sharing. I like the IRC feature of letting ops, "voiced users" (i.e. those who share), and "users" (i.e. those who don't share) have different tiers that can be controlled in the queueing priority. I never really liked the "forced minimum share" and "first-come-first-serve-all" mentality of DC anyway.
Oh well. Enough rambling, I guess. To summarize, the CLIENT should be all powerful / functional, and the hub operators and individual sharers should be the ones who control how / to whom files are sent / prioiritized. I guess over the last year I've almost abandoned DC in favor of IRC, but still have a lot of friends here who I'd like to share with.
Thanks for the time!
Re: This really should be added...
Open-source has nothing to do with cheating. There are cheats available for just about any P2P program, open or closed source...ToonGal wrote:My theory is that cheaters will ALWAYS cheat. Regardless of what safeguards are put into the program, as long as it is open source, those with malicious intent will succeed.