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<72>
|
|||
|
|
position were sent. But it should still work.
|
|||
|
|
|
|||
|
|
What you think?
|
|||
|
|
|