Big Muscle

only latest Common Controls for Win9x is needed + unicows.dll which is available with DC++/StrongDC++

it can't be disabled... StrongDc++ (so also ApexDC++) and also DC++ work on Win9x correctly.

vista will become final when its SP1 is released )))

it should be hub problem, because if you see the message, it means that it comes to hub and hub sent it to you but not to some users.

I had a similar idea in the past but it was related to Line speed visible in Connection column.

ok, it wastes about 800kB for 95 files but you wouldn't be able to download 95 files so fast with normal method because you lose your slot in short time. And it has already been said that multisource downloading is designed for fast connections only so there's no reason to complain that it downloads about 800kB more per 95 files.

when one chunk claps on another chunk, the download must be disconnected and reconnected to download another chunk from that user. And when it disconnects, another user can "steal" your slot btw clients like Valknut are much worse, because they send new $ADCGET every "TTH-leaves size" (usually every 64kB)

Revconnect always sent one $ADCGET which causes losing a slot at the end of chunk. 2munki: where did you get thess numbers? they are absolutely false.. what is 4500x ? $ADCGET will be sent 48 times per file for 47.68mb and if one $ADCGET command has 80 bytes, it wastes only 3,8 kB (8 kB counting also $ADCSND) and it's much better than losing a slot after segment and waiting a few days for slot from someone and then lose it again. and CZDC is being banned in a lot of hubs if someone enables to block segmented uploads.

maybe you said "Could you please", but from the content of your posts flows that we must, because you want it, so write your own client with public CVS.

amp, could you show some law which says that CVS must be available? that developer has to release new build when you say that you want it??

hidden users/bots are included in this number too

it doesn't work on slow connections in such way, because real speed of users decreases. Theoretically it should works like some users think, but according to many tests it works in that way only on fast connections, so auto-disconnecting is protection to abuse segmented downloading on slow connections. Manual slow downloads disconnecting is there if someone wants higher limit than it's default.

"leeching" isn't real word which can be used here, because leeching is about uploading. It's hard to me to explain it in English, but there's one simple fact - you should use minimum slots as possible and not all available slots. A lot of people thinks that if they download one file from five users then the the slots will be released 5x sooner, but it's closed to true only on really fast connections.

there's on big difference - on slow connection you will occupied slots of all segments for a very long time. And you should also realize that slow connections coulnd't be able to handle more connections and it's speed will decrease. But I don't know whether I've already mentioned it. The automatic very-slow sources removing is bad, but there's no other possibility. "Slow speed" should be based on your real download without dependency of upload speed of remote side, but it's not technically possible to get your real download speed, so it's done as it's done ;)

2amp: you forgot to highlight some words yes, of course, you can use it on slow connection, but then you should except some problems, because we don't want to have situation that all slots will be eaten by slow users. it's like you would think that your bicycle will be faster when you will be allowed to ride it on a highway.

it's to take the advantage of fast connections (1Mbps isn't suitable for it yet, should be higher)

i have never said that you should upgrade your network. I just said you shouldn't use segmented downloading.

I won't comment your text now, because I don't have much time now. But I will be serious now, so sorry for my following words - are you kidding that you are use segmented downloading on such slow connection????? that's your problem and not in slow download disconnecting.

what connection type do you have??? On my 5MB it doesn't slow down anything and only brings the faster downloading and more free slots in the network. Segmented downloading is done for fast connection to download from more fast users and not to occupy every each slot in network with zero influence.

if it happens it's not due to veryslow downloads disconnecting, but there must bug elsewhere and it should be fixed by different way and not by removing this feature.

yes, if you enable slow download disconnecting with speed below 5kB/s and every segment will be 5kB/s than all sources will removed. But it has nothing to do with this auto-disconnecting.

no, it can't, because it removes source only if there's other downloading source.

RevConnect has this feature too: and it doesn't screw your downloads, it only disconnects very slow sources if you are using segmented downloading. But I understand that leechers want to use every slot which they can, so there won't be any free slots for other user.

it's not the bug but feature which ensure that you will not use too many slots for one file!!!

hmm, interesting patch... but clients using it should be banned, because: a) it allows to spam with $MyInfo when minimizing/restoring it allows leeching by occupying slow segments and eating too many slots