Bandwidth Throttling

There are many hubs that do not allow their users to use clients that allow bandwidth throttling. They feel that many users would abuse the throttle settings, for example, limiting their upload bandwidth to 1kb/sec while leaving their download bandwidth unthrottled. They feel that this violates the "spirit of the filesharing community".

There are external applications which will manage your bandwidth usage, one such is NetLimiter (I like version 1.30) which will allow you to set limits for your entire computer, individual applications, individual applications processes, and/or individual connections. It also measures and displays network usage statistics (total and application-specific, immediate and longterm), shows process data for each application that uses the network, and shows WHOIS data for indiviual connection addresses. It does not slow my PC down noticeably, and my computer is at 4-5 years old.

There may be other programs that provide the throttling you need, but I do not know their names. One of these may provide what you need.

A hint: If you limit your maximum upload speed at 5-10% below the maximum your internet connection will support, it may help speed downloads, depending on the type of connection you have.

This functionality is neverteless very important.

If you are on Linux/*BSD/etc. (linuxdcpp [DC++ port]) you can only throttle your whole bandwidth and not only the application. But that is useless if you want bandwidth ressources for surfing etc..
Also if there are other PCs using the same internet connection you just cannot work on other things (really nasty).

And the hubowners know that there are lots of other programs around for throttling (at least for win32). It is not a problem of the developers, you should make the app as useable and comfortable as possible.

"NetLimiter is an ultimate internet traffic control and monitoring tool designed for Windows."

Doesn't help us linux users none....

Hopefully this capability will be available soon, in the dc++ core and thereby the linuxdc++ port..

There's always trickle for linux...

Also regarding Netlimiter, i seem to remember it being invasive, injecting it's dll into everything, and causing apps to crash. :P

I tried 'trickle' - didn't work :/

QOS in linux isn't much use for this purpose. Would be much simpler to put the capability into the offending client program (like every other bandwidth-intensive app has nowdays :)

AFAIK, only Netlimiter *Monitor* is free. The actual tool for throttling your bandwidth isn't free. And I don't earn Dollars.

I also support this wishlist item. I'd be ok with having my download speed <= upload speed. Doesn't that solve it?

Furthermore, a general Pause button would be great. Currently, I have quit DC++ just so that I can download email. Then I have to fire it up again when I leave home. Tedious.

Linux is quite capable of shaping traffic, and in my experience the tools are very powerful although it needs more documentation. (My shaping is done using 'iptables' and 'tc')

Please check http://lartc.org for more information regarding shaping bandwidth. Again this is not to limit all uploads to 1kb/s or something equally ridiculous.

See this patch.

After merging with this limiter code, my client started to be very unstable when limiting is enabled. Call stack looks like this:

> StrongDC.exe!memcpy(unsigned char * dst=0x02651f2d, unsigned char * src=0x02f63ba8, unsigned long count=16384) Line 250 Asm
  StrongDC.exe!_ssl3_write_bytes() + 0x3c3 bytes C
  StrongDC.exe!_ssl3_write_bytes() + 0xd8 bytes C
  StrongDC.exe!_ssl3_write() + 0x115 bytes C
  StrongDC.exe!_SSL_write() + 0x7e bytes C
  StrongDC.exe!dcpp::SSLSocket::write(const void * aBuffer=0x02f5bba8, int aLen=1877) Line 138 + 0x19 bytes C++
  StrongDC.exe!dcpp::BufferedSocket::threadSendFile(dcpp::InputStream * file=0x025c6808) Line 351 + 0x40 bytes C++

One more information, it doesn't crash always, but it seems that it disconnects every TLS connection.

This is call stack from DC++

#0 0x77c36fa3 in msvcrt!memcpy () from C:\WINDOWS\system32\msvcrt.dll
No symbol table info available.
#1 0x006b95e5 in do_ssl3_write (s=0x6e5bc60, type=15, buf=0x6d52928 "",
    len=0, create_empty_fragment=112371200) at ./ssl/s3_pkt.c:745
        p = (unsigned char *) 0x6d52928 ""
        i = <value optimized out>
        mac_size = 16421
        prefix_len = 0
        align = <value optimized out>
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I found a reason of problems. OpenSSL documentation says:

"When an SSL_write() operation has to be repeated because of SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, it must be repeated with the same arguments."

But this is exactly what isn't kept. When you enable limiter in "incorrect" time, the length in SSL_write() will be different althought previous operation ended with SSL_ERROR_WANT_WRITE. Old version of limiter changed length only when reading block from disk (i.e. after SSL_write has been completed correctly)

Fixed in version 0.760.