upload speed limiter

[ToonGal]

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

"...put into the program" was specifically referring to DC++ only. I wasn't trying to imply that if DC++ was "closed" source, that it couldn't be hacked. Even mentioned external limiters in the line b4 that one.

What I do believe is that since those who WANT to "cheat" (limit, not share, fake share, etc.) can do it with relative ease, there is no good reason NOT to include it. This would make it easier for those who want to control their environment, while still being productive to the community at large.

Unfortunately, my usage of DC++ has dwindled to a trickle, and I share practically nothing at this point, simply because one DC UL crushes all other activities / p2p's running. The program is little more to me than a chat service to visit friends and recruiting station to get people to IRC. Ironically, this comes at a time where my b/w has doubled due to the new cable modem being faster than DSL in my area.

Oh well.

[GargoyleMT]

What I do believe is that since those who WANT to "cheat" (limit, not share, fake share, etc.) can do it with relative ease, there is no good reason NOT to include it. This would make it easier for those who want to control their environment, while still being productive to the community at large.

I'd play devil's advocate, but I can't get behind it. I'm sure you can think of plenty of things that you'd rather have barriers to entry - for instance, being 16+ to drive a car. Or having a permit to carry concealed handguns. (Neither are good examples, but you don't want _everyone_ to drive, or _everyone_ to carry a concealed handgun, do you?) Both are for the "safety" of the community. (If anyone jumps on this argument, relax, it's only a bit of extremism to help you see a counter-argument.)

Unfortunately, my usage of DC++ has dwindled to a trickle, and I share practically nothing at this point, simply because one DC UL crushes all other activities / p2p's running. The program is little more to me than a chat service to visit friends and recruiting station to get people to IRC. Ironically, this comes at a time where my b/w has doubled due to the new cable modem being faster than DSL in my area.

There -are- upload limiting clients that will hide your limit (BCDC and DC++k). Suffering because you don't use one is... less than ideal

[ToonGal]

There -are- upload limiting clients that will hide your limit (BCDC and DC++k). Suffering because you don't use one is... less than ideal

Hardly suffering... I -do- use those when I'm uploading to friends in DC, AFTER they ask me while using DC++. UL bandwidth control was the first reason for lesser DC usage; the other being the idea of how the slots are implemented. I like IRC's rotating queues for one file as opposed to the one slot gets all it can philosophy.

That being said, DC is still perfect for me when using it to bulk send to another distributor, and that's why I lobbied for the limiter.

DC++ -is- the base off which other's build. While I do use the lesser clients on-demand, I want my DC++! Seriously, it happens or doesn't, np. But just cast my vote, nonetheless. C u soon, gang!

[cyberal]

Use CFOS, it really works!!

http://www.cfos.de/techinfo/shape_e.htm

During TCP/IP transfer a certain amount of data needs to be confirmed upon reception before more can be sent. Stalling data confirmation results in delays and transfer-rate slowdowns, thus forcing the sender to wait. Especially for ADSL, it is possible to slow a download to a crawl by choking the upstream channel (which has the smaller bandwidth anyway) with an upload. This is because in such a scenario there is hardly any upstream bandwidth left for data confirmation. Combined with other delays in the DSL line, this effect can cause download rates to plunge dramatically.

The Dynamic Traffic Shaping cFos employs analyzes all bidirectional data transfer and prioritizes data packets to avoid congesting the DSL connection, which ensures downloads aren´t slowed down. This results in:

Full download rates during uploads
Full download rates during multiple downloads & uploads
High responsiveness while surfing the Web

[GargoyleMT]

UL bandwidth control was the first reason for lesser DC usage; the other being the idea of how the slots are implemented. I like IRC's rotating queues for one file as opposed to the one slot gets all it can philosophy.

Now this is a point I can also agree with.

[cyberal]

UL bandwidth control was the first reason for lesser DC usage; the other being the idea of how the slots are implemented. I like IRC's rotating queues for one file as opposed to the one slot gets all it can philosophy.

Now this is a point I can also agree with.

Goodbye rar is the first that comes to mind! Rotating queues for 1 file??? that must be the dummest thing i've ever heard.. would take ages to get anything... would never work in a hub with 1000 users! Maybe it's good on small IRC channels where it's tv-eps that are being downloaded.. mp3 album? picture archive... omg!
I agree that the slot implementation today is no good, today the first (read fastest) gets the slot.. should be a slot queue, but when you finally got your slot you should be able to download the stuff you want! That way you can share it yourself faster! If 10 ppl where to download a rar-release 1 file at the time it would take bloody ages until anyone else have the entire release and is able to share it too! STUPID STUPID STUPID!

[ToonGal]

STUPID STUPID STUPID!

It's hard to argue when a cogent point is stated as eloquently as yours. However, I shall endevor to elucidate.

It's obvious we are using it for two different functions. When someone like you is sharing (or receiving) .rXX files, the parts are useless without the whole. In my case, I'm sharing large video files of TV shows/cartoons (100MB - 700MB) in mass quantity.

Just because my idea doesn't suit your paradigm doesn't mean my idea is "STUPID". As a matter of fact, as I stated in my last post, I -like- the idea of bulk distribution to a specific slotted user because that's how I can achieve distribution to a faster re-server.

Regardless of methodology, even then, I don't quite buy your argument. From my experience, just because someone HAS something complete doesn't mean they are more likely to SHARE it. In a game theory sense, I believe that if .rXX files were shared one file at a time, then people would have an INCENTIVE to share their parts, so that they would have a likelier shot at getting their next part. This is the ed2k theory of distribution, and it seems to work well for that network.

I merely said that control is the issue. Had I the OPTION to limit my UL and rotate queues, it would work better for me. I never said it has to be changed for those serving .rar's that want to serve the way it works now. A flexible environment is never a bad one, IMHO.

I won't argue my point / idea any further, because it's obvious a mature discussion is lost on you.