[vcf-midatlantic] A "100%" Efficient BBS Transfer Protocol
chrisjpf33 at gmail.com
Wed Oct 16 19:31:47 EDT 2019
Serial communication always scared me. I wish I understood it better.
On Wed, Oct 16, 2019 at 5:13 PM Bob Applegate via vcf-midatlantic <
vcf-midatlantic at lists.vcfed.org> wrote:
> 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>
> > wrote:
> >> Ahh interesting - is that because a one byte slip/drop might not allow
> >> 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
> > 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
> > 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
> > and this will
> > continue to happen for every successive block.
> > Sending the entire file back the other way would work as a confirmation
> > 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
More information about the vcf-midatlantic