Segmented downloading techniques

[Big Muscle 1]

Sorry if it's look like I'm trying to insult you. Some things are hard for me to tell in English and sometimes I use worst word then I really mean. I only really don't know how to write in english and finally should understand that you solutions aren't acceptable and won't be implemented and I'm too tired that if I write it to you, you still say "Solution is blablabla..".

[Excelsium 0]

I will agree to disagree with Big Muscle and have accepted he will not build the rest of my solution/feature.

I'm also tired of writing so much.

I will reword the opening post sometime so its easier to read and so that it includes the full details listed in recent posts. e.g. including solution 2. is not acceptable if its proven to have a low success rate.

Maybe you will understand my reply to this - I didn't see this post:

If couldn't understand it, I'm trying to explain it in non-computer words.

There is some big hole on the road. You will drive car A and fall to the hole. Your solution is to use car B. You will fall to the hole too! Now understand that your solution is rubbish?

Car A = Information

You can use the information to download the failing file successfully using another method 'Car B.'

- DC++ Normal mode

- Other P2P Client: Bittorrent, eMule and so forth.

This is the last time I'll ask if you understand or not.

1. Car A drives you to Car B.

2. Car B drives you to your destination.

Now do you understand ?

[ifmn 0]

I don't understand what happened with the 'hole', so - no.

What makes you believe there wont be corruption when you download smthng with DC++ ? There's no escape from hardware failure...

- Other P2P Client: Bittorrent, eMule and so forth.

And you want devs to implement them in strong/apex ?

Why do you even continue arguing ? BM clearly stated he wont add your 'technique'...

- Already said that I or someone else will build said feature/solution.

So hes said hes not going to build the simple 'informing the user about the problem' solution - I will or will have a friend do it it for me.

Or maybe someone else will biggrin.gif

[Excelsium 0]

I post just to check peoples understanding and give full explanations.

- I did say its the final time I'm asking him if he understands me or not because I did not see one of his posts before I posted my last reply.

What makes you believe there wont be corruption when you download smthng with DC++ ? There's no escape from hardware failure...

It seems you have ignored Bittorrent etc. although I've not had a visible failure yet with normal mode.

No visible failures yet? Probably because I only use it in 1% of cases - the times when the segmenting download technique fails and the times the files are not available elsewhere such as bittorrent.

Thats with the old solution though, of course I'm open to the 'hole' now with my current solution - I don't have time for manually obtaining Car A any more.

I have successfully driven Car A to Car B to my destination many times already

- when I used to use the current segmenting download technique.

I will automate the process of obtaining Car A.

Also one of the 'holes' is Time waste.

I will make a bridge over that hole.

One of the other 'holes' is bandwidth waste.

I will make a bridge over that hole aswell.

The 'hole' Big Muscle refers to is a corrupted download.

One can jump into this hole to avoid a bottomless pit called time and bandwidth waste - the manual process of obtaining Car A.

- The hole is temporary - you have a corrupted download? try again. 95-99% it will succeed without corruption on the first retry in normal mode.

- 95-99%+ of the users other downloads succeed without corruption so of course it will almost certainly complete without corruption on the first retry.

You can also use bittorrent or whatever.

One of these 'Car B' methods have always successfully brought me to my destination, 99%+ on the first try.

Hence the 'hole' is temporary indeed. unlike the said bottomless pit.

My original title for this thread is perfect.

Detect corrupt file and switch download technique - Thats exactly what I've been doing all this time and successfully - I've been doing it manually - I will automate it.

The Detect corrupt file and switch download technique will enable me to use the segmented download technique in its current form. ** Involves bittorrent etc where possible.

- No I wont implement these other p2p clients inside the client (strong/apex) 'Car A' information I will simply feed into another p2p clients download queue (Manually). The process of obtaining 'Car A' however will be automated.

Summary

1. My technique exists, works - and has been used successfully by myself and others many times already (Manual).

- I don't use it myself anymore because of the time waste caused by it being manual.

2. I will automate my technique.

I don't expect a long reply from Big Muscle.. even 'yes' or 'no' is enough.

If he dosn't reply I will just refer to his last post.

[Big Muscle 1]

I think you haven't understood my car story. Car A was "segmented downloading", car B was "normal downloading". And the hole on the road was a bug in memory/HDD etc. And it meant that no matter which method you will use but you will always fail if you fall into hole.

And it won't switch to normal downloading because it's unsafe. Segmented downloading redownload corrupted chunks (maybe redownloading will never finish) but it doesn't allow to have corrupted file as finished download and that's the most important. Normal downloading has only standard TTH consistency checking but allows corrupted downloads if they get corrupted after sending data to your OS. So why your solution has never been implemented in normal downloading?

[Excelsium 0]

I think you haven't understood my car story. Car A was "segmented downloading", car B was "normal downloading". And the hole on the road was a bug in memory/HDD etc. And it meant that no matter which method you will use but you will always fail if you fall into hole.

And it won't switch to normal downloading because it's unsafe. Segmented downloading redownload corrupted chunks (maybe redownloading will never finish) but it doesn't allow to have corrupted file as finished download and that's the most important. Normal downloading has only standard TTH consistency checking but allows corrupted downloads if they get corrupted after sending data to your OS. So why your solution has never been implemented in normal downloading?

Ahh yes but in 95-99%+ of cases we don't fall into the 'hole' therefore I refer you to my summary:

1. My technique exists, works - and has been used successfully by myself and others many times already (Manual).

- If it dosn't work the first time it will on the first retry (95-99%+) with the same probability of success on subsequent retries if they are required which has never been the case personally.

My success rate in other p2p apps is 99%+ I cant remember the last time I had a problem.

2. I will automate my technique.

[ifmn 0]

Thats luck,maybe after a PC restart strong/apex will download everything correctly.

[Excelsium 0]

Thats luck,maybe after a PC restart strong/apex will download everything correctly.

Lol.. of course I've tried all the usual things. - Possibilities

1. The client cannot repair these files at all

2. The client cannot repair these files at all within a reasonable time period

e.g. left running for days at 10 megabits with small files.

*client: strong/apex.

I've a question:

Since we don't fall into the 'hole' 95-99%+ of the time and 95-99%+ of the users other downloads complete.

Why dosn't the client repair the file when were not in the 'hole'?

- I've other downloads running at the same time in strong/apex.

- Other downloads are completing successfully whilst the failing file continues to fail.

[Big Muscle 1]

Ahh yes but in 95-99%+ of cases we don't fall into the 'hole' therefore I refer you to my summary:

you can't know it. I've already said that the probability of corruption is stll same.

My success rate in other p2p apps is 99%+ I cant remember the last time I had a problem.

Yes, your success rate, but it's only circumstance. For another user it can be viceversa.

[Excelsium 0]

you can't know it. I've already said that the probability of corruption is stll same.

Yes, your success rate, but it's only circumstance. For another user it can be viceversa.

Ok but please answer the questions I posted after.

I will automate my technique because of its success rate in dc++ normal mode and other p2p clients.

Other users have had similar or same success rate.

- My technique is a solution for those users with this set of circumstances.

[Big Muscle 1]

I will never reply to this topic anymore. If you can't understand that the success rate in normal mode and other p2p clients is only a circumstance and it can behave differently for other users, than don't wait any answers from me.

[Excelsium 0]

I will never reply to this topic anymore. If you can't understand that the success rate in normal mode and other p2p clients is only a circumstance and it can behave differently for other users, than don't wait any answers from me.

Yes it is circumstance users with this circumstance will enable my technique.

- We already have done manually - it will be automated.

[ifmn 0]

There's no point in adding something, because of your hardware problems, that could help sometimes to some users.

Edited April 7, 2007 by ifmn

[Excelsium 0]

There's no point in adding something, because of your hardware problems, that could help sometimes to some users.

because of your hardware problems

- Factually incorrect: could be software.

I see value in it because of the success rates I personally experience so I will add it (Automate it) for myself if no-one else.

- I've seen at least a few other users that would benefit.

[Big Muscle 1]

The real fact is that maximum benefit can be reached by fixing hardware problems, then no switching to other methid would be needed and there would be no waste. Dot.

[Excelsium 0]

The real fact is that maximum benefit can be reached by fixing hardware problems, then no switching to other methid would be needed and there would be no waste. Dot.

Incorrect on one point: Could also be software problem as you admitted. (Outside of DC++ client).

- Due to the exponential possibilities it would cause much waste to find the exact cause.

- Hence my technique is a solution* hence I will automate my technique.

* Only for users with high (95+%) success rates with my technique.

- Unless of course its something like iceman50 pointed out - a real bug in the latest version of DC++.

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]

But Excelsium, in terms of corrupted files nor even 99% is acceptible. It will be 99% OK with you, 98% with your peers, 95% with their peers... and will end in crap.

[Excelsium 0]

But Excelsium, in terms of corrupted files nor even 99% is acceptible. It will be 99% OK with you, 98% with your peers, 95% with their peers... and will end in crap.

1. It is accetable (to users of said circumstances) because it wastes less than the redownloading chunk ad infinitum problem. It also brings them to their destination (complete uncorrupted download).

- Redownloading file with (95-99%+) success rate wastes less than said problem.

2. See earlier replies. - It is only used by users that have said circumstances

- It is already used by users that have said circumstances.

- It is and will only be used (enabled) by users of said circumstances.

- The only difference will be that it will be automated.

- Users of said cirumstances who use this technique check their downloads before sharing, they dont share 'crap'.

- Note: The majority of peers in the network use the 'unsafe' download technique 'dc++ normal mode' - it allows corruption.

- People who think its not acceptable for users of said circumstances to use this technique can refer to this and earlier replies. rather than me reposting for infinity.

[Zlobomir 3]

1. It is accetable (to users of said circumstances) because it wastes less than the redownloading chunk ad infinitum problem. It also brings them to their destination (complete uncorrupted download).

No, it is not. Imaging me as such user I would not accept it. And it will be complete CORRUPTED download.

- Redownloading file with (95-99%+) success rate wastes less than said problem.

No, it will count down below 95% progressively (see below).

2. See earlier replies. - It is only used by users that have said circumstances

No, you can't guarantee what will each single user do.

- It is already used by users that have said circumstances.

So it is already a solution for them.

- It is and will only be used (enabled) by users of said circumstances.

No, you can't guarantee what will each single user do.

- The only difference will be that it will be automated.

Thus may deserve a bit of thinking over, however most automatic ideas in soft end bad.

- Users of said cirumstances check their downloads before sharing, they dont share 'crap'.

No, you can't guarantee what will each single user do.

- People who think its not acceptable for users of said circumstances to use this technique can refer to this and earlier replies. rather than me reposting for infinity.

You can refer to the replies of those people (among whose is BM himself ), rather than reposting for... ad infinitum? Oh see, it is the same... We are all posting over and over (making you "restart post"), just in order not to leave a wrong opinion (corrupted download) on the forum (HDD).

[Excelsium 0]

To Zlobomir:

- A Knife can be used to slice bread or to kill people.

Final repost of this note:

- Note: The majority of peers in the network use the 'unsafe' download technique 'dc++ normal mode' - it allows corruption.

- When I run out of explanations and arguments I will indeed stop posting and refer people to my earlier replies.

Refer to my earlier replies.

[Big Muscle 1]

- Users of said cirumstances who use this technique check their downloads before sharing, they dont share 'crap'.

How can you know it? I have never checked what I've shared. It was moved to finished downloads (= it is ok) and I check only whether it is what I wanted to download.

[Excelsium 0]

How can you know it? I have never checked what I've shared. It was moved to finished downloads (= it is ok) and I check only whether it is what I wanted to download.

See the reply I just made to Zlobomir.

[Big Muscle 1]

Note: The majority of peers in the network use the 'unsafe' download technique 'dc++ normal mode' - it allows corruption.

yes, true. That's why there is a lot of "same" files with different TTH and we want to change it.

Also DC++ wants to changes and current SVN contains also rereading last downloaded block from disk and if it's corrupted, it will be redownloaded. And there's no your solution, just a redownloading corrupted block.

Features which may work sometimes for someone is no worth to do. I wish you finally understand it, that if you make your solution, it will only work for you and maybe one other person. And it won't work either for you always but only sometimes. When your HDD moves to corrupted place (if it's HDD error) in normal downloading, you will get corrupted file for normal downloading :)

[Zlobomir 3]

To Zlobomir:

- A Knife can be used to slice bread or to kill people.

Refer to my earlier replies.

True, but for killing a man, apart from the moral side, you know damn well you will spend a good part of your own life in jail, if you got caught. And this is smth you know as a part of your whole process of social integration. And this process is far more longer than DC++ experience.

Actually, you know what it could be? The killing knife could be http/torrent, while DC++ is the "slicing bread" one.

And I am referring to your earliest reply for writing the above, truly believing and protecting my right to think to be right, just as you do.

/off And I have to write at least 5 pages analisys between neokeinsian theory (god of economics forgive me the spelling), monetary theory and neoclassical theory. Btw if smo ACCIDENTALLY has such thing ready, do not hesitate to contact me. It will save me a lots of time and therefore help the project. /off

[Excelsium 0]

yes, true. That's why there is a lot of "same" files with different TTH and we want to change it.

Also DC++ wants to changes and current SVN contains also rereading last downloaded block from disk and if it's corrupted, it will be redownloaded. And there's no your solution, just a redownloading corrupted block.

Features which may work sometimes for someone is no worth to do. I wish you finally understand it, that if you make your solution, it will only work for you and maybe one other person. And it won't work either for you always but only sometimes. When your HDD moves to corrupted place (if it's HDD error) in normal downloading, you will get corrupted file for normal downloading

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

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

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) - and post online. - Because of 3.1.

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

That bug iceman50 mentioned could be one of the causes.:

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