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?