Segmented downloading techniques

[Big Muscle 1]

a) If DC++ fixed its download technique so it dosn't allow corruption I feel several people will put effort into finding the root cause(s) of this issue (they could be software or hardware)

there was no bug, so it couldn't be fixed. Only checking mechanism has been improved.

If someone gets corrupted file with segmented downloading, it's not bug of segmented downloading.

If someone gets corrupted file with normal downloading, it's not bug of normal downloads.

Both download methods work as expected. Corrupted files mean bug in the PC and not in download mechanism.

Btw I've already asked you, but don't remember whether you replied. Why don't you complain to Microsoft that Windows' copying allows corrupted files???

And onemore thing. Why are you the only one with corrupted files wanting some your solution?

Yes, you pointed to some threads where people complain about corrupted files. But why no other person with corrupted files writes to this topic asking for your solution???

Maybe there's currently no other user with corrupted files.

Maybe those users in other threads managed to fix their computer problems, don't have corrupted files, so they don't need any your solution.

[Excelsium 0]

Big muscle replies for #158 and #159 are in my post #157.. I need to shorten it a little perhaps.

Finished cleaning post #157.

Nm.. cleaned some more :)

[Big Muscle 1]

2. DC++ download technique in its current state does allow a corrupted download to complete.

no, it doesn't. You still don't understand the case of corruption.

DC++ allows only 100% OK downloads. Corruption occurs when the file is stored on your HDD which has nothing to do with downloads.

Neither Windows itself handle such kind of corruption. It's only our good will that we does it.

[Excelsium 0]

Reply to #161:

DC++s method allows a download with a corrupted temporary file to complete.

StrongDC++s method detects that the download has a corrupted temporary file and does not allow the download to complete. (Redownloads chunk ad infinitum if itself cannot repair the corrupted temporary file.)

I will edit #157.

[Big Muscle 1]

System Windows allows file copying with corrupted files

I can remember that long time ago I got a corrupted HDD (I think that cache was corrupted). Everytime I tried to copy big file (small files was ok) to this HDD, it ended in infinite file copying (as remaining 5 minutes, 10 hours, 10 days etc.) and noone cared about this problem. It was my fault, that my HDD was corrupted, so why anyone could anything with it.

[Excelsium 0]

#163: StrongDC++ technique does not allow this, DC++ does

- You've said DC++ may change its technique so that it too does not allow downloads with corrupted temporary files to complete.

- I've corrected #157.

- as said in #157 the root cause(s) will probably be discovered and posted online because the amount of users experiencing the redownloading chunk problem will increase if DC++ changes its technique in the way described.

- I also acknowledge that my techniques are completly obsolete if the root cause(s) are discovered.

- The bug(s) is unidentified and is located somewhere in my machine (hw/sw)

- And/Or in the latest DC++ client.

- My technique is a workaround for that bug to download a file successfully without corruption in 1-5% of cases where I cannot with StrongDC++s segmented download technique.

[balder 1]

It seems you have ignored Bittorrent

seeker has already said that he had the exact same problem with uTorrent so bit torrent has not been ignored.

You have also said that

I can of course do this myself, others can too.

now i took this to read that you could provide a patch to the SDC project to fix your issue, if so do so. This is an opensource project after all.

At the end of the day it appears that everyone who trys to talk to you ends up going round in circles. I think that your argument has been made and BM's has also been made. I have read the entire thread (it took a while) and i don't believe that BM has missed much from not reading your posts (more then likely because he did read them just not thourally). What i have noticed is that since pretty much the first page of (currently 9 thats #164 posts) i haven't seen anything new. BM says its hardware and wont be fixed by him (something i agree with) and you say it would be nice to have a feature to check files after they have been downloaded, this could possibly be a good feature but at the end of the day i think it is not something that will be used to much. it will take a lot of effort to implement and BM has already said it wont happen. I would therefore vote for this thread to be locked again and if lee hadn't already unlocked it would probably be locking it myself. I would however but in place a rider that if crise wants to respond it hould be reopened

[Excelsium 0]

#165:

- About bittorrent: my technique is only valid in said circumstances. when the user has reliable high success rate using other methods.

- The thread was never locked.

- Your right, we've made our arguments.. my most relevant I feel are in #157 and #164

- Yup I may release a 'patch' if the root causes are not found... at the moment only a few would use it.

- Would probably be never required if DC++ changed its technique because I feel the root causes would be discovered.

[Big Muscle 1]

- About bittorrent: my technique is only valid in said circumstances.

yeah, you finally understand it. And this is the reason why it won't be implemented.

[Excelsium 0]

#167: I've always understood its only valid in said circumstances.

correction to implemented 'automated' - its already been used by myself and others with said circumstances.

- Agreed it wont be automated by you and probably not by anyone else reading this except myself - And if the root causes are discovered soon enough, not by myself either.

- See #157,#164,#166

*I guess its ok if your refering to the implementation of the automation

I'm done. more posts would be reffering to #157,#164,#166 etc and this one I guess.

and you say it would be nice to have a feature to check files after they have been downloaded, this could possibly be a good feature but at the end of the day i think it is not something that will be used to much

- Probably only valid for DC++ normal mode in its current state.

That would be nice to deal with the small percentage of downloads that have been 'completed' but for whatever reason turn out to be a corrupt copy of the file the user tried to copy 'download' from a peer.

Match TTH of just completed download to the one put in the queue.

In fact that would probably go a long way to solve the problem of many TTHs for same filename

- Also just corrected #157 some more.

[Zlobomir 3]

My answer to your post no. 157 then:

1. StrongDC++s segmented download technique does not allow a download with a corrupted temporary file to complete.

This is very nice, since corrupted temp file comes either from a problem in Dd PC, or from a corrupted source file at the peer.

2. DC++s download technique in its current state does allow a download with a corrupted temporary file to complete.

This is very bad, since it allows the spreading of corrupted files over the network.

3. If DC++s download technique is changed so that it does not allow a download with a corrupted temporary file to complete:

3.1. The amount of users who experience the redownloading chunk problem will be increased.

3.2. I feel several people will put effort into finding the root cause(s) of this issue (they could be software or hardware)

The users could fix their problem if the root cause(s) are discovered.

I feel the root cause is discovered - hardware problem or corrupted source file.

That bug iceman50 mentioned could be one of the causes.

Be specific as you are with your post nos., iceman50 has mentioned a lot of... things.

[Excelsium 0]

#169: By causes I mean:

The root causes of the corrupted temporary file that is beyond repair by the DC++ client.

- The exact specifics of the 'bug' in which the user can take action to 'fix the bug' so they can use the segmented download technique in its current state with a 99.99999999%+ success rate.

I dont believe the root causes have been proven yet - they could be hardware or software such as Windows XP. - the exact specifics have not been found.

- or a combination of hw and sw bugs.

just a theoretical solution nothing to be 100% fix but it is possible maybe, i just found a new connection fix for DC++ 0/699 with the sockets causing problems under windows

[Zlobomir 3]

#170

Even if causes are not proven, worse, we can not act on blind.

Regarding sockets - with all my respect to coders as knowing more, I do not think sockets have something to mess here, and I doubt also that iceman50 has written this in such context.

[Excelsium 0]

#171: Agreed, my technique is only valid for me and a small group of other users with said circumstances.

- That group may grow if DC++ changes its technique as said in #157

- If the exact actionable specifics are discovered to 'fix the bug(s)', my technique is not valid and made obsolete.

Until the exact actionable specifics to 'fix the bug(s)' are known I'll use my technique in its automated form when/if I get around to automating it.

[Zlobomir 3]

#172

The technique to "fix the bugs" would be our team traveling worldwide and inspecting/fixing problems in each separate PC with the said problems. I would gladly consider doing this on your expenses. :)

[Excelsium 0]

#173: I believe the bugs would be very similar or the same across the affected machines

Making it easy to discover the exact location in a specific machine and fix a particular machines hw /sw or combination.

- If bugs cannot be discovered or fixed then my technique in its automated or semi automated form is valid for this small group of users with said circumstances.

- The group may grow in size as said in #157.

[ifmn 0]

It aint our job to find problems in ppl's computers, dc is for dl/ul,chating and so on (p2p stuff)

[Excelsium 0]

#175 see #157: 3.2. and 3.1.

[ifmn 0]

Apex/Strong does it job correctly, your hardware f*cks up things...

[Big Muscle 1]

- If bugs cannot be discovered or fixed then my technique in its automated or semi automated form is valid for this small group of users with said circumstances.

So use it in your mod for that small group. Call that mod for example "Strong/Apex Mod MAYBE I will help you", BUT WE WON'T IMPLEMENT IT, SO DON'T ANNOY US WITH IT.

[Excelsium 0]

#177: I agree partially: It is either bug(s) in hardware or software or a combination that stops 1-5% of downloads from completing* using SDC++ segmented download feature.

*1-5% in my case and in several other users cases.

*Percentage of failing/failed downloads may vary in other bugged machines.

I think I've said this already, I'll refer to this post if I see I need to make the same reply again.

Or just not reply, my reply is here .

#178: Agreed. except on the title for the mod/patch/etc.

[Zlobomir 3]

Nice. Peace! :)

[Greg 0]

Closed.

If as you say, it is resolved, then locking should not be a problem.

This is unacceptable. Private/one-on-one conversations are to take place in PM, as suggested.

[Excelsium 0]

Results of testing.

0.2.2. Corrupt temporary files are repaired with 1 chunk redownload - havn

[Crise 26]

Excelsium:

I have merged your post to this topic, and now I see that this issue is resolved, for now anyways...

Please no further queries that are directly related to this topic, thank you.