Upload Speed Limiting

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

Moderator: Moderators

Should DC++ Have Upload Speed Limiting to Manage ADSL Connections.

Yes
108
61%
No
68
39%
 
Total votes: 176

Menchi
Posts: 18
Joined: 2003-01-10 06:52

Post by Menchi » 2003-01-10 07:46

DC is a community who’s only limitation is upload speed.
The slots system worked with this, a control is needed to finish it.
I would _prefer_ not to have a user connect to me with a u/d ratio slowing down their download from MY computer.

Seriously, the only reason I use a bandwidth limiter is so I can upload without the pain. Only people who want to upload can benefit from an upload limiter.

It will _not_ hurt anyone else since the cheaters already have pre-compiled versions.
“... real leeches and fakers prefer ‘slot lockers’...� is the best way I’ve seen it put.

What I would like to see is some sort of dynamic per slot guarantee.

Currently I give 30k/3 slots using the .181 client

This works great when I have 3 people that can download at 10k.
Even better, they don’t get "bullied" out by the more aggressive connections.

If a modem (or some poor soul that has ADSL but isn’t using a bandwidth limiter) connects to me then a bit of my upload is wasted. So why not guarantee bandwidth for the slower connections while _smoothly_ capping the most aggressive ones.

e.g.

30k/3slot = 10k/s
slot1,2,3 = 10k
total = 30k

60k/3slot = 20k/s
slot1 = 20k (maxed)
slot2 = 5k (56k)
slot3 = ~3k ('unlimited" ADSL)
total used ~27k

If the ADSL connection decides to disconnect/kick/remove slots in order to start downloading then the total raises above my limit and DC++ adjusts.

46k/3slot = 12k/s
Slot1 = 12k (maxed)
Slot2 = 5k
Slot3 = 12k(maxed)
----
29k


As for you Swedish people, I don’t care about you, just don’t bother the developers. Stay in your own hubs and set up a bot to kick anything but B:* and "unfamiliar" IP's like you have been doing anyway.

I just want to share.

~ I’m the op [email protected] (Upload: 197.23 GB, Download: 35.53 GB)

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2003-01-10 08:34

hasn't this thread died yet?

i general see upload-limiting as something bad. And i'll continue todo this.

i-haven't-yet-seen-anything-in-this-thread-that-is.going-to-change-my-mind-ly'ers.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

maniak
Posts: 21
Joined: 2003-01-05 06:01
Location: Warsaw, PL

Post by maniak » 2003-01-10 14:42

ivulfusbar wrote:hasn't this thread died yet?.

It didn't and it WON'T. Even if moderators would delete it, it will come back, sooner than later.

ivulfusbar wrote:i general see upload-limiting as something bad. And i'll continue todo this.

i-haven't-yet-seen-anything-in-this-thread-that-is.going-to-change-my-mind-ly'ers.

The day any other client with similar features plus limiting comes out, I'll say goodbye to DC++. If the developers want to make sure most ADSL users will not use their program, it's their choice. Just wait some and the DC++ will come back into "exotic clients" category. Is that what you want?
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone. (karb on /.)

maniak
Posts: 21
Joined: 2003-01-05 06:01
Location: Warsaw, PL

Post by maniak » 2003-01-10 14:45

Menchi wrote:I just want to share.

Apparently, you want too much. :x
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone. (karb on /.)

Menchi
Posts: 18
Joined: 2003-01-10 06:52

Post by Menchi » 2003-01-10 16:44

The day any other client with similar features plus limiting comes out, I'll say goodbye to DC++. If the developers want to make sure most ADSL users will not use their program, it's their choice. Just wait some and the DC++ will come back into "exotic clients" category. Is that what you want?


http://alyandon.hypermart.net/
http://utrum.dyndns.org:8000/
http://dcpp.netfirms.com/

Enjoy ;)

as long as i'm spamming url's
http://abma.x-maru.org/guide/
http://www.doom9.org/

rtfmoz
Posts: 25
Joined: 2003-01-08 02:14

Post by rtfmoz » 2003-01-12 04:53

Suggestions for upload limiting implementation...

Non-Idle Network Upload Limiting;

Network traffic - DCC Traffic = 0 then switch off upload limiting
Network traffic - DCC Traffic != 0 then switch on upload limiting if specified.

Excluding Netbios and DNS traffic from the counts this should allow DCC to run unlimited until someone is trying to access the Internet.

It would be ideal for the ADSL user.

Regards

Romeo Tango Foxtrot Mike

maniak
Posts: 21
Joined: 2003-01-05 06:01
Location: Warsaw, PL

Post by maniak » 2003-01-12 13:24


I know these very well. I have to...

Problem is their limiting is far from perfect nad since they are not the official distribution, some people consder them hacked.

I don't care much about the latter, but the barely working limiting code is a problem. Set limit to 12KB/s, get upload at anywhere from 12 to 15KB/s (my "download is fucked" point is somewhere close to 13). Set it lower, and the operators complain.

In fact latest version of BCDC++ is worst in this regard :-(
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone. (karb on /.)

maniak
Posts: 21
Joined: 2003-01-05 06:01
Location: Warsaw, PL

Post by maniak » 2003-01-12 13:24

rtfmoz wrote:Suggestions for upload limiting implementation...

Non-Idle Network Upload Limiting;

Network traffic - DCC Traffic = 0 then switch off upload limiting
Network traffic - DCC Traffic != 0 then switch on upload limiting if specified.

Let's suppose I leave DC++ running and go to sleep. Limiting code turns off, since I do not generate other network traffic while asleep. Now instead downloading at decent speed, for the whole night it downloads at 2-3KB/s, because unlimited upload saturates the upstream.
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone. (karb on /.)

rtfmoz
Posts: 25
Joined: 2003-01-08 02:14

Post by rtfmoz » 2003-01-12 20:33

Good point,


Bandwidth is based on flows. Bytes / second for everything.

Variables
TotalBytes/s = total available bandwidth per sec
TotalAckBytes/s = bandwidth required for acks of downloads per sec
UploadBytes/s = what is left for uploads per sec
NoOfUploadThreads = total number of uploads
ThreadBytes/s = bytes available for each thread per second
Thread#CountBytes = total bytecount available for sending per thread
Thread#PacketSize = packet size per thread

Functions
QueueThreadPacket = subroutine to queue a packet for a thread

Speedlimited would be TotalBytes/s - %20

Pseudo Code
; How much bandwidth available for uploads?
UploadBytes/s = TotalBytes/s - TotalAckBytes/s
; How much per upload thread?
ThreadBytes/s = UploadBytes/s / NoOfUploadThreads

; Do we send a packet for a particular upload thread?
; Must be completed within a second.
For each UploadThread {
; I get more bytes for this thread for sending
Thread#CountBytes = Thread#CountBytes + ThreadBytes/s
; If I have enough to send a packet then queue it
While Thread#CountBytes > Thread#PacketSize {
QueueThreadPacket
Thread#CountBytes = Thread#CountBytes - Thread#PacketSize
}
}

I am not a professional programmer so this does not take into account issues with timing in a programming environment.

Regards

Kevin Davies

dbloom
Posts: 2
Joined: 2003-01-13 17:36

This is not just a problem for ADSL users

Post by dbloom » 2003-01-13 17:43

Many cable ISPs cap their uploads too (@Home did, and so does my current ISP), almost all at 128kbps. It seems this is the 'universal cap'. I think the DC++ client should have an option to cap downloads at 64 kilobits/second - no more, no less. 64kbps is not unreasonable, and I don't think it would even need a mention in the <++ thing. Normally, DC++ drags down my cable connection to an unreasonably slow level. I don't run DC++ except when I need something, for this reason. I would share more, and I'm sure others would too, given this option.

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

Post by ender » 2003-01-14 02:29

What about people who have faster connections? What if they, too capped their DC++ to 64 kbps?

szbali
Posts: 1
Joined: 2003-01-14 05:23
Contact:

About the Upload/Download paradigm

Post by szbali » 2003-01-14 06:36

Hi
I have some thoughts and experience about this subject, so I will share with you now:
There is clear need for fixing this issue, as many of you have indicated (by votes also).
But it is a technical or ethical problem :?:

Who needs it:
- Many users who has slower (ADSL) connections. If you go around and check, most of the users in most of the hubs has DSL connections set. Many of the has the slowest version (256/128, 512/256, 1024/512, or faster). In most of the cases, the upload speed is less than the download speed, let's say twice. And this would not be a problem either, because (lets take the slowest one) it is acceptable to have a download/upload ratio of 25k/12k ( a movie this way takes about 8 hours). But because DC++ does not uses the bandwidths optimally, this ratio arrives to 4k/12k or worse, just because of 12k which goes out. If the upload is killed, the download is going back to 25k. So it is clear that not the download source but the local upload which slows the download

Who does not needs it:
- Users who has fast connections. They should be :D , because they are fortunate to have access to a fast internet, and not because they pay for it (who the hell can permit its own T1 or T3)?

Who is afraid of having an upload speed limitation :evil: :
- Users who has fast connections and downloads from other users who has fast connections.

Current solutions to upload speed limitations:
Because downloading a movie which would take 78 hours, has no sense and everybody is looking for his benefits, the upload speeds are limited anyway by the following methods:
- kill the upload
- leave the hub (not all the users has the setting kill-download-when-exit-from-hub)
- change frequently the username
- share files what nobody needs
- share files renamed in various languages, far less people can find something interesting to download
- there are some unofficial versions with speed limitations, but using those, you may get banned in some hubs.
- rules of hubs are broken constantly, and even if it is discovered and banned, because having ADSL, the IP number is changing in time, this risk is acceptable too.

Most of the users are happy to share and they would be proud when somebody is downloading from them, but in a give-and-get sense. There are few who has everything what it wants, no need for download, just offer for everybody. This is not "Red Cross without frontiers"...
Everybody should profit from this, even those who does not needs, are not interested, or maybe are offended by this, because it would contribute to the common good.

Solutions:
- The optimal solution would be, of course, to do not limit the upload, but remove as much as possible its effect on the download.
- To have a setting which limits the upload kBytes .This is drastically, but the easy way, but some of you may be against it.
- More the priority to download instead of upload (it seems that after a login, all the users who are uploading are connected, with full speed, later comes the download with the strangled bandwidth)
- The upload speed is limited by the download speed (determined statistically). Possible user intervention: Enable / Disable. After it is enabled, the ratio of maximum upload/download ratio should be determined and used for limitation.


Have a good day

eHast
Posts: 18
Joined: 2003-01-09 02:36
Location: Lund, Sweden

Post by eHast » 2003-01-14 14:55

Regarding upload/download limits on high-speed networks.

Here in Lund the student network is almost collapsing because of the high load. Last summer the network was connected to Sunet with Gb speeds, and this was the last drop. Some of the network links are now so satuated that you get transfer speeds in the 10k area.

Considering that it's 10-100Mbit this is quite annoying. And it's quite possible that eg DC has to be off for the rest of the world because of this. (Ie no out or incoming DC connections allowed.)

I bet that this will sooner or later become a problem at other places. The only way to stop it from going critical is to either make it possible to regulate bandwidth or to make the programs clever enough to throttle themselves. (The latter is naturally very comlicated.)

Having central bandwidth limiters is not really possible for these types of networks as it would cost way too much.

maniak
Posts: 21
Joined: 2003-01-05 06:01
Location: Warsaw, PL

Post by maniak » 2003-01-14 19:02

Paradox wrote:576/256 ADSL

This ADSL connection is more balanced than most so doesn't suffer so much from the crushed downloads that most do. However it is still noticeable that downloads don't utilise the bandwidth as well as they could, and throttling the upload speed to about 30K/s (since the max is 32K/s) would probably allieviate this problem.

This also depends on the details like use of PPPoE... I had 256/64 ADSL and it worked without need to limit. Now I have theoretically better 512/128 but it's using PPPoE. Nothing worse was ever invented. Dies completely without limiting :-(
Paradox wrote:Limiting on a per slot basis is what is needed here. With limiting set at 100K/s or 150K/s it would probably function fine even though the maths adds up to more than the total bandwidth because you are unlikely to use all your bandwidth for each slot unless you are in a purely 10Mbit hub and then you'd use a different set up.

Conclusion

As you can see there is need for upload limiting no matter what connection you have. There is of course the posibility that it will be abused (and I'm sure it is with the hacked clients already), but the people that need fear the abuse (or should that just be use) of upload limiters the most are 10Mbit leechers that only care about getting the fastest downloads possible.

Per slot limits would be probably the best. Even better would be some way to detect unused bandwidth and redistribute it over the slots (eg. modem user on one slot, taking 2KB/s and the remaining per slot allocation is given to other users; but this would be IMHO very difficult to do properly).

If not that, simple limiting would help immensely.

Problem is that Arne fears abuse too much and apparently he doesn't need this feature personally. Take a look in the feature tracker under "features that will not be implemented'... :-(
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone. (karb on /.)

Cyber Boss
Posts: 1
Joined: 2003-01-15 18:00

Post by Cyber Boss » 2003-01-15 18:47

I would guess that anyone who has used an Internet connection with a low capped upload speed (ie 128K) would not oppose an upload bandwidth limiter. Upload saturation brings my system down to a craw. My experience is that allowing upload bandwidth up to 75% of it's capacity greatly increases downloading bandwidth, Internet surfing, etc, without affecting the upload speeds very much.
8)

rtfmoz
Posts: 25
Joined: 2003-01-08 02:14

Post by rtfmoz » 2003-01-15 22:24

Whats the bloody point if they dont READ the feedback.
Why have a goddamn forum at all?

Arne?

Menchi
Posts: 18
Joined: 2003-01-10 06:52

Post by Menchi » 2003-01-16 02:43

If there are any developers reading this, lets keep the rants down to a minimum (myself included) and give them a good idea of what we want.

Why is an upload limit is needed?

- prevent people from using non-standard clients
- keep group/shared connections sane (e.g. 10mbit)
- lag/choke problems not fixed with the small send buffer
- encourage people to share instead of kick
- painless to stay connected all the time

Requirements: (did I forget any?)
User set limit
- no reliable way to determine the connection
- % bandwidth may be needed for other reasons
Standardized tag
- allows hub operators to filter out slow connections
- "hacked" clients will be less common (no need to compile your own)
Per slot limiting
- prevents a single connection from taking over
Auto increase k per slot (up to limit)
- dealing with 56k connections
- "wasted" bandwidth should be kept to a minimum
Smooth limiting
- versions based Alyandon's mod fluctuate around an average (bad)
- ping times should not be affected
- makes online games possible (usually needs only 5k & a good ping)

Abuse:
- limit set too low (why?)
- tag removed using non-standard client (already a problem)

OLDoMiNiON
Posts: 202
Joined: 2003-01-06 06:22
Location: Salford, England.
Contact:

Post by OLDoMiNiON » 2003-01-16 07:31

ok, do you realise how many thousands of posts have been made on this issue? and how many times arnie has said NO?!?!
he has his reasons, and in my mind, they are good ones!

OLDoMiNiON
Posts: 202
Joined: 2003-01-06 06:22
Location: Salford, England.
Contact:

Post by OLDoMiNiON » 2003-01-16 08:01

ok, didn't read the whole thread b4 i said that.. a lot of you are putting forth some good ideas and suggestions!
however i doubt that arnie will go along with it.. :(

Iceman[grrrr]
Forum Moderator
Posts: 58
Joined: 2003-01-03 11:30
Location: Québec, Canada
Contact:

Post by Iceman[grrrr] » 2003-01-16 10:02

rtfmoz wrote:Whats the bloody point if they dont READ the feedback.
Why have a goddamn forum at all?

Arne?


I read all posts everyday... I'm just not the one saying what will and won't be implemented... however, he may change decision some day so don't despair!
DC++ QoS Person

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-01-17 07:28

I also experienced another problem. I normally had about 15 users downloading from me at decent speeds, however every now and again a user on the same acedemic network as me connected. The result at this point was one 500-800K/s upload and 14 other slow or stalled ones. This is definitely not fair on those other 14 users, especially if some of them were getting 100K/s and are now running at 10K/s.


I think, this is perfectly fair as guy on the fast network quickly get what he want and then he will stop slowing down others and will make the slot free.
In fact very few of fast users keep downloading large amounts of data from single source. I'm one of those fast ones and I know what I'm talking about. The problem is, that there is so many lusers, who prefer to disconnect me instead of waiting until I download one damn mp3 album. Of course it is almost impossible to get such user banned on hub, because he disconnects manually and ops will not notice. However I managed to get some of them banned when thay made a mistake and disconnected fast op or when I had op's trust .
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM

Menchi
Posts: 18
Joined: 2003-01-10 06:52

Post by Menchi » 2003-01-18 11:20

yilard wrote:I think, this is perfectly fair as guy on the fast network quickly get what he want and then he will stop slowing down others and will make the slot free.
In fact very few of fast users keep downloading large amounts of data from single source. I'm one of those fast ones and I know what I'm talking about.


I disagree, once they find out they can download from you fast they go into leech mode and queue all (hub required) 20 gigs on your share. There will never be enough bandwidth.

but thats not the point

I'm happy to share as fast as I can, but not at others expense. In fact, wasted (unused) bandwidth is a big concern especially when considering limiting, but if 2 cable connections start downloading off me either one can max my upload. What happens is that one will tend to squish out the other ... till one times out. Talking to both people downloading off me found no reason for this to happen (nobody was downloading off them, they both had good connections etc). Switching to the per sot .18 mod evened things out. I am fairly happy with this mod but would like a more current version that can deal with 56k users as well.

dbloom
Posts: 2
Joined: 2003-01-13 17:36

Proxy?

Post by dbloom » 2003-01-18 14:48

How about no upload capping, but making DC++ act as a proxy for your browser to go through? That way, it could intelligently allocate bandwidth to your internet connection, while not leaving much room for abuse.

ted
Posts: 3
Joined: 2003-01-19 14:17

Post by ted » 2003-01-19 16:13

In my opinion using DC++ as a HTML proxy is no solution. One of the reasons is that many users need to use another, external, proxy - for instance me to gainm access to certain servers through the University proxy.

For at the developers may do something without too much effort (and I than you all for the effort of developing this good client!), we have to have something reasonable simple and understandable solution.

I have a fast cnnection, and have not experienced any enormous problems, but just enouhj to make me to feel that something should be done.

Some ideas:

Why not a fairness algorithm for starters, allowing the less utilized slots to have slightly higher internal priority, so that nobody can squeeze others out by monopolizing the line capacity? It is NOT same than fixed speed per slot scheme!

Maybe a feature of capping the speed would be also necessary, in spite of any misuse risks. It seems that all kinds of "leecher-friendly" versions and mods are anyway available even ready compiled for the incompetent (but selfish) kiddies to install. If the capping parameters are transmitted to the HUB, a script there might detect any major suspicious setting and thus potential misuse (for eample that max UL speed is ridiculously low)

Ted

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-01-21 05:36

Maybe a feature of capping the speed would be also necessary, in spite of any misuse risks. It seems that all kinds of "leecher-friendly" versions and mods are anyway available even ready compiled for the incompetent (but selfish) kiddies to install.


Now only few people use modified client because they either don't know about possibility or because modified clients patch versions lag too much behind official dc++ released (the patch for current dc++ version is issued quite late). As only few users use it, suspicious ones can be quite easily detected and banned.

If upload limiting would be part of official distribution 95% of people would limit upload! And then who will bother with detecting who does not limit upload who does?

If the capping parameters are transmitted to the HUB, a script there might detect any major suspicious setting and thus potential misuse (for eample that max UL speed is ridiculously low)


These can be simply faked.
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM

LordAdmiral
Posts: 13
Joined: 2003-01-03 23:25

Post by LordAdmiral » 2003-01-22 23:11

IMHO, implementing an upload limiting feature is a very bad idea. Leeching should not be condoned whatsoever, in any manner or fashion possible. It isn't a matter of DC++'s reputation, but a question of the file sharing system itself. I [i]will not[/i] share on a network with 75% leechers. My school's hub has such a ratio of leechers to sharers. Heck, there are people who're sharing their whole HDD's--all 500MB, the min share of the hub. Therefore, unless a friend specifically requests a movie from me, I refuse to enter the hub, regardless of how fast it may be.

Back to UL. There is no sense in implementing it. It'll make every legit hub force everybody to use NMDC, and that is most certainly not an option I'd like. By, then everybody would be doing it because everybody else is doing it, and DC will go straight to hell.

To the ADSL users: If you're scared of downloading a 5KBps whenever somebody fast uploads from you, then I'm certain you'd be even more afraid of downloading at 5KBps from everybody all the time, which would be the result should you have your way. Besides, DSL users should not have 8 slots open anyway.

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

Post by ender » 2003-01-23 02:43

Some people just don't get it - without the upload limiter I had to close uploads all the time when I wanted to download something, with it I could let them be, and since I started using it my ul:dl ratio went from 0.90 to 2.2...

Menchi
Posts: 18
Joined: 2003-01-10 06:52

It hurts to share

Post by Menchi » 2003-01-23 15:41

Now only few people use modified client because they either don't know about possibility or because modified clients patch versions lag too much behind official dc++ released (the patch for current dc++ version is issued quite late). As only few users use it, suspicious ones can be quite easily detected and banned.


latest version of BDC++ is .22 and came out the same week as DC++ .22

LordAdmiral:

In practice I have not seen people abuse this feature, in fact the opposite is true (see below). If an ADSL user has the need to cap their connection to 5k they can probably only upload at 10k anyway. I'd rather see them cap it than drop me repeatedly, disconnect, and fake share.

Some people just don't get it - without the upload limiter I had to close uploads all the time when I wanted to download something, with it I could let them be, and since I started using it my ul:dl ratio went from 0.90 to 2.2...


Exactly, this fixes the sharing problem. Upload limiting takes away the need to be greedy. Before a good upload mod, my ul:dl ratio was below 1, now its 5.74 ... that’s nearly 6x more sharing than before! Another way to look at is 215GB-215/5.74 = 175 GB more than I would have shared with normal DC++.

maniak
Posts: 21
Joined: 2003-01-05 06:01
Location: Warsaw, PL

Post by maniak » 2003-01-23 16:01

ender wrote:Some people just don't get it - without the upload limiter I had to close uploads all the time when I wanted to download something, with it I could let them be, and since I started using it my ul:dl ratio went from 0.90 to 2.2...

You see, since we don't have a terabyte of hottest stuff to share, 1000 slots and OC-3 line, we're just random losers to them. Our troubles have no significance to them.

And modified DC++ clients are popping up... It's only the question of time before someone makes an Ultimate Leech Edition. But since they want it soo bad...
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone. (karb on /.)

maniak
Posts: 21
Joined: 2003-01-05 06:01
Location: Warsaw, PL

Post by maniak » 2003-01-23 16:05

yilard wrote:
If the capping parameters are transmitted to the HUB, a script there might detect any major suspicious setting and thus potential misuse (for eample that max UL speed is ridiculously low)


These can be simply faked.

If they are in standard distribution 99% of people won't bother to hack client or use any other trick. If they are forced to use modified clients because it's not in the standard, you simply encourage them to hack the client or use some evil hacks that someone might produce.

It's a day or two to get compiler from warez d00dz, 15 minutes to get source, and maybe a hour to add a lot of nasty stuff. Real nasty, like slot locking (that's one line in code!), hidden limiting (get bcdc++ source and rip off B: tag), share "inflation" a'la dctc (add xGB to share amount)... force people to compile their own, you'll get a lot of bad stuff.

This kind of fanaticism tends to yield results exactly opposite to expected.

and by the way, as I already wrote once: Want people to stop bitching about limiting? Send them the money to buy and operate a business class link. They won't need it then. Oh, don't want to/don't have few million to spare? Why not stop pretending there is no problem then?
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone. (karb on /.)

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-01-23 17:52

maniak wrote:
yilard wrote:
If the capping parameters are transmitted to the HUB, a script there might detect any major suspicious setting and thus potential misuse (for eample that max UL speed is ridiculously low)

These can be simply faked.

If they are in standard distribution 99% of people won't bother to hack client or use any other trick. If they are forced to use modified clients because it's not in the standard, you simply encourage them to hack the client or use some evil hacks that someone might produce.


You are not right. It is easy to modify hypotetic client with upload limiter to report faked info about limit. But it's quite difficult to implement upload limiting. So faking can be done easily for lamer, but upload limiting is not as easy implemented and existing modified client versions are very lagging behind official release, which is good. Authors of leeching mods for some reason are unable to keep up with current releases, which is also good. So people can either use newest official software or use outdated buggy modified versions.

It's a day or two to get compiler from warez d00dz, 15 minutes to get source, and maybe a hour to add a lot of nasty stuff. Real nasty, like slot locking (that's one line in code!), hidden limiting (get bcdc++ source and rip off B: tag), share "inflation" a'la dctc (add xGB to share amount)... force people to compile their own, you'll get a lot of bad stuff.


It's no that easy for lamer to do that nasty stuff. And now it is quite easy to detect cheating users and get them banned. This is what I do with everyone who cheats or keep disconnecting me for whatever reason. Btw. i'm not interested in their u/d ratio, ADSL or whatever. It is so easy to PM me and ask not to overload their connection now and I would wait until they don't need the bandwith (e.g. till night). But they almost always prefer to cheat. So I don't want another weapon in their hands. period.

PS:
Note that even slot locking can be really simply detected. I'm going to come with an idea which can kill all slot lockers for some time. I need just some time to consider things.
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM

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

Post by sarf » 2003-01-24 07:10

yilard wrote:[snip]It is easy to modify hypotetic client with upload limiter to report faked info about limit.

True.

yilard wrote:But it's quite difficult to implement upload limiting.

Untrue. Exact upload limiting is more difficult to implement than inexact limiting. Inexact limiting takes about 3-7 minutes to add to the program.

yilard wrote:So faking can be done easily for lamer, but upload limiting is not as easy implemented and existing modified client versions are very lagging behind official release, which is good.

If all you want is an upload-limited version then you can hack one together within minutes of receiving and unpacking the latest source distribution. Most authors of DC++ variants want more, however (as I do). I consider upload limiting a useful feature for people with asymmetrical bandwidth, but it is not an essential feature for me. I do, however, limit download to four times the upload limit - this in an attempt to make the lazy would-be leechers work for their hard earned 1 byte/s upload limit with no strings attached.

yilard wrote:Authors of leeching mods for some reason are unable to keep up with current releases, which is also good. So people can either use newest official software or use outdated buggy modified versions.

Well, not that it is relevant, but the reason I lag behind in my versions are that I am but one person who modifies code when it reaches the public. I thus have no chance to be up-to-date. I also consider some of the changes in the new versions of DC++ to be interesting but not vital (not vital enough to scrap my old code and go to the new code only to see arne release a new version two days later).

yilard wrote:[snip]It's [not] that easy for [lamers] to do that nasty stuff. And now it is quite easy to detect cheating users and get them banned. This is what I do with everyone who cheats or keep disconnecting me for whatever reason.

Not that easy? It is very easy to add nasty things to DC++. I had the slotlocking in my code (but #ifdef:ed so that it didn't end up in the normal binary) just to check it out (and check out detection).
By the way, how do you detect cheating users, if I may ask? I am very interested in this as some methods can be defeated quite easily.

yilard wrote:Btw. i'm not interested in their u/d ratio, ADSL or whatever. It is so easy to PM me and ask not to overload their connection now and I would wait until they don't need the bandwith (e.g. till night). But they almost always prefer to cheat. So I don't want another weapon in their hands. period.

So easy to PM someone? What if it isn't you, but a leeching bandwidth sucker that just *has* to get that Scooby Doo theme music you have made yourself and won't listen to reason, but *will* report you if you close his/her connection all the time.

yilard wrote:PS:
Note that even slot locking can be really simply detected. I'm going to come with an idea which can kill all slot lockers for some time. I need just some time to consider things.

Slot locking is a stupid thing to do. A more effective way is slot lying (e.g. saying that you have more slots than you really do). Make sure that you have at least one "true" slot and upload limit to some reasonable amount, say 3-4 kb/s and claim that others are leeching all your bandwidth. This should work often enough (not tested in RL).

Sarf
---
The Rule of Fives states that all things happen in fives, or are divisible by or are multiples of five, or are somehow directly or indirectly related to five. The Rule of Fives is never wrong.

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-01-24 07:41

Maybe I have been a little bit hasty and savage when I dismiss all reasons to limit upload. I can agree finally with most points sarf presented.

Some additional comments follow:

By the way, how do you detect cheating users, if I may ask? I am very interested in this as some methods can be defeated quite easily.


I'm not a hub owner just user so I try to kill just leechers harassing me. I'm not interested in cheaters not leeching from me.

In fact I'm very picky when downloading stuff. I prefer 0-day releases and most of the people sharing quality stuff are certainly no cheaters. So I rarely have to do with real cheaters. I'm not greedy so I would not commit suicide if some leecher get 1GB from me while I'm sleeping.

First of all I ask every fast user downloading from me at a fast rate >100k/s to let me look into their file list and/or download something interesting. In fact I'm not interested in snails, because my connection is quite instable, especially in winter :( - optical wireless you know - and they will lose their slots soon.

If anyone doesn't respond to PM and I see him to start downloads, repeatedly disconnecting I try to get him banned or I leave the hub so he will not get what he want. I'm online 24/7 so I can return anytime and continue my downloads.

"File not found" guys get banned also very quickly.

Slot locking is a stupid thing to do. A more effective way is slot lying (e.g. saying that you have more slots than you really do). Make sure that you have at least one "true" slot and upload limit to some reasonable amount, say 3-4 kb/s and claim that others are leeching all your bandwidth. This should work often enough (not tested in RL).


My idea would require slight addition protocol and would also block slot lyers. Shortly it is based on cross-checking downloads/uploads on clients. Maybe this could be done from time to time or upon request.
But currently it is in very early stage of forethinking so it is very probable, that it turns out not to be viable due to additional tasks (and load) required by hub or simply because it may tend to return false positives.

Btw. how many people on the public hubs are slot locking or slot lying according to your estimates?
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM

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

Post by sarf » 2003-01-25 11:44

yilard wrote:[snip]I'm not a hub owner just user so I try to kill just leechers harassing me. I'm not interested in cheaters not leeching from me.
[snip]

Ah. Alright.

yilard wrote:First of all I ask every fast user downloading from me at a fast rate >100k/s to let me look into their file list and/or download something interesting. In fact I'm not interested in snails, because my connection is quite instable, especially in winter :( - optical wireless you know - and they will lose their slots soon.

This was one feature I had hoped DC++ would have put in from the start - that downloading from you would automatically mean granting a slot to you.

yilard wrote:If anyone doesn't respond to PM and I see him to start downloads, repeatedly disconnecting I try to get him banned or I leave the hub so he will not get what he want. I'm online 24/7 so I can return anytime and continue my downloads.

I see. From what I understand, if a user repeatedly disconnects your upload without responding to PMs or whatnot you take action. A reasonable way to do things, but this means that the slot lyers would still get away.

yilard wrote:"File not found" guys get banned also very quickly.

Hehe, very few modified clients use this method to prevent downloading. It is stupid and very easy to notice.

yilard wrote:My idea would require slight addition protocol and would also block slot lyers. Shortly it is based on cross-checking downloads/uploads on clients. Maybe this could be done from time to time or upon request.

Ah, you mean cross-check all downloads/uploads within a hub. An interesting idea... but quite hard to do unless you
  • forbid DC++ clients from being in more than one hub
  • forbid any client other than your own, "homegrown" client in the hub
  • employ some sort of "trust" calculation (otherwise clients controlled by the same user could be connected to each other, thus checking out fine)

    yilard wrote:But currently it is in very early stage of forethinking so it is very probable, that it turns out not to be viable due to additional tasks (and load) required by hub or simply because it may tend to return false positives.

    Depends on how it is coded. I'd guess it would be very restrictive as well as extremely hard to implement - mainly because many users still use old DC++ versions and have no reasons to upgrade.

    yilard wrote:Btw. how many people on the public hubs are slot locking or slot lying according to your estimates?

    On public hubs: about 5-10% are using some sort of "cheat" to decrease the amount of data to upload
    On public, non-policed hubs: about 10-20%

    These are guesstimates, and only as good as I can guess based on my observations.

    On an other note, the percentage of modified clients are increasing (as far as I've seen). There are quite a few people who use my client (DC++k) but who do not cheat. I do not say that they are a majority, but they do exist. It stands to reason that other people use the modified clients based on their non-cheat-related features, too.

    Sarf.
    ---
    You can't lick the system, but you can certainly give it a damn good fondling...

LinkSync
Posts: 31
Joined: 2003-01-26 02:54
Contact:

WOW! This one got lit up eh?

Post by LinkSync » 2003-01-26 03:58

Nice to see an active forum again!

I run TREEHOUSE and my client shares from the same machine.

I would LOVE SLOT THROTTLES!

when Filetopia had them it was really good. my main concern is sharing out (serving) files. and MOST users in the world are still dial up...
So i would love to set a cap that the broadband guys would hate (they are all lousy greedy leeches anyway) and then they can just get unhappy and go away and open up a slot for some nice dial up person who would be very happy to see a solid 5k rollig down there pipe.

To me slot throttles is a basic configuration tool and any so called abuse or harm from it woudl be handled as always by all the users and hubs anyway. PEER PRESURE WORKS! rules dont and design only frustrates when it doesnt enhance choice and freedom.

I agree with everybody here!
If u want an abortion go ahead.
And if u dont then have the baby!
choice
sweet sweet reasonable freedom of choice
*grin*

remember wise man say:
Person that fly upside down have crack up!"
TREEHOUSE.dns2go.com:411
[email protected]
Good Warez LINKS @ www.tree-house.info

tdowning
Posts: 4
Joined: 2003-01-26 17:14

Post by tdowning » 2003-01-26 18:01

I can only see one thing that would drive me back to WinMX, and that is the lack of a bandwidth limiter. WinMX has a BWL that works, and works well. I have watched the bandwidth window in WinMX, and compared it to Netstat Live, (www.analogx.com) and could clearly see when the upload spiked and then dipped, and slowly recovered. Setting up the BWL, the throughbut was dead level.

Everybody gets an equal piece of the "Pie" but if someone can't use all of theirs it gets divided evenly among the rest. and the threads/queue window shows you that everybody is getting equal BW.

Menchi
Posts: 18
Joined: 2003-01-10 06:52

Post by Menchi » 2003-01-27 01:55

tdowning wrote:Setting up the BWL, the throughbut was dead level...
... divided evenly among the rest.
.


Amazing! I haven’t bothered to try WinMX yet but I think I’ll take my shares over to it ... there must be tons of ppl just leaving this ap on all day with no worries.

I only have 30k to divvy up but I'm sure some people will be grateful.


I do like the DC network for a few reasons
-slot system first come first served is appealing
-the community that hub organization and chat creates
-searching/ease of use (tried setting up IRC and gave up)

CerthasIM
Posts: 10
Joined: 2003-01-26 15:52

...

Post by CerthasIM » 2003-01-27 12:15

Not seeing this thread I opened another one but wouldlike to voice my opinion here, too.

And Upload Limit is needed for various reasons mentioned above. Most of all nobody really cares about upload speed normally. If I allow 96KBit/s of my 128Kbit/s upload I don't lose anything, so I'm likely to do it.
After allif someone downloads from me it frees upload capacities elsewhere which I could use for my now intact download again.

I benefit from uploading even as a primary downloader.

Now ideal would be a sollution where it's not the users call to enter the limit but where it's automatically set to 75% of the max speed.
This would eliminate abuse and solve almost all issues.
The technical difficulties of this approach are not known to me, so I can only speak from anabstract position.
When I cast my vote for "Yes" I have something like this in mind and notneccesarily a hard user setable limit.

COLYPTiC
Posts: 7
Joined: 2003-01-28 01:54
Location: USA
Contact:

Post by COLYPTiC » 2003-01-28 03:00

OMG, this is a popular topic in this forum

I have a pretty slow cable connection 1.5mb/256kb and I'm running at 180KB/32KB most of the time if I keep my uploads to 4 or less, any more will slow my dloads down becuase of the overflow of ACK packets. All I had to do is raise my recieve buffer in the registry. With the standard XP recieve buffer (around 27000) I'm lucky to hit 100KB down no even if I had just one upload.

DC++ I think handles ACK packets and bandwidth very well if you raise the registry's recieve buffer and use small send buffer in DC++, alot better than any other P2P program I've used and about as good as FTP.

Adding an upload limiter (bandwidth throttle) would just encourage leeches that you see on the other P2P networks that have upload limiters, NOO!!!!

Even though BCDC++ and some other mods have it, its not allowed in many hubs and if you get caught you usually get banned for a good reason, its almost as bad as faking your share. Too many people would abuse it.

I think a good alternative to the horrid upload limiter would be to add a better send/recieve buffer ratio in the source code. This would let people who don't know or don't want to raise there recieve buffer in the registry.

Having a little spare b/w for ACK packets is good, but the right send/recieve buffers is better.

LinkSync
Posts: 31
Joined: 2003-01-26 02:54
Contact:

Post by LinkSync » 2003-01-28 17:49

WOW! good thread here!
OK guys heres a thought.
I run a hub from same machine i run my client.
I want to protect the qos of the hub for users.
also i want to share files.

The biggest worry i see is ppl worrying about the flaming leeches what will kill there uploads altogether rather than share.

so in fainess we need TWO features!
upload throttles and a client side USER BAN.

that way if for any reason i'm not wanting to serve u files anymore i can chose to ban u from mine.

this would be filesharing only and not chat related so u could swear at me still :)

the chat version would be IGNORE...

*grin*
TREEHOUSE.dns2go.com:411
[email protected]
Good Warez LINKS @ www.tree-house.info

Snooze
Posts: 119
Joined: 2003-01-26 13:42
Location: Denmark
Contact:

Post by Snooze » 2003-01-28 18:00

Im not sure its such a good idea to leave it up to the users to ban leechers. This WILL be abused !! And isnt that why we have ops ?

Snooze
Posts: 119
Joined: 2003-01-26 13:42
Location: Denmark
Contact:

Post by Snooze » 2003-01-28 18:05

btw ...good thinking CerthasIM !!! it sure would be the best solution if the client would set it to ex. 75 % of the max limit or have it as an option like the "use small buffer" feature !

tdowning
Posts: 4
Joined: 2003-01-26 17:14

Post by tdowning » 2003-01-29 19:05

Menchi wrote:I do like the DC network for a few reasons
-slot system first come first served is appealing
-the community that hub organization and chat creates
-searching/ease of use (tried setting up IRC and gave up)


I think the QinMX queuing system is better, because you can see how many ppl are ahead of you, it will tell you remotely queued ## and as time goes by that number will go down, at 0 your transfer starts

AlleyKat
Posts: 40
Joined: 2003-01-31 15:37
Location: Denmark

Post by AlleyKat » 2003-02-02 01:25

Well - I think this discussion is getting summed up pretty nicely, actually.

Theres a majority for the bandwidth-capping, but a lotta fuzz about how to implement it... why not cut the discussion real short and implement a low-level 90-95-97% up/down limiter - I just want it wide enough (and 3-5% is enough on most DSL lines - and not exactly a heavy limitation even on high speed lines) to let my emails trickle through and my Messenger to stay online. That's ALL I ask. And, I'm pretty sure, that's all MOST users ask.

I really LOVE DC++ and will (and do) share all I can - so please don't force me back to fakeshare systems like Kazaa, just to keep my IM's online. And don't let me get tempted by experimental bandwidth cappers and "blue" versions. Gimme just that liiiittle bit o' bytes needed.

I know it'll take time & thinking implementing it, especially as it should not easily be tampered with, and should 'cap in a fair way'.

Could a method be a more detailed connection setting, so the capping could work from that? This way, 'cheaters' could still lie their bw bigger but would also 'feel the consequences', as the capping limit would be beyond their actual line speed. I see the problem in testing for cheating the other way around (say claim 512/128 when reality is 512/256), but I'm pretty sure there's a bright mind with an excellent idea out there somewhere.

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

Post by sarf » 2003-02-02 05:08

AlleyKat wrote:[snip]Theres a majority for the bandwidth-capping, but a lotta fuzz about how to implement it... why not cut the discussion real short and implement a low-level 90-95-97% up/down limiter - I just want it wide enough (and 3-5% is enough on most DSL lines - and not exactly a heavy limitation even on high speed lines) to let my emails trickle through and my Messenger to stay online. That's ALL I ask. And, I'm pretty sure, that's all MOST users ask.

Yes. The problem is how to detect what 95% of your connection is.

AlleyKat wrote:I really LOVE DC++ and will (and do) share all I can - so please don't force me back to fakeshare systems like Kazaa, just to keep my IM's online. And don't let me get tempted by experimental bandwidth cappers and "blue" versions. Gimme just that liiiittle bit o' bytes needed.

I am working on a version that will have upload limiting, but which will cap your downloads at four times your upload.

AlleyKat wrote:I know it'll take time & thinking implementing it, especially as it should not easily be tampered with, and should 'cap in a fair way'.

Unfortunately this method will only, if ever, be used in DC++ as the modders already have implemented capping using other methods (e.g. using a somewhat inexact form of limiting).

AlleyKat wrote:Could a method be a more detailed connection setting, so the capping could work from that? This way, 'cheaters' could still lie their bw bigger but would also 'feel the consequences', as the capping limit would be beyond their actual line speed. I see the problem in testing for cheating the other way around (say claim 512/128 when reality is 512/256), but I'm pretty sure there's a bright mind with an excellent idea out there somewhere.

I sure hope so, 'cause I am coming up dry at the moment. More connection types could help, but what is really needed is a fast and reliable way to detect the amount of bandwidth that the user has available.

Sarf
---
There are three magical words that make everyone feel happy... 'no compilation errors'.

CerthasIM
Posts: 10
Joined: 2003-01-26 15:52

Post by CerthasIM » 2003-02-02 08:55

Could we figure out the max speed by a burst executed at the initialisation of the connection?
Establish the connection, send burst for 2 seconds, meassure the 2nd second transfer rate and take 75-90% of this.
(I hav an highly assymetric but in Germany unfortunately common 768/128 connection so I don't think 95-97% willbe sufficient for me...)

CerthasIM
Posts: 10
Joined: 2003-01-26 15:52

Post by CerthasIM » 2003-02-02 08:58

Uhand sorry for the double post but Cryptolitic, could you give details on what one has to do there exactly? Is this relieably possible in Win98 as well?
And how exactly does the buffer size alievate the problem, anyways. My (naive) understanding was that buffers help with lag but that this is a bandwidth issue to boot.

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-02-02 11:29

CerthasIM wrote:Establish the connection, send burst for 2 seconds, meassure the 2nd second transfer rate and take 75-90% of this.

send to whom?

you'd need to have someone who has the download capacity of your upload. and immediately.
this means you would need a dedicated 100mbit (or so) user who only has one download slot; and who can't do anything else with his connection.

and _every_ hub would need one of those.... or would you set up a 100Gbit main server for _all_ dc users?

undoable afaict
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

CerthasIM
Posts: 10
Joined: 2003-01-26 15:52

Post by CerthasIM » 2003-02-02 15:54

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.

Locked