
Heard of this "Imodem" protocol? It's a variant of XMODEM meant
for use over really long lines, where the turn around delay
(approaching 30 secs!) makes ACK/NAK type things not work.

Basically, it sends a stream of unacknowledged numbered blocks,
and at EOF, issues a list of bad blocks which are then resent.
Very nice idea. Of course we have ZMODEM ...

What if: you make this eensy weensy change to ZMODEM. When you
get a bad block, you just remember it (the offset). When you get
EOF (ZEOF), you ZRPOS at the lowest remembered bad offset, get
the data, ZRPOS at the next highest, then when all blocks are OK,
ZRPOS to EOF or whatever it is that ZMODEM uses.

Only the receiver needs to be changed. The change would still be
completely ZMODEM-Forsberg to the letter and spirit correct. This
relies on the regularity of ZMODEM, plus the fact that the sender
issues ZCRCW blocks (wait for ACK) after a ZRPOS, ie. after an
error.

For example: you have a 10,240 byte file, to send as ten 1024
byte blocks. Sender whizzes all the data out, then issues a ZEOF.

Now the receiver got CRC errors on blocks 2 (offset 2048) and 7
(offset 7168). When it receives the ZEOF, it does a ZRPOS to
2048; the sender will resend starting with that offset. When that
block is received OK, the sender does a ZRPOS from 7168, the
sender does it's usual. When all is well, the receiver does a
ZRPOS to the previous EOF (or whatever mechanism) and the file
transfer is completed.

	----

The ZMODEM code and spec calls for (under all the right, and
usual, circumstances) ZCRCG blocks, ie. fully un-acknowledged,
but that after an error, a ZCRCW block is sent, which requires an
ACK. This scheme would work, but be less effecient, if the sender
immediately did ZCRCG's after the re-position to the bad part, as
data beyond the bad block would be sent, and would probably slow
down things when a second (in this example the ZRPOS 7168) re
position were sent. But it should still work.

What you think?

