Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Have you heard an anecdote about a noob-programmer and 10 guru-programmers? Guru programmers were trying to find an error in his solution, and noob had already found it, but didn't tell about it, as it was something that stupid, we was afraid to be laughed at.</p> <p>Why I remembered this? Because the situation is similar.</p> <p>The explanation of my question was very heavy, and I decided not to mention some small aspects, that I was sure, worked correctly. (And they really worked correctly)</p> <p>One of this small aspects, was the fact, that the downloaded file was encrypted via AES PKCS7 padding. Well, the decryption worked correctly, I knew it, so why should I mention it? And I didn't.</p> <p>So, then I tried to find out, what exactly causes the error with the last chunk. The most credible version was about problems with buffering, and I tried to find, where am I leaving the missing bytes. I tested again and again, but I couldn't find them, as every chunk was saving without any losses. <strong>And one day I comprehended:</strong></p> <p><s>There is no spoon</s></p> <p>There is no error.</p> <p>What's the point of AES PKCS7? Well, the primary one is that it makes the decrypted file smaller. Not much, only at 16 bytes. And it was considered in my decryption method and download method, so there should be no problem, right?</p> <p>But what happens, when the download process interrupts? The last chunk will save correctly, there will be no errors with buffering or other ones. And then we want to continue download. The number of the downloaded chunks will be equal to <code>currentFileChunkIterator = currentFileSize / delta;</code></p> <p>And here I should ask myself: <strong>"Why are you trying to do something THAT stupid?"</strong></p> <p>"Your downloaded one chunk size <em>is not delta</em>. Actually, it's less than delta". (the decryption makes chunk smaller to 16 bytes, remember?)</p> <p>The delta itself consists of 10 equal parts, that are being decrypted. So we should divide not by delta, but by <strong>(delta - 16 * 10)</strong> which is (304160 - 160) = <strong>304000</strong>.</p> <p><em>I sense a rat here</em>. Let's try to find out the number of the downloaded chunks:</p> <p>2432000 / 304000 = 8. <em>Wait... OH SHI~</em></p> <hr> <p>So, that's the end of story.</p> <p>The whole solution logic was right.</p> <p>The only reason it failed, was my thought, that, for some reason, the downloaded decrypted file size should be the same as the sum of downloaded <em>encrypted</em> chunks.</p> <p>And, of course, as I didn't mention about the decryption(it's mentioned only in previous question, which is only linked), none of you could give me a correct answer. I'm terribly sorry about that.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload