Upload Speed Limiting

[Sedulus]

*slams head against wall*
didn't think of it that way...
hm.. sounds good
maybe it should periodically check if the speed is better (every 5 minutes or so), so a bad start would not be a problem

[sarf]

Well to the user who wants to download from me obviously.
This way obviously we lose a few percent on download even if the download wouldn't saturate the upload limit but with the ratios of up/down capacities being what they are I don't see a major hurdle in that really.

Ummm... you mean that we should start an upload to someone then (after a few seconds to let the maximum speed "build up") cut the bandwidth to that person with 2-5 percent? That is not efficient... but it will work. Unfortunately, if the algorithm isn't reevaluating all the time what might happen are two users which both want 100% of your upload bandwidth. This could pose a problem, since even if you cut off their bw with 2-5 percent they'll still drain all you have.

But maybe I am missing something in the theory. Could someone write some pseudo-code to do some proof-of-concept?

Sarf
---
Everybody is equal here. It's just some people are more equal than others.

[CerthasIM]

It's not efficient nor is it elegant, but in the absence of better proposals...

For multiple streams I would say it would need to reevaluate max capacity everytime a stream is opened.

Say I've got 3 uploads going, my 4th port is requested -> burst send to all 4, get a new max, and cap the total to 90% of that, with the individual clients fighting the old way.

---

I also had another idea which would limit abuse, and technically would only require a download limiter.
Make it possible to automatically request a cap of the stream from the download side.
In this scenario I start to download something and a small messagewindow pops up asking if I agree to limit my download to (Userspecified Byterate/open connections). Displayed with a Userspecified message.
I'm sure msot downloaders would be willing to do the uploaders this favour.
If a user set's his Byterate to low he risks that people will select to not limit their downloads.
Someone with 256Kbit uprate will of course have no problem faking a 128Kbit rate, however, this can be discovered by ops/bots by starting a short test download on the client without download limit.
Easier to detect then fake share I'd say.

[tdowning]

I suppose measuring bandwith automatically is not all that cut-and-dry. my connection will on DC fluctuate from 50-300 kbits. if one large burst goes out in one second, then transfer rate will drop dramatically the next. I suppose you need to play with the limit, and see where the transfer rate steadies out into a nearly constant stream

[sarf]

It's not efficient nor is it elegant, but in the absence of better proposals...[snip]

As stated before, I want to see pseudocode for this. That way I can at least have a chance to see what kind of things are needed to implement it.

I also had another idea which would limit abuse, and technically would only require a download limiter.
[snip auto request download limiting]

Very true, this would work if everyone uses both the client(s) capable of doing requested limit of downloads as well as people having this option enabled (because some people will not want to see 100's of requests popping up because some malicious person likes making their computer crash). Possible to do on a smaller scale and possible to automate as well, you just have to specify a lower limit to the bandwidth that the client will limit itself to.

Someone with 256Kbit uprate will of course have no problem faking a 128Kbit rate, however, this can be discovered by ops/bots by starting a short test download on the client without download limit. Easier to detect then fake share I'd say.

Ummm... so you mean that people without an automated download limiter would be banned/kicked?

I still prefer a ratings system.

Sarf
---
The man who makes no mistakes does not usually make anything.

[CerthasIM]

Pseudo code, well I'm sorry I'm really not a coder. My Pascal days are way past.

-

For the request flooding, you could simply add an option to automatically accept capping requests. (conditionally maybe as you suggested)

Also I didn't mean people without capping are banned but that those who request caps far below their capacity are kicked, which can quickly be figured out by not accepting the caping request and seeing if you get a lot more transfer then the capping request indicated.

Problem is as you said the client, but AFAIcan see most people do use a recent version of DC++, so it doesn't solve the issue from day one but will become better and better as the client spreads.

[Menchi]

Reading the above posts shows that auto detecting is trickier than it looks. As I have said before, only the user knows best how much bandwidth he/she has/needs. The problem isn’t finding out how much bandwidth they have, it is enforcing sane bandwidth management. I agree that both normal DC++ and a user-defined limit do not guarantee this. For now the only solution is to allow the user to set the limit.

Something new:
Periodically check conditions between you and the people downloading from you. Ideally these checks could be initiated by a hub op/bot as a way to detect "cheaters". Burst speed: Allowing unlimited downloading to see if the limit can be surpassed by some %. If it goes above that, a red flag is raised and DC++ knows we have a "leecher". Consistent ping times: possibly to the hub. This can allow us to catch instances where DC++ is abusing your bandwidth to the point of DoS.

This is still avoiding some basic ethical questions regarding p2p etiquette.

Why do people cheat?
Fake shares (not having enough files) and running servers (hubs, games, file sharing) aside...
I see no reason why anyone would want to limit their bandwidth other than to improve quality of service. Someone did mention ISP quota's, but (ISP induced) bandwidth caps are just another way to enforce them, and it should not be considered unreasonable to allow DC++ users to enforce it themselves. 100mbit corporate shared connections fall into another category, but it is not unreasonable to allow them to share without being branded as an abuser of bandwidth.

Regarding the servers
No sane person should be hosting a game server on as little as 256k, a usual speed for those having problems right now. If someone is good enough to be sharing files then why not use DC? Hub owners are already giving back, I don’t think anyone would object to allowing them to share painlessly as well.

The real issue here is that ISP's have created a world where upload bandwidth is scarce.

[Jonte]

finland or sweden for an example ,))

I live in sweden, and the only choise i have is 56k Modem.. whoopee!

[Pycckuu]

Definetely YES
it should have 10k minimum though

[acrespo]

I think that BCDC++ has a interesting algorithm.

If you limit your upload to below 6 Kbytes/sec, download limit will be the same as upload limit. For example, if you set your upload limit to 4 Kbytes/sec, your download limit will be 4 Kbytes/sec too.

But, I would change a little this algorithm: If you set any value to upload limit, download limit will be the same value.

This will resolve all the problems. If user want down the upload limit, the download limit will down too with the same setting. Low and high speed connections will be happy with this algorithm.

I have a private hub in my computer. My conection is DSL 256/128. If I don't have a upload limit I can't connect in my own hub, because I need upload bandwith to the hub!!!

The upload bandwith problem in DC++ is not a user problem only. I am a hub owner with the problem!

Andre Crespo - WAS (was.ddns.info)
[email protected]







Andre Crespo - [email protected]

[ender]

There's only one thing wrong with your thinking: most people don't download all the time, but they do upload all the time... My download limit is ~270 kB/s, upload ~64 kB/s. With BCDC set to limit to 60 kB/s, my UL:DL ratio was around 2, even though when I was downloading, I was downloading with over 200 kB/s... I bet it's the same with most people - they don't download all the time, but when they do, they want to download at least as much as they uploaded.

[yilard]

There's only one thing wrong with your thinking: most people don't download all the time, but they do upload all the time...

Heh, roughly the number of uploads should be globally equal to number of downloads . So in the worst case half of people are just downloading and half of people are just uploading (kinda simplified but I think it's quite true).

When I think about, I have downloads running 24/7. What a pity that download is 15 k/s and upload 400 k/s

[Danzig]

Just updated my version of upload limited dc++ at http://dcpp.netfirms.com with 0.231
It's just the same code as the 0.18 version, but no minimal limit/extra tag this time

[ender]

but no minimal limit/extra tag this time

what's this good for? do you want to ban DC++ 0.231 from all hubs?

[volkris]

This again?
While I was upgrading the version of DC++ on my girlfriend's computer I figured I'd hop on over to ye old DC++ forums to see what's going on.

It's funny to see that the same old conversations are going on with the same old level of cluelessness. I only skimmed this thread, since I've probably skimmed the same thing a hundred times in the past, but it seems that none of you are any closer to offering any real solutions. I see that Sarf made a vague reference to a ratings system, one real solution that was once developed, but I didn't see any reply actually explaining the idea.

So, just a couple of little hints that might boot someone in the right direction... finally:

Focus on the problem. The problem is not that some people take without giving back. The problem is that people taking without giving back will, if left unchecked, lower the total amount available for others to take. Comments like LordAdmiral's "leeching should not be condoned whatsoever" are really displaying a tremendous lack of thought. Of course who am I to question a Lord Admiral?

Be careful who you trust. As it stands Direct Connect as a whole relies on users to play nice with each other, trusting them not to use "unfairly" modified clients and to be honest about what's going on. Obviously this is moronic. Until this is fixed all of the complaining about how evil an upload limiter is will remain kind of silly. The upload limiter is only a small part of the problem, and once the real problem is fixed the limiter problem will evaporate. Luckily this isn't a hugely difficult thing to fix even without modifications to the protocol. Someone just needs to do it.

Humans suck. Anywhere that humans are involved in the operation of DC is a flaw in the design. Computers should be able to manage EVERYTHING better than an op, and if they can't then the system should be altered so that they can. Kick the ops out and everything will work better (or crumble, just make sure it goes towards better). Be wary of hub owners talking in these forums for the same reasons. They're dinosaurs.

Game theory is your friend. Read up on it.

Don't let imperfection daunt you. You'll never be able to make DC/DC++ 100% efficient because of its very nature. Right now it is horribly ineffecient, though, so just because an improvement doesn't hit 100% shouldn't keep you from implementing it.

Arbitrary numbers suck. Every time any of you propose anything along the lines of 90% or 3/4, anytime any of you actually propose specific numbers, you're probably doing something wrong. You're not letting the computers manage themselves.

I could go on and on, but you kids are probably not really caring anyway.

[sarf]

Greetings, Volkris. Nice seeing your name float around in the forums again, even if it is with a flame-teasing post... but then again, you had a penchant for those even on "ye old forums".

This again?

Actually, there is a very good reason to take up this topic again - because for this forum, it is a new thread. Most people on the forum has not read the lichlord forums (well, IMHO and all that).

While I was upgrading the version of DC++ on my girlfriend's computer I figured I'd hop on over to ye old DC++ forums to see what's going on.

Same old, same old. There is nothing truly new, except that for each new version DC++ gets a little more features.

It's funny to see that the same old conversations are going on with the same old level of cluelessness.

Well, we do try to get a new and improved Clueless Person every now and then, so that we can restart old threads with new names.

I only skimmed this thread, since I've probably skimmed the same thing a hundred times in the past, but it seems that none of you are any closer to offering any real solutions. I see that Sarf made a vague reference to a ratings system, one real solution that was once developed, but I didn't see any reply actually explaining the idea.

I was tossing out the ratings system name just to see if someone actually developed a working version of it. I am seriously tempted to build it myself, in C# / VBScript / Java or whatnot just to create some proof-of-concept, but I want to brush up on the old questions - how do you uniquely identify a user without making them anonomyous, for example?
Since I lack the IP of the lichlord server (if it is running anymore) I thought that someone had the answers. Guess I was wrong, or if not, that someone isn't talking.

So, just a couple of little hints that might boot someone in the right direction... finally:

Tsk tsk tsk... Volkris, be patient with the "kids" - they haven't your experience.

Focus on the problem.

I like to focus on solving problems, but hey, I'm just that kind of a guy.

The problem is not that some people take without giving back. The problem is that people taking without giving back will, if left unchecked, lower the total amount available for others to take.
[personal comment snipped]

Yes... add to this the new possibility of getting yourself reported to your ISP for sharing files, and you have a situation in which DC will either evolve or die, due to people migrating to new, undiscovered applications.

Be careful who you trust.

This goes for malicious "reporting" users, too. That problem can be quite easily solved, but it will mean migrating to another infrastructure, such as FreeNet or something similar.

[snip]Until [the trust issue] is fixed all of the complaining about how evil an upload limiter is will remain kind of silly. The upload limiter is only a small part of the problem, and once the real problem is fixed the limiter problem will evaporate. Luckily this isn't a hugely difficult thing to fix even without modifications to the protocol. Someone just needs to do it.

Yes, and that someone needs guidance, lest we get another "Direct Connect"-ish solution of a problem. <shudder> I still haven't got over the $ValidateDenide nor the whole protocol.

Humans suck.

Hmmm... "humans are untrustworthy, shifty buggers" sounds to me like a more palatable description, but alright, let's go with "humans suck". Beware incoming below-the-belt humour, though.

Anywhere that humans are involved in the operation of DC is a flaw in the design. Computers should be able to manage EVERYTHING better than an op, and if they can't then the system should be altered so that they can. Kick the ops out and everything will work better (or crumble, just make sure it goes towards better). Be wary of hub owners talking in these forums for the same reasons. They're dinosaurs.

Well, someone has to run some sort of application, somwhere, so let the humans click on a few buttons every now and then, alright?
But seriously, I do agree that if the DC applications were more automated this would be a Good Thing (tm).

Game theory is your friend. Read up on it.

Where? Links, perhaps? A clarification that is isn't (only) about Othello or PacMan?

Don't let imperfection daunt you. You'll never be able to make DC/DC++ 100% efficient because of its very nature. Right now it is horribly ineffecient, though, so just because an improvement doesn't hit 100% shouldn't keep you from implementing it.

... but do let feature creep daunt you. Don't implement something just because "it might be useful". Make sure it is useful, otherwise, don't bother. If it is something few people would want, make sure it is optional or disabled by default (perhaps at a code level).

Arbitrary numbers suck. Every time any of you propose anything along the lines of 90% or 3/4, anytime any of you actually propose specific numbers, you're probably doing something wrong. You're not letting the computers manage themselves.

However, somewhere we have to start talking about arbitrary numbers. 1 and 0 are good examples, but - jokes aside - some things are better managed by users than computers. What to share, for example, due to the fact that some people do indeed share illegal stuff (gasp!) or even (double gasp!) download illegal stuff from DC.

I could go on and on, but you kids are probably not really caring anyway.

Hmmm... a bit prejudiced, eh? Or just cynical? Either way, cheer up, smile, and reply to interesting and relevant posts. Soon you'll notice that you spend less time in the closet thinking fond thoughts about your axe, and more time in front of your computer, mindlessly replying to topics declared "dead and buried" six months ago. A much better state of being, eh?

Well... all I really wanted to ask was about the details of the ratings system, but I got carried away.

Sarf
---
"They used dogs. They used probes. They used cardio plate crossoffs. They used teepers. They used bribery. They used stick tites. They used intimidation. They used torment. They used torture. They used finks. They used cops. They used search and seizure. They used fallaron. They used betterment incentives. They used finger prints. They used the bertillion system. They used cunning. They used guile. They used treachery. They used Raoul-Mitgong but he wasn't much help. They used applied physics. They used techniques of criminology. And what the hell, they caught him." -- Harlan Ellison, "Repent, Harlequin, said the Tick-Tock Man"

[Jellobug]

I don't know how I would go about implementing this, but maybe upon installation of DC++ there could be a behind-the-scenes speed test performed, upon which an optional limit could be based. It would be possible that they're using bandwidth at the time, thus tainting the true results, but chances are they at least aren't running DC. Or maybe not just at installation, perhaps this test could be performed on program startup. Or system startup.

[volkris]

Greetings, Volkris. Nice seeing your name float around in the forums again, even if it is with a flame-teasing post... but then again, you had a penchant for those even on "ye old forums".

Yeah, I was in a fun mood

This goes for malicious "reporting" users, too. That problem can be quite easily solved, but it will mean migrating to another infrastructure, such as FreeNet or something similar.

I honestly don't believe there will ever be much of a technical solution to this problem. It's a legal/legislative problem, and unless things change there the rest of the picture doesn't have much hope. Freenet and the like solve the problem but only by making tradeoffs that make their systems nearly useless to this group of users. I'd say to basically ignore all of the specifically legal and ISP based concerns when thinking about advancements. Many legal problems manifest themselves as routine poisoned server and routing failure issues anyway.

Yes, and that someone needs guidance, lest we get another "Direct Connect"-ish solution of a problem. <shudder> I still haven't got over the $ValidateDenide nor the whole protocol.

The system was created by someone who simply didn't care about doing it right, that's all. He made his quick buck and that was that.

some things are better managed by users than computers. What to share, for example, due to the fact that some people do indeed share illegal stuff (gasp!) or even (double gasp!) download illegal stuff from DC.

I wouldn't really call a user deciding what he wants to download "managing DC", but in the end that's the full extent of management that the network requires. Other than that people only have to manage their own machines, and then only by deciding how much of their system resources they're willing to exchange in return for access to those downloads.

Well... all I really wanted to ask was about the details of the ratings system, but I got carried away.

I don't remember the full development of the idea. It was so long ago. I know at one point that identification was going to be handled by cooperation between the ratings server and the hub, meaning that if the hub policy allowed authentication then that would allow ratings to be stored and such and if it didn't then users would just keep their ratings for the length of their session (whatever that's defined to be by the hub). But I'm sure the idea went further.

A lot was lost on the lichlord forums. Some was lost on the original sourceforge boards before that as well. Someone in another forum here was talking about MD5 hashing, and I really wish I had a copy of the solution proposed that used tiger tooth (or whatever it's called) hashing. It was pretty developed on Lichlord.

[sarf]

I honestly don't believe there will ever be much of a technical solution to this problem. It's a legal/legislative problem, and unless things change there the rest of the picture doesn't have much hope. Freenet and the like solve the problem but only by making tradeoffs that make their systems nearly useless to this group of users. I'd say to basically ignore all of the specifically legal and ISP based concerns when thinking about advancements. Many legal problems manifest themselves as routine poisoned server and routing failure issues anyway.

Heh. Well, as much as I'd like to see a DC++-ish application using FreeNet instead of that horrible Frost thingy, I guess I'll just have to wait until every packet in the world is being inspected manually by officials searching for a "terrorist threads" and getting their salary supplemented by organisations that wish to control the flow of "their" information.

The system was created by someone who simply didn't care about doing it right, that's all. He made his quick buck and that was that.

I'd like to "do it right"; I just do not want to make it "right" then have 50% of my mails to say "great job, but you could've done it *this* way". I have a psychological flaw, you see, I feel a bit guilty if I delete mail without responding to it (a response being "Where were you when I coded the thing?" or something just as snide).

I wouldn't really call a user deciding what he wants to download "managing DC", but in the end that's the full extent of management that the network requires.

Well, you said that every place the human has to do something, he/she will mess it up (or at least, something to that effect).

Other than that people only have to manage their own machines, and then only by deciding how much of their system resources they're willing to exchange in return for access to those downloads.

I do agree. I, for one, do not have a problem with the current demands on bandwidth / CPU time that DC++ has, but it would be good for everyone to be in control of how much to "feed" DC++ with.

I don't remember the full development of the idea. It was so long ago. I know at one point that identification was going to be handled by cooperation between the ratings server and the hub, meaning that if the hub policy allowed authentication then that would allow ratings to be stored and such and if it didn't then users would just keep their ratings for the length of their session (whatever that's defined to be by the hub). But I'm sure the idea went further.

As am I. Some combination of a MD5 hash of their IP, or hashing their IP and then adding the hash of their nick or whatnot (dredged from a long dormant part of my brain).

A lot was lost on the lichlord forums. Some was lost on the original sourceforge boards before that as well. Someone in another forum here was talking about MD5 hashing, and I really wish I had a copy of the solution proposed that used tiger tooth (or whatever it's called) hashing. It was pretty developed on Lichlord.

Yeah. <sigh> But such is the way of the 'net, here today and gone tomorrow. Too bad it seems to be that way for the knowledge gathered by individuals, as well.

Too much gloom and doom.

To anyone that actually remembers (or even better, had the thing saved to disk in some manner) the discussion about the rating server:

I hereby volunteer to make a "proof-of-concept" Java-program that will work as a ratings server (though not in an optimal way). It will not use a database or connection-pool, but it *will* work. For me to do anything, though, I will need information.

Post here if you want to discuss / suggest / inspire something about the ratings server and/or protocol.

Sarf
---
At first there was nothing. Then God said 'Let there be light!' Then there was still nothing. But you could see it.

[mo]

Some combination of a MD5 hash of their IP, or hashing their IP and then adding the hash of their nick or whatnot

Good starting point, not good for people with dynamic ip addresses :/

[ivulfusbar]

[quote="Danzig"]Just updated my version of upload limited dc++ at [url]http://dcpp.netfirms.com[/url] with 0.231
It's just the same code as the 0.18 version, but no minimal limit/extra tag this time[/quote]


you will be arrested, you do not follow the GPL. Legal actions will be taken.

[CerthasIM]

"Arbitrary numbers suck. Every time any of you propose anything along the lines of 90% or 3/4, anytime any of you actually propose specific numbers, you're probably doing something wrong. You're not letting the computers manage themselves."

We're not doing something wrong, ADSL is doing something wrong. We have to implement a Hack to correct this inaccesible mistake there.
We have numbers from experience which are overall quite coherent.
And the sollution Danzig proposed in the other thread (and I repeated here unconcious of hsiproposal) might not be new but sounds to me conceptually human proof.

[Danzig]

you will be arrested, you do not follow the GPL. Legal actions will be taken.

Oh, i'm so scared.

Do you want me to release the sources or what?

[volkris]

We're not doing something wrong, ADSL is doing something wrong. We have to implement a Hack to correct this inaccesible mistake there.

I assume you're referring to the "set the limit to 75% of max speed" idea.

It's just not incredibly doable without tremendous expense of bandwidth just measuring the speed. Individual bursts won't work because of network equipment that buffers streams while cutting through bursts, affecting your results. I suppose you could use some sort of system where you throttle the transfer itself up and down, testing the BW for thirty seconds every four minutes, but this is complicated and partially dependent on the OS to cooperate. And of course who exactly are you going to be sending this traffic to in the first place? If you're sending it anywhere on the Internet you'll be measuring traffic between you and the other person, which says almost nothing about your own traffic capacity.

For example, if because of some bottleneck between me and you there's a huge bottleneck that drops the connection speed to 100kb then your proposal would mean that I would only be transmitting 75kb to you, even though I'm sitting here on my fat 10mb connection and have no need to cut out that 25kb. You'd be having to wait 25% longer for the file for no reason at all.

Your hack is just that: a crude hack. Sure it could be done as a quick measure to at least get SOMETHING done, but it hardly solves the problem of giving users the ability to determine how much upload bandwidth they can afford and are willing to give to uploaders.

sounds to me conceptually human proof.

It's not. I can do a number of things to my computer to trick the DC client into thinking I have less bandwidth than I really have, thus limiting my bandwidth to whatever I want. Not only that, but this changes nothing about my ability to simply edit the code. This system where bandwidth is limited by the giver and nobody else says anything about it is fundamentally human reliant. It fundamentally relies on trusting users to give what they have. This is the stupidity of the DC trust model.

Until there is some sort of direct feedback involved in the system nothing will be human proof and efficiency will slowly deteriorate.

If there is feedback, though, suddenly clients will begin competing against each other in ways that improve DC. Right now clients compete against each other to take; they jump over each other trying to get those slots. If feedback existed they would also jump over each other to give, so the clients would have every reason to experiement with different transfer mechanisms as discussed here. Get it?

[AlleyKat]

Hmmm to turn the entire concept a bit around, would it be possible to make the program "stutter"?

My first thought was something very dirty I haven't really done any serious programming since the true assembler days on the C64, so it was something along the lines of a few well-placed "noop"'s But to put such a suggestion to true programmers like arnetheduck and his henchmen... and what about the different speeds at which machines does their "thing" and so on and so forth. No.

But... all the network traffic are done in packets. And there is SOME control over the flow of those packets, at several levels. Weren't it possible simply to let DC++ "skip" say 5 in every 100 packets, leaving it in queue to the next 100 (well 95) - and leave that last bit of packets' time to the rest of the system? Ofcourse it wouldn't help if it immediately forwarded the next 95 packets - it has to leave those remainíng bytes to the rest of the system, idle or not?

If some Greater Light could enlighten us Smaller Lights with some 10 or 15 lines of code that could achieve the above, and the Father Light included the elegant Lines of (leech-) Free Connectivity in the Mother Code, at least my little light would shine 24/7 instead of 8-15/5-6.

I also see too many dangers in all those attempts to measure the speed of the machine's internet connection - its too easily tampered with, and how and against what?

Basicly, I think I'm still mostly for the idea of placing trust in people, making it the detailed manual setup of ones own linesize that appeals the most to me. And with a more precise measurement of avg. upload speeds, maybe the hub (/ops/bots) could test if its the truth by simple testing a hub get filelist and data about the avg. speed (this too could ofcoz be faked, but it must be getting harder).
--------------------------------
I'm getting tired of having to stop DC++ to read and post in here.

[meermanr]

I have been reading through this thread and everyone seems to be interested in ADSL and 10Mbit connections, which is fair enough.

But there are a select few users (I know of about 250+) who use DC++ on a University LAN, which means we are all connected at 100Mbit Full Duplex, a nice rate of 10Mb/s!

So my problem is not so much about bandwidth, but a much more serious one. My harddisk!!

If I am using my PC, (watching a film, or using the TV card for instance) and a single person starts to download from me, I send the file at a rip-roaring 10Mbytes a second! My harddisk can barely achieve this speed, and so my entire computer effectivly stalls, everything becomes jerky and so on.

This is a real shame becuase it simply means i dont share 24/7 as it spanks my poor harddisk. I have to close it whenever I start using my machine, and I often forget to open it again.

This is my rather special scenario, and reason, that we all need bandwidth limiting! Limit the whole program - Just as long as it does not over take my harddisk!

Ideally (here come some fresh input) I'd like DC++ to be able to check which programs are running. For instance if the screensaver is active it will go at full speed, if Media Player or DScalar ( my TV app ) are running it should go to slow mode. This would solve the open/close fiasco I have at the moment!

PS. No doubt some smart person will suggest I slow my network card down to 10Mbit, but the difference between 900kbps and 10Mbps is to much for me..!

[volkris]

But there are a select few users (I know of about 250+) who use DC++ on a University LAN, which means we are all connected at 100Mbit Full Duplex, a nice rate of 10Mb/s!

What university do you go to? And how is 100FDX equal to 10Mb/s?

So my problem is not so much about bandwidth, but a much more serious one. My harddisk!!

Additionally you might try some hardware tuning utilities. For example make sure you have DMA enabled for your disks, if you can.

It's strange that your TV card would skip. Normally TV cards basically write directly to your graphics card without any use of the processor or anything else that would allow it to skip. If you don't have AGP then you migth consider upgrading. Also, perhaps some sizes of video will skip while others won't.

But anyway, I agree with you completely. Bandwidth limiting to me isn't about ADSL, it's about the much larger picture where anyone should be able to limit their bandwidth for whatever reason. We have no way of knowing how many good sharers are lost because they can't leave DC running at full throttle 24/7.

So yeah, I'm with you. Until complete limiting is in place this problem won't be solved. Arne disagrees, though Go get one of the DC++ clones that has limiting built in.

You should take your suggestion about monitoring for other programs (especially screen saver) and start a new thread. Perhaps DC++ can open an extra slot or something when the screen saver is activated. Your suggestion would be much more likely to be implemented if it wasn't tied to bandwidth limiting. I believe DC++ could even just monitor idle time like instant messenger.

PS. No doubt some smart person will suggest I slow my network card down to 10Mbit, but the difference between 900kbps and 10Mbps is to much for me..!

Oh, no, don't do that. Just install a QOS program that lets you specify that the DC port is to only get 10mb. Everything else will run at full speed.

[meermanr]

What university do you go to? And how is 100FDX equal to 10Mb/s?

University of Warwick, UK

PS. No doubt some smart person will suggest I slow my network card down to 10Mbit, but the difference between 900kbps and 10Mbps is to much for me..!

Oh, no, don't do that. Just install a QOS program that lets you specify that the DC port is to only get 10mb. Everything else will run at full speed.

QoS? That is one of the clients you can install on the network card right? I have that installed, I had no idea you could do that - how excatly would I go about limiting DC++ to 10Mbit?

I got a limited version of DC++, but the most it allows is 100Kbps, I want around 4,096kbps!

btw - 100MbFD = 10MB/s I meant, didn't realise the difference a captial B makes.. 100Mbit ~ 10Mbytes (ish)

Tanks for your help, I think I will start a new thread!

[volkris]

QoS? That is one of the clients you can install on the network card right? I have that installed, I had no idea you could do that - how excatly would I go about limiting DC++ to 10Mbit?

I only know how to do it under Linux, sorry.
I know you Windows guys are dealing with an inferior OS and all, but surely modern versions of Windows can do QoS somehow

Let's see... Linux had it at least five years ago so yep, it's about time for Windows to get around to catching up.

[meermanr]

I don't suppose Cygwin will do the trick?!

[Sedulus]

Just updated my version of upload limited dc++ at http://dcpp.netfirms.com with 0.231
It's just the same code as the 0.18 version, but no minimal limit/extra tag this time

you will be arrested, you do not follow the GPL. Legal actions will be taken.

Oh, i'm so scared.

Do you want me to release the sources or what?

eat this:

Code: Select all

Hello, 

Thank you for your e-mail . We have terminated this account.

Netfirms aims to provide legitimate web hosting services and has a ZERO tolerance policy towards illegal content.

We apologize for the inconvenience this has caused you.
If you have any further questions, please do not hesitate to contact us.

Thanks,

Allan
Abuse Department

:P

[Sedulus]

note that I didn't plan to get your account removed, I just wanted you to get a slight prod so you would respect the GPL.

[volkris]

Abuse Department

Man, I have NEVER seen an abuse department actually do something I've considered constructive.

This goes for all abuse departments from official businesses down to little rag tag groups like those policing LiveJournal.com

[Menchi]

This isnt violating GPL if he agrees to send anyone who asks the source code ... through snail mail even
and its not like you cant contact him
just ask, dont abuse the system to forward your own agenda.


So i'll ask right here. Can you, Danzig, give us the source?
All i'm asking is for the core code, i'm not a socks programer and DC++'s source code is horrible. I've been looking through DCGUI's code and found a few things you might want to add.

Code: Select all

// this is the max rate for every slot but if a slot use less than
// we give the other slots the "restrate"
rate /= DownloadManagerInfo.slot_use_settings;
if ( rate > 0 )
{
	obj     = 0;
	count   = 0;
	tmprate = 0;
	while( pTransferList->Next( (CObject*&)obj) )
	{
		pTransfer = (CTransfer*)obj;
		if ( (pTransfer->GetDone() == etsNONE) &&
		     (pTransfer->GetSrcDirection() == edUPLOAD) &&
		     (pTransfer->GetTransferType() == ettSETTINGS) )
		{
			// check if the slot use less than 1/2 of the max rate
			if ( (pTransfer->GetTransferrate() < (pTransfer->GetRate()/2)) 
				&& (rate >= pTransfer->GetRate()) )
			{
				// set the new rate for this transfer (3/4)
				pTransfer->SetRate((pTransfer->GetRate()*3/4));
				// give other slots the restrate
				tmprate += rate-pTransfer->GetRate();
			}
			// check if the slot use less than 3/4 but more as 1/2 
			//of the current rate we made no changes
			else if ( (pTransfer->GetTransferrate() < (pTransfer->GetRate()*3/4)) 
					&& (rate >= pTransfer->GetRate()) )
			{
				// give other slots the restrate
				tmprate += rate-pTransfer->GetRate();
			}
			// all other slots use more as 3/4 or the max rate
			//for a slot is less than the current rate for the transfer
			else
			{
				count++;
				tmprate += rate;
			}
		}
	}
}

for those of you who think a quick hack isnt easy
here it is in all its laggy glory.

Code: Select all

void Socket::write(const char* aBuffer, int aLen) throw(SocketException) {
	checkconnected();
//	dcdebug("Writing %db: %.100s\n", aLen, aBuffer);
	dcassert(aLen > 0);
	int pos = 0;
//-	int sendSize = min(aLen, 16384);
//+
	int sendSize = 0;

 	// If speed throttling is enabled set maximum send length to a multiple of 512
 	// based on the maximum throttling rate instead of 16384.  This gives finer grain 
 	// control to the speed throttling and shouldn't impact actual throughput as 
 	// winsock should coalesce send buffers.
 
	if (getSendRate() != 0)
	{
		sendSize = (getSendRate()<=10240 ? 512 : 512*(getSendRate()/10240));
		if (sendSize > 16384) sendSize = 16384;
	}
	else
		sendSize = 16384;

 	sendSize = min(aLen, sendSize);
//+/


	bool blockAgain = false;

	while(pos < aLen) {

//+
		// Check to see if we have exceeded the send speed limit
		// Don't impose speed limit on small send packets as they are hub/user messages
		if (sendSize > 256 && getSendRate() != 0)
		{
			int j=0;
			dcdebug("Thottling (%d):  stats.up: %d  sendSize: %d \n", j, stats.up, sendSize);

			// Wait until stats.up is reset or 2 seconds have elapsed.
			while (stats.up >= getSendRate() && j< 100)
			{
				Sleep(20);
				j++;
			}

		}
//+/ 	

		int i = ::send(sock, aBuffer+pos, min(aLen-pos, sendSize), 0);
		if(i == SOCKET_ERROR) {

remember, where looking for a GOOD bandwidth limiter, to make it so easy to upload that people wont want to fake share.

[ender]

This isnt violating GPL if he agrees to send anyone who asks the source code ... through snail mail even
and its not like you cant contact him
just ask, dont abuse the system to forward your own agenda.

Actuall it is - the GPL requires that the source code can be obtained in the same way as the binary - so if your program can be downloaded from a website, the source code must be downloadable from the same place, too.

[Menchi]

You're supposed to provide the source code by mail-order on a physical medium, if someone orders it. You are welcome to offer people a way to copy the corresponding source code by FTP, in addition to the mail-order option, but FTP access to the source is not sufficient to satisfy section 3 of the GPL.
When a user orders the source, you have to make sure to get the source to that user. If a particular user can conveniently get the source from you by anonymous FTP, fine--that does the job. But not every user can do such a download. The rest of the users are just as entitled to get the source code from you, which means you must be prepared to send it to them by post.

If the FTP access is convenient enough, perhaps no one will choose to mail-order a copy. If so, you will never have to ship one. But you cannot assume that.

Of course, it's easiest to just send the source with the binary in the first place.

I think this proves my point, thank you for the link.

[Menchi]

Sorry. I thought the second link was the same and I didnt read it.

Still, when you see someone in violation of the gpl you are supposed to report it.
http://www.gnu.org/licenses/gpl-faq.htm ... gViolation

Now we have even less of a chance to get that code.

[Rubberband]

eat this:

Considering your abuse of copyright, as noted on:

http://wza.digitalbrains.com/

I'm assuming you have brains enough to consider that you may also receive a communication and perhaps a visit from your local police force should you have not covered your arse sufficiently.

I suppose it's more thrilling to take down a GPL violater and brag about it on the board than consider that his contribution had more merit than your overzealous actions.

[Pycckuu]

we need a minimum for upload (10KB/sec or even 20)
OR we don`t neeed this feature!

[AlleyKat]

we need a minimum for upload (10KB/sec or even 20) OR we don`t neeed this feature!

Well... If I should be really selfish, I'd agree on the 10KB up limit - that would enable me to leave 3,6KB/s for surfing, mails and messaging - and I'd be more than happy.

But the best would still be a precise measurement of the lines true limits, then capping it by just 1 or 2KB/s - WHICH IS ALL I ASK! Well, I suppose it doesn't help yelling either...

[volkris]

But the best would still be a precise measurement of the lines true limits, then capping it by just 1 or 2KB/s - WHICH IS ALL I ASK! Well, I suppose it doesn't help yelling either...

Nooo, the best would be a quantum communication channel of some sort that would transmit an infinite amount of information instantaneously

[kender]

How about connecting upload limit to download limit(so that if u cap ur ul to 10kB/s u can only get 50kB/s - or lower) Should be fair enough.
Oh and btw - Do I understand correctly or the whole issue of not putting ul cap into dc++ is to prevetn morons that aren't smart enough from halting their ul? That kinda sux - cause there r so many ways to cheat in dc it only takes little brains to go and use them :< And u deny USEFUL ability for those who need it :<

PS. For all you ppl that have some money spare - go buy some P100 with 1GB HDD and make it into a linux router with QoS Should help and costs r almost nil(Will require some time though

[Sapporo]

Ok, so now I have to go out and buy hardware because a feature is missing in my free software.

People who want upload caps will just use an unoffical version that may implement it in an "unfriendly" way. The point of adding upload limiting to the offical release would be that it could be standardized. Probably including reporting of upload caps to the HUB. So the HUB can then regulate their own policies on it.

Don't like people with upload caps? Then go to the "NO UPLOAD CAP HERE" HUBs that will most likely appear.

[Danzig]

note that I didn't plan to get your account removed, I just wanted you to get a slight prod so you would respect the GPL.

I DO respect GPL, you f*kin moron, but I also respect the DC society, and I'm sure this source-code won't do any good to us, DC users.

But anyway, there you have it:
http://dc-plus-plus.netfirms.com

[AlleyKat]

erm, well done Sedulus, that'll stop the 'blue'-versions dead in the tracks... oh well.. mebbe Danzig shouldn't have posted it in here in the first place. For myself, I might just use his version - I'm getting tired of being 'offline' just because I wanna share with my friends.

For me, I'd like to go with kender's advice and set up a *nix box, I got a 133 around here somewhere. Too bad, really, I don't want it capped at night - might as well share the last few bytes, right - but with a box on it, I'll have to work through hell to make an easy capping-on/off from my desktop. I still find the DC concept cool - I'm just getting so tired of my client I'm seriously considering changing. I've heard both WinMX and eDonkey mentioned. Maybe it's worth a check.

[mo]

Here is a possible solution to the upload limit issue...

If the users ul/dl ratio is better than 1, allow that person to use a reasonable limit.
4k min per slot possibly?

If you have 3 slots 12k is the most your allowed to limit
If you have 10 slots 40k is the most your allowed to limit
etc...

If their ratio is less than 1, no limiter is available.

I know the ul/dl ratio is calculated by some plain text values in the ini file, so those values would need to me encrypted in some way to prevent tampering.

[Sapporo]

Personally, I don't think the minimums should be regulated on the client side. Especially considering someone can just remove that limit and recompile the client in a few seconds. This should be something that the hubs should regulate themselves (via kicking).

[sarf]

[using ul/dl ratio as a toggle for upload limiting]

Unfortunately, this would be hacked. Even if no one makes a modified client with it, they would make a "patch" or "crack" that would set your ratio to some high value simply by looking at how the value is encrypted, thus ensuring a good ratio for many gigabytes of downloading.

A guy in the MMORPG business said once "Do not store any information client-side. All such information is in the hands of the enemy". While I dislike being negative about things, this is the case for DC++. Besides, I prefer for my software to be working for me, not against me, using easily defeated checks that penalizes some good and fewer bad users.

What I want to do is to make it a positive thing to share - and an even better thing to have people get stuff from you. The ratings servers are one way of doing this - so far the only way I've heard about that has a chance to work. In a system such as this, uploadlimiting would not be an issue, falsified ratings would be. That problem could be solved. Decreasing the control the end-user has over their software will not solve the problem of uploadlimited clients in the current system - it will only reinforce the somewhat tarnished reputation of open-source software as a tool for hackers, crackers and coders - not a tool for the normal user.

Sarf
---
If at first you don't succeed, quit; don't be a nut about success.

[harry_x]

If you have a old p120-ish box + 2 nics lying around, you can install linux + QoS. Linux can act as a bridge and also shape the traffic. I am planning to deploy one box just like this at our house's very saturated 10mbps connection. Bridging means the box will work like a switch (it is in fact a 2-port switch): no network config changes at all, so no router/passive/active mode problems.

So modding dc++ isnt the only way to do this.

no it isn't - i'm using this scheme at home for about 3/4 year... The only problem is that most of qdisc are too unaccurate to shape traffic on these slow links - for example CBQ is at my slow link unusable - so i had to apply the HTB qdisc patch ,which works fine. I crap my upload speed to about 85% of my real upload speed (total upload speed), so the ACK packets can go (eg. my download speed is then unaffected. <br>
And that should be implemented in DC++, because is much clearer and info about the amount of crapping could be in ++ tags. It's odd to say that it could be abused - but same way amout of share, slots,etc. could be faked:) <br>
btw here in czech exists client called CZDC++ and linux DCgui is popular too - both of them supports upload capping - and dcgui tells amount of capping in ++ tag - and most of hubs have no problem with that - so tell my other should have - if they don't want to allow capping, then bots will simply kick people with it (and of course, it could be faked - but if somebody want to leech, then he will use leech clients which do much worse things that simple upload capper in DC++).

[harry_x]

But there are a select few users (I know of about 250+) who use DC++ on a University LAN, which means we are all connected at 100Mbit Full Duplex, a nice rate of 10Mb/s!

What university do you go to? And how is 100FDX equal to 10Mb/s?

So my problem is not so much about bandwidth, but a much more serious one. My harddisk!!

Additionally you might try some hardware tuning utilities. For example make sure you have DMA enabled for your disks, if you can.

It's strange that your TV card would skip. Normally TV cards basically write directly to your graphics card without any use of the processor or anything else that would allow it to skip. If you don't have AGP then you migth consider upgrading. Also, perhaps some sizes of video will skip while others won't.

But anyway, I agree with you completely. Bandwidth limiting to me isn't about ADSL, it's about the much larger picture where anyone should be able to limit their bandwidth for whatever reason. We have no way of knowing how many good sharers are lost because they can't leave DC running at full throttle 24/7.

So yeah, I'm with you. Until complete limiting is in place this problem won't be solved. Arne disagrees, though Go get one of the DC++ clones that has limiting built in.

You should take your suggestion about monitoring for other programs (especially screen saver) and start a new thread. Perhaps DC++ can open an extra slot or something when the screen saver is activated. Your suggestion would be much more likely to be implemented if it wasn't tied to bandwidth limiting. I believe DC++ could even just monitor idle time like instant messenger.

PS. No doubt some smart person will suggest I slow my network card down to 10Mbit, but the difference between 900kbps and 10Mbps is to much for me..!

Oh, no, don't do that. Just install a QOS program that lets you specify that the DC port is to only get 10mb. Everything else will run at full speed.

hmn imho it isn't so easy because you will never know the ports that the other side could use (it doesn't apply on active mode). but i dunno, i din't studied it so much (beacause se i run dc++ at old notebook with windows - at workstation i use linux - so i can use ip base filter applied to QoS class)