On Tue, Oct 15, 2019 at 7:42 PM John Heritage <john.heritage@gmail.com> wrote:
Ahh interesting - is that because a one byte slip/drop might not allow the CRC algorithm to work properly?
Yes. There are 2 kinds of failures that you need to handle: 1. a byte is corrupted during transmission, and is received incorrectly. 2. a byte is dropped during transmission, and is never received. The CRC will handle the first case with no trouble, but in the second case it won't be obvious to the receiver that the 1024 bytes they got was actually 1023 bytes from the first block (with 1 byte missing), plus the first byte of the second block. So the receiver will calculate the CRC and it will be wrong, which is fine because the first block needs to be retransmitted anyway. But then, the receiver will calculate the CRC for the second block, starting with the second byte (because the receiver doesn't know that the last byte of the first block was actually supposed to be the first byte of the second), which will also end up wrong, and this will continue to happen for every successive block. Sending the entire file back the other way would work as a confirmation of success, but if there are any errors (in either direction) you still need a way to figure out which parts of the file need to be retransmitted and communicate that information to the receiver, which is kind of the same problem all over again. -ken