例如：
发送器要发送：”爸爸的爸爸到底叫什么呀丫鸭压？” ----->>>>>给接收器
逻辑如下
发送器：问---接收器可以接受什么类型的数据
接受器：回---我可以接收“xxx”这几种类型的数据
发送器：发---文件名称、大小、日期....
接收器：回---准备好接收文件了，发过来吧！(重传暂时不讨论)
发送器：发---数据内容如--->>> “爸爸的爸爸+ZCRCG(结束符合)”
发送器：发---数据内容如--->>> “到底叫什么+ZCRCG(结束符合)”
发送器：发---数据内容如--->>> “呀丫鸭压？+ZCRCE (数据最后一个结束符合)”
发送器：发---数据已经发完+ZEOF(数据最后一个结束符合)”
接收器：回---收到，是否发送新文件？(ZACK和CRC通过)
发送器：发---要终止会话
接收器：回---同意终止
实际程序是这样的逻辑：
| ZMODEM 发送器 | ZMODEM 接收器 | 帧类型 |
|---|---|---|
| 发送器请求接收器发送它的初始化参数 | ZRQINIT=0 | |
| 接收器以提供它的大多数能力的帧进行响应 | ZRINIT=1 | |
| 发送器提供要传输文件的名称，以及关于长度和日期等可选数据 | ZFILE=4 | |
| 接收器请求文件数据再某个位置开始。对于新文件这一般是位置 0 | ZRPOS=9 | |
| 发送包含所有文件内容的单个数据帧。所有数据子包以 ZCRCG 结束，最后一个例外，它以 ZCRCE 结束 | ZDATA=10 | |
| 发送所有数据，并指明了文件尾 | ZEOF=10 | |
| 接收器指明已经准备好开始接收新文件 | ZRINIT=1 | |
| 发送器指明它要终止会话。如果发送器有更多文件要发送，它将再发送一个 ZFILE帧 | ZFIN=8 | |
| 接收器同意而连接中断 | ZFIN=8 |
ZMODEM的帧：ZMODEM发送器和接收器之间传递的所有信息都包含在数据包中(在ZMODEM 中称数据包为帧)，即使是简单的协议协议信息（比如确认信号）也在数据包中。
十六进制报头：
ZPAD ZPAD ZDLE B FrameType ZF3 ZF2 ZF1 ZF0 CRC1 CRC2 CR LF XON
1. ZPAD ZPAD ZDLE表示帧的开始
2. 字符 B 用于表示十六进制报头
3. frame-type表示帧类型
4. ZF3 ZF2 ZF1 ZF0：是4个字节的信息，当帧类型不同时，它的含义也不同
5. CRC-1 CRC-2为校验码
注意：在 B 字符------------CR/LF/XON 序列之间，所有字符都是
十六进制编码的，这意味着每一个字节使用两个字符的可打印值。
ZRQINIT＝0：
当 ZMODEM 发送器启动时，它发送这种帧。它是请求接收器发送它的 ZRINIT帧，该帧将开始文件传输。ZRQINIT 帧头可用于在接收程序中触发一个自动下载。ZRQINIT 帧不发送任何数据子包。如果发送器试图发送一个命令给接收器，头字节 ZF0 包含常量 ZCOMMAND；否则它包含一个 0。
ZRINIT＝1:
接收器发送这种帧以指明它准备好从发送器处接收文件。可以自发地发送它，或者应答 ZRQINIT 帧。这个帧具有 4 个字节地能力信息包装在报头中。ZF0 和 ZF1 的下列位可以进行设置和清除，这要取决于接收器的能力。
CANFDX＝1:接收器具有确实的全双工操作，意味着它可以同时发送和接收数据。
CANOVIO＝2:接收器在写磁盘时可以接收数据，要充分利用 ZMODEM 的流特性，就需要这种能力。
CANBRK＝4: 接收器可以发送一个中断信号。
CANCRY＝8: 接收器可以解码 RLE 帧。应用例中不支持这种能力（Omem Technology
可能把这种能力看做对 ZMODEM 的专有扩展）。
CANLZW＝16: 接收器可以解压缩 UNIX 压缩式的数据。这种能力在应用例中不支持。
CANFC32＝64: 接收器可以接受 CRC32，应用例不支持 CRC32。
ESCCTL=64: 接收器需要看到所有控制字符转换码，而不是仅 XON/XOFF 等少数几个。
ZF2 和 ZF3 包含接收器输入缓冲的尺寸。如果这个值是非零的就意味着接收器不能在完全的流模式中工作。相反，当它向磁盘写数据时，它将停止接收。
ZSINIT＝2：
在处理 ZRINIT 帧后，这个帧可以被发送器有选择地发送给接收器。它提供给接收器一些信息而不管接收器的能力。两个位装入 ZF0。
TESCCTL＝64: 此位用于指明发送器期望所有控制字符都进行转换
TESC8＝128: 此位用于指明发送器期望转换 8 位。ZMODEM 没有完全实现这种能力，但包含在未来改进的规范中。仅有一个数据子包跟随在报头后面。这个子包包含不超过 32 个字符的字符串，以空字符终止。这个字符串用于在出错时唤醒发送器。
ZACK＝3:
这种帧类型用于确认 ZSINT 和 ZCHALLENGE 帧，以及其后跟随 ZCRCQ 或ZCRCW 终止符的数据子包。如果应答是给 ZCHALLENGE 帧的，4 个报头标志字节由ZCHALLENGE 报头所发送的 4 个字节副本来填充。
ZFILE＝4:
这种帧类型用于初始化实际的文件传输。它包含一个报头，后面跟随单个数据子包，子包包含文件信息。4 个报头字节中填入了与要传输文件有关的各种标志。ZF0 包含文件转换选项；ZF1 包含可选的管理选项；ZF2 具有传输选项；ZF3 包含扩充选项。这个帧考虑的选项最多，而且很少使用。对于我们的目的，在 ZFILE 帧中传送的重要项是文件名称、长度及可选的日期。在此详细说明选项的其余部分是为了完整性。
ZF0 可以设置为下列值之一，它们指明存储文件数据时使用的转换方法。
ZCBIN＝1:
二进制传输，数据不需要转换。
ZCNL＝2:
使用本地约定转换接收行的结尾。这个选项在 UNIX 和 MS－DOS 之间发送 ASCII文件是有用的。
ZCRESUM＝3:
从中断的文件传输中恢复。接收器检查目标文件是否比发送的文件短。若是，文件传输可在异常终止的地方重新开始。
ZF1 可以设置为以下的数值。
¾ ZMNEW＝1: 只有在源文件更新或更长时覆盖目标文件。
¾ ZMCRC＝2: 对比源文件和目标文件的 CRC。如果数值相同，传输文件，否则跳过传输。
¾ ZMAPND＝3: 把源文件追加到目标文件。
¾ ZMCLOB＝4: 如果目标文件存在，则无条件的覆盖目标文件。
¾ ZMSPARS＝5: 如果目标文件存在，只有文件比较新才覆盖目标文件。
¾ ZMDIFF＝6: 如果目标文件存在，只有文件的长度或日期不同才覆盖目标文件。
¾ ZMPROT＝7: 这个选项与 ZMCLOB 相对。它告诉接收器只有在目标文件不存在时才传输文
件
ZF2 可以设置为以下的数值。
ZTLZW＝1: 要传输的数据经过 UNIX 压缩程序压缩的。在应用例中不支持这个选项。
ZTRLE＝3: 数据是使用 Run Length Encoding 压缩的。通过创建专用的 RLE 帧，在 ZMODEM后来的版本中，这部分规范被取代。丢失的选项 2 属于 ZTCRYPT，是在最初的 ZMODEM 规范中定义，但从未实现的加密选项。
ZF3 是位图，其中由条件的设置了扩充选项。在 ZMODEM 规范中定义的唯一选项是
ZTSPARS 选项，它考虑到对“稀疏文件”的特殊处理。这个选项在 ZMODEM 规范中定义，但它很少得到过支持
如果对你有帮助，请给予作者一丝丝奖励
