Big Muscle

yes, it's true this is false. Pause is maximally 10 ms and you can't lose the slot.

no they doesn't :-P they normally send their filelist to every client which asks for it... but our client doesn't ask for it :)

the only result will be that our client will be banned because of upload blocking :-P ask your hub owner to block these non-TTH clients in the hub

no, I haven't removed anything. a) only simple condition has been added to disallow downloads without TTH tree change hasn't been done by me, but by DC++ developers. that you are crying on a bad grave :)

I agree with you that they should go away from DC, but it should be ensured by hubowners and OPs. And no, they are not leechers, because they don't block anything :)

BECAUSE WE ARE NOT THE LEECHERS!!!!!!!!!!!!! GO AWAY FROM DIRECT CONNECT IF YOU DON'T WANT TO UPLOAD!!!!!!!!!!

because we are not leechers to block uploads ask your hubowner to clock these clients. There's nothint to be removed in the client.

DC is about uploading and not downloading, so we won't block uploads to anyone, because we are not leechers.

Just look at the website of another provider and you will see it :)

does this memory leak disappears from detector when you use your fix? because if you check the code, you will see that "clearUserList()" is called in onClose routine in HubFrame.cpp

yeah! it would be nice option but I don't have much time to write it at this time :)

if I remember well, than apexDC doesn't use overlapping because its code is overriden by super-seeding feature

It works perfectly... erm.. but nothing works perfectly it's just because: a) it works only for sources with known speed it requires that the current chunk would be downloaded below 15 seconds with new overlapping source c) if the source was very fast before, it can be very slow now or it doesn't have to have a slot already but I admit that this feature still needs some improvements especially in forcing the connection to fast sources when there's a slow one remaining etc..

But it's not your right here. DC++ is about sharing and not only about downloading and there's big probability that you will share downloaded files.

it has nothing to do with multisource. It's due to feature Autosearch automatch queue (or how is it exactly called) Also multisource has nothing to do with hubs, so it can't affect them in any way.

no, it's not possible and there's no reason why it should be possible

it's really nice. You take 2x - 3x more slots in network, so many other users aren't able to download anything and it works only A LITTLE BIT faster ^_^

It's your choice. You will get a lot of fake files, corrupted files and you will not be able to download anything from 99% of users. Live with it What's stupid with that? That you can't share fake files? Or that you can't upload corrupted files? Yes, it's really stupid :)

I think, it behaves like fulDC in DC++ emulation mode ;-)

IP address in "External WAN/IP" field is used only when the check "Don't allow override IP" is checked, else it uses IP address which has been used for connecting to hub.

I have something similar in my TODO on my HDD, but it's not to easy to write it.

emulation is to emulate DC++. If you add anything else, then it won't be emulation, so it don't have to be there, because you will be kicked too.

which causes hub overload

it always checked the share before opening else you wouldn't be able to connect to any hub

it was already written - remote client doesn't have full TTH support so we won't download from it. It's a feature and not a problem!