Full file recheck and recheck on resume

[amp 0]

I did a quick n' dirty patch to add this abilities to 0.2.2. Unfortunelly i'm not pro in C++ , so problems still exist:

- Progress bar on file recheck won't show

- Even newly added files are rechecked then temporary file is created

- other things I might not found

Hopefully, you can fix them and include into next release.

Or at least, maybe you'll made this features in the right way.

1.txt

[Big Muscle 1]

I don't see any point why to include $MyInfo spam using switching away mode.

[Crise 26]

I haven't looked into this properly yet but as said by BM there is no point in having the [AWAY] flag in description, especially since it will/may cause many completely useless myinfo's to be sent... which is not good.

[amp 0]

It's my own customization. I've just forgot to delete it from the patch. How about other features introduced?

[Crise 26]

It's my own customization. I've just forgot to delete it from the patch. How about other features introduced?

haven't yet had a chance to go through it properly... as said.

[amp 0]

I'm impatiently waiting your verdict about this features, and will they appear in next release? I'm not holding to my implementation, but on idea.

[amp 0]

:)

[amp 0]

A friend of mine made some fixes and improvements to 0.2.2 version:

1) added [AWAY] into description

2) limiting limits removed *

3) range check error bug fixed

4) slow users bug

5) scrolling bug even if autoscroll is disabled

6) pressing Esc will clear message text

7) some other small fixes and a bit changed VS2005 project files

8) full file recheck on download finish (experimental)

* yes, this edits are forbidden, but we here have very small up and down speeds and we use this version in one and only hub. So just ignore them). I'm just too lazy to delete them from this patch.

Hope you like it and include in next release. This version is MUCH more stable than mine)

1.txt

[Lee 84]

Maybe we can take a look at the fixes. :)

[Big Muscle 1]

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

[Crise 26]

Away tag/flag in description will never be included in official ApexDC++, and same goes for the change related to slow users :)

[amp 0]

Why slow users? And what do you mean by it? Slow users bug means it removes slow sources even if this option is disabled.

[void 0]

it allows leeching by occupying slow segments and eating too many slots

...this is why uploader limits number of available upload slots. Am I wrong?

Now such type of "slow user" disconnecting due to incomprehensible reasons looks like a bug and speeds down download a lot (often removing all sources but one, which can then go offline, effectively stopping download at all). This is really annoying.

[Big Muscle 1]

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

[Zlobomir 3]

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

S*rew a feature that could s*rew a download! Let's assume that the user is not a leecher, after he finish Dd there will be two sources, then 4, etc. And with the "feature" all the Dders are s*rewed up. :)

Edited October 22, 2006 by Zlobomir

[Crise 26]

S*rew a feature that could s*rew a download! Let's assume that the user is not a leecher, after he finish Dd there will be two sources, then 4, etc. And with the "feature" all the Dders are s*rewed up.

Okay, easy....

I'm not 100% certain but what is the most disliked multisource client, i believe it might be reverse connect as revconn doesn't have max segments limited, and I'm not sure but i think it doesn't have this forced dropping of very slow sources either...

Regardless if I'm right with above or not... I believe DC is still more about community and sharing, than downloading as fast as you can.

[Big Muscle 1]

RevConnect has this feature too:

Automatically Recycle Excessive Sources

Congestion avoidance. Prevent users from exhausting precious free slots in the network. There is a dynamic minimum download speed decided by total download connections amount. e.g. 50 download connections require every connection's speed > 2K bytes/s . By this way, users with better bindwidth could download fast, meanwhile poor internet connections could max their bindwidth with minimum tcp connections amount. The principle here is downloading as fast as you can without wastingness.

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.

[amp 0]

Sometimes this even cause that file has no source at all!

[Big Muscle 1]

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

[amp 0]

I believe DC is still more about community and sharing, than downloading as fast as you can.

Oh, believe me, download 4Gb file with 3Kb/s with constantly droping sources is REALLY annoying.

You see, we have not much fast speeds here, actually, most people on our hub have 256/128 connection speed. And we should open 5 slots as it mentioned in our hub rules. So, most sources have speed about 1-2 Kb/s.

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

void can explain better, he made more investigation into this problem. I saw such behaviour, then all sources are dropped :-/.

[Big Muscle 1]

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.

[Zlobomir 3]

Well, I personally never had the issue or never mentioned it. Indeed I am exlusively uploading. But I think amp and void (and others before...) are saying the truth, why you are rejecting so desperately?

P. S. This post may be useless already, but typed before BM's explanation above. :D

Edited October 22, 2006 by Zlobomir

[Big Muscle 1]

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.

[Zlobomir 3]

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.

I'm happy with that. :D

[void 0]

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.

This feature description explains how it should work but not how it works in practice. And in practice I can see the following. A lot of files in download queue and one big file which I want to download first. I set it to high priority. And due to this "feature" after a few minutes I typically receive from one to zero (because this source will eventually go offline) active download sources. For the file I want to download before others. And whether this will happen or not depends on some undocumented hard-coded constants. Oh, this is great feature.

I doubt very much that this feature helps against leachers (while limited upload slots number works pretty well). But IMHO it really hurts to users.