[vcf-midatlantic] A "100%" Efficient BBS Transfer Protocol
bob at corshamtech.com
Wed Oct 16 17:07:22 EDT 2019
That’s what timeouts are for. The receiver should time out because it’s waiting too long for the missing byte. The transmit side has a timeout to re-transmit, so the receive side should also have a timeout to discard the current incomplete message.
Ideally, the dropped byte would generate a framing or other error at the receiving hardware (UART?ACIA/etc) which can also be used to flag the current frame as potentially corrupted.
Or, do as synchronous protocols do and have a unique character that only appears at the start of a frame, never in the data stream. That way if the character is ever seen, it allows the receiver to re-sync and know exactly where it is in terms of frames coming in. If a byte is dropped, the receiver will see the reserved character and know to throw away the incomplete frame and just receive the new one that is arriving.
Synchronous protocols are so much easier than asynchronous ones.
> On Oct 16, 2019, at 2:07 PM, Kenneth Gober via vcf-midatlantic <vcf-midatlantic at lists.vcfed.org> wrote:
> On Tue, Oct 15, 2019 at 7:42 PM John Heritage <john.heritage at gmail.com>
>> 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.
More information about the vcf-midatlantic