upload speed limiter

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

rockteer
Posts: 3
Joined: 2003-06-02 11:10

upload speed limiter

Post by rockteer » 2003-06-02 11:35

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 :P
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

Kenneth-Chile
Posts: 80
Joined: 2003-03-21 10:17
Location: Concepcion, Chile.

Post by Kenneth-Chile » 2003-06-02 12:26

Image
In Theory, there is no difference between Theory and Practice. In Practice, there is.

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-06-02 14:14

[shameless plug mode]
Try DC++k or BCDC++... to get the former, simply press my "www"-button. :)
[/shameless plug mode]

Sarf
---
Only borrow from pessimists--they don't expect to be paid back.

Nazo
Posts: 68
Joined: 2003-04-03 14:35

Re: upload speed limiter

Post by Nazo » 2003-06-02 17:46

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
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
Posts: 3
Joined: 2003-06-02 11:10

Post by rockteer » 2003-06-03 17:13

well, i realy didn't quite use the search button :P
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

Nazo
Posts: 68
Joined: 2003-04-03 14:35

Post by Nazo » 2003-06-03 19:07

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.

rockteer
Posts: 3
Joined: 2003-06-02 11:10

Post by rockteer » 2003-06-04 13:15

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 :P

stay cool

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-04 21:24

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>
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.

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-06-05 01:34

Just to make another thing clear - this problem is not solvable in 15 minutes by programmers, either. :lol:

Sarf
---
I believe that everyone is entitled to my opinion.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-05 19:28

sarf wrote:Just to make another thing clear - this problem is not solvable in 15 minutes by programmers, either.
Sure it is, the last 15 minutes leading up to the solution count!

I never said total time. ;-)

Think outside the box... Or something.

Nazo
Posts: 68
Joined: 2003-04-03 14:35

Post by Nazo » 2003-06-05 19:56

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.

fishaa
Posts: 5
Joined: 2003-05-28 14:56

Post by fishaa » 2003-06-06 10:07

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

dieselmachine
Posts: 36
Joined: 2003-01-19 22:22
Location: Rochester, NY, USA
Contact:

The problem is already solved

Post by dieselmachine » 2003-06-06 15:46

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...

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-08 22:20

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.
Date: 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...
From: http://sourceforge.net/tracker/index.ph ... tid=527768

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-06-09 07:58

well you can allways use www.netlimiter.com :)

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-09 21:42

Wisp wrote:well you can allways use www.netlimiter.com :)
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
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2003-06-10 07:47

GargoyleMT wrote:
Wisp wrote:well you can allways use www.netlimiter.com :)
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.
that's fixed in the latest version

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-06-15 10:45

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 ;)

fs
Posts: 4
Joined: 2003-06-13 09:51
Location: .pt

Post by fs » 2003-06-15 18:21

Something like that is already with DC++k. When you limit you upload to, let's say, 10KB/s, it automatically changes the download limit to 40KB/s.

So, with DC++k:
UP:DOWN = 1:4

Is this what you're looking for? ;)

Æ’s
Proud member of P2P:PT and moderator of its forum.

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-06-16 03:04

Boas, fs é sempre bom encontrar por ká alguns Portugas :D

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

ender
Posts: 224
Joined: 2003-01-03 17:47

Post by ender » 2003-06-16 03:24

1:1 would needlessly limit your own downloading capacity - I'm limiting my uploads at the network layer, having the max upload speed set to 60 kB/s and max download to 270 kB/s... guess what, I still upload much more than I download - however when I do download, I'm able to get things fast.

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-06-16 04:42

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

fs
Posts: 4
Joined: 2003-06-13 09:51
Location: .pt

Post by fs » 2003-06-16 09:30

[PT]Devilishly wrote:Boas, fs é sempre bom encontrar por ká alguns Portugas :D
Hehe, digo o mesmo :P

Anyway if it’s “UP:DOWN� is 1:4, I think it should be more “UP:DOWN�= 1:1
Well.... Search DC++k's code.... You'll find where to choose what you want instead of the 4 ;)
Proud member of P2P:PT and moderator of its forum.

XmothX
Posts: 14
Joined: 2003-06-18 13:29

Post by XmothX » 2003-06-19 15:34

[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&#8230;

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.

Dev e-xtreme.net
Posts: 5
Joined: 2003-06-18 09:15

Post by Dev e-xtreme.net » 2003-06-19 16:40

PS: Of course with netlimiter, this can also be done
dammit u found out my sercret of using netlimiter dam u!

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-19 23:00

[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.
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
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-06-20 09:37

That’s a good point GargoyleMT :D
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

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-20 20:03

[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.
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).

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.

mai9
Posts: 111
Joined: 2003-04-16 23:02

Post by mai9 » 2003-06-21 07:14

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?

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-21 09:44

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.
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%.

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).

[PT]Devilishly
Posts: 96
Joined: 2003-04-18 05:57
Location: Oporto, Portugal
Contact:

Post by [PT]Devilishly » 2003-06-21 10:13

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…

Best regards,
[PT]Devilishly

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

my take on it is...

Post by GargoyleMT » 2003-06-21 11:35

[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…
Well, that's the safeguard that BCDC and DC++K both have in them to protect against "abuse" of the upload throttling code.

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
So, with my client, he'd only be able to download at 20kbyte/s instead of 180 kbyte/s. This was obviously unacceptable to him, and he said that if I did it that way, he'd just hack the source and do it his way anyhow.


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.

mai9
Posts: 111
Joined: 2003-04-16 23:02

Post by mai9 » 2003-06-21 18:38

GargoyleMT wrote:
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.
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%.
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... :)

jnj
Posts: 3
Joined: 2003-06-23 14:48

Post by jnj » 2003-06-24 14:21

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. :(

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-24 14:51

jnj wrote:Better yet -- why not just put the feature in and be done with it?
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.

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.

jnj
Posts: 3
Joined: 2003-06-23 14:48

Post by jnj » 2003-06-24 15:02

I can't say that I disagree with you. I've been recommending a number of users over to BCDC++ for just these reasons.

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. :)

James

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-24 15:29

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.
:) 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. :)

Welcome to catch-22

jnj
Posts: 3
Joined: 2003-06-23 14:48

Post by jnj » 2003-06-24 15:41

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.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-06-24 15:47

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.
Try looking for a new version in a little while. In the meantime, try filling in all the search options.

cyberal
Posts: 360
Joined: 2003-05-16 05:42

reserve bandwidth

Post by cyberal » 2003-06-25 01:13

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".
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

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-06-25 01:24

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

jbyrd
Posts: 255
Joined: 2003-05-10 09:26
Location: no-la-usa-earth
Contact:

Post by jbyrd » 2003-06-25 10:16

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!
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.

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. :roll:

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. :!:

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Post by sarf » 2003-06-25 11:43

cyberal, to answer your question about "leaving a little bandwidth for other programs/ACKs" - it can't be done easily. Unfortunately.

Sarf
---
There has been an alarming increase in the number of things you know nothing about.

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-06-25 11:55

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.
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.
agree 100%


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

jbyrd
Posts: 255
Joined: 2003-05-10 09:26
Location: no-la-usa-earth
Contact:

Post by jbyrd » 2003-06-25 14:17

cyberal wrote:It's a fact.. most users are STUPID & SELFISH... not evil!
As far as I'm concerned, in the DC community, they are the exact same thing.

What's funny is you contradict yourself in the following sentence with:
cyberal wrote:Sure, users that just don't wanna share exists too, but they are very few!
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:setting your UL speed to nothing will get you... nothing.
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?

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.

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-06-26 02:09

jbyrd wrote:Setting your upload speed to nothing will give you faster download speeds.
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: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!
jbyrd wrote:These selfish users only share because they have to.
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 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)..
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!
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

jbyrd
Posts: 255
Joined: 2003-05-10 09:26
Location: no-la-usa-earth
Contact:

Post by jbyrd » 2003-06-26 07:55

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!
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...

(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...) :roll: :roll: :roll: :roll: :roll: :roll: :roll:

Something tells me that no one will do this, and most won't even remotely experiment. :|

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-06-26 09:08

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

ToonGal
Posts: 7
Joined: 2003-03-23 15:53
Location: Bay Area, CA
Contact:

This really should be added...

Post by ToonGal » 2003-07-02 03:50

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!

ender
Posts: 224
Joined: 2003-01-03 17:47

Re: This really should be added...

Post by ender » 2003-07-04 04:55

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.
Open-source has nothing to do with cheating. There are cheats available for just about any P2P program, open or closed source...

Locked