46 lines
2.0 KiB
Plaintext
46 lines
2.0 KiB
Plaintext
|
||
Heard of this "Imodem" protocol? It's a variant of XMODEM meant<6E>
|
||
for use over really long lines, where the turn around delay<61>
|
||
(approaching 30 secs!) makes ACK/NAK type things not work.
|
||
|
||
Basically, it sends a stream of unacknowledged numbered blocks,<2C>
|
||
and at EOF, issues a list of bad blocks which are then resent.<2E>
|
||
Very nice idea. Of course we have ZMODEM ...
|
||
|
||
What if: you make this eensy weensy change to ZMODEM. When you<6F>
|
||
get a bad block, you just remember it (the offset). When you get<65>
|
||
EOF (ZEOF), you ZRPOS at the lowest remembered bad offset, get<65>
|
||
the data, ZRPOS at the next highest, then when all blocks are OK,<2C>
|
||
ZRPOS to EOF or whatever it is that ZMODEM uses.
|
||
|
||
Only the receiver needs to be changed. The change would still be<62>
|
||
completely ZMODEM-Forsberg to the letter and spirit correct. This<69>
|
||
relies on the regularity of ZMODEM, plus the fact that the sender<65>
|
||
issues ZCRCW blocks (wait for ACK) after a ZRPOS, ie. after an<61>
|
||
error.
|
||
|
||
For example: you have a 10,240 byte file, to send as ten 1024<32>
|
||
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<74>
|
||
2048; the sender will resend starting with that offset. When that<61>
|
||
block is received OK, the sender does a ZRPOS from 7168, the<68>
|
||
sender does it's usual. When all is well, the receiver does a<>
|
||
ZRPOS to the previous EOF (or whatever mechanism) and the file<6C>
|
||
transfer is completed.
|
||
|
||
----
|
||
|
||
The ZMODEM code and spec calls for (under all the right, and<6E>
|
||
usual, circumstances) ZCRCG blocks, ie. fully un-acknowledged,<2C>
|
||
but that after an error, a ZCRCW block is sent, which requires an<61>
|
||
ACK. This scheme would work, but be less effecient, if the sender<65>
|
||
immediately did ZCRCG's after the re-position to the bad part, as<61>
|
||
data beyond the bad block would be sent, and would probably slow<6F>
|
||
down things when a second (in this example the ZRPOS 7168) re
|
||
position were sent. But it should still work.
|
||
|
||
What you think?
|
||
|