我需要在我的程序中包含基本文件发送和文件接收例程,它需要通过zmodem协议。问题是我无法理解规范。

参考,以下是规范

规范没有定义各种常量,所以这里是 google 的标题文件。

在我看来,这个文件中有很多重要的事情是未定义的:

  • 它不断地指的是zdle编码,但它是什么?我何时使用它,当我不使用它时?
  • 在zfile数据帧之后,传输文件的元数据(文件名,修改日期,大小等)。这是zcrcw块,然后是根据规范未定义的块。据称ZCRCW块包含16位CRC,但规范没有定义CRC计算的数据。
  • 它没有定义其使用的CRC多项式。我发现CRC32 Poly是标准的CRC32,但我没有与CRC16 Poly的运气。 nevermind,我通过试验和错误找到了它。 CRC16 Poly是0x1021。

    我已经浏览了参考代码,但我可以发现的只是从90年代初到90年代未定义的C文件。我还发现了来自MSDN的一组文档,但它痛苦地模糊和矛盾,测试我运行的是: http://msdn.microsoft.com/en-us/library/ms817878.aspx (您可能需要通过谷歌的缓存

    为了说明我的困难,这是一个简单的例子。我在包含“Hello World”的服务器上创建了一个明文文件!它被称为HelloWorld.txt。

    i使用以下命令从服务器启动传输:

    sx --zmodem helloworld.txt
    
    .

    这会提示服务器发送以下zrqInit帧:

    2A 2A 18 42 30 30 30 30 30 30 30 30 30 30 30 30   **.B000000000000
    30 30 0D 8A 11                                    00.Š.
    
    .

    三个问题:

    • 是填充字节(0x2a)任意?为什么这里有两个,但在其他情况下只有一个,有时没有?
    • 规格在最后没有提及[CR] [LF] [Xon],但MSDN文章确实如此。为什么它?
    • 为什么[lf]有位0x80设置?

      之后,客户端需要发送Zrinit帧。我从MSDN文章中得到了这个:

      2A 2A 18 42 30 31 30 30 30 30 30 30 32 33 62 65   **.B0100000023be
      35 30 0D 8A                                       50.Š
      
      .

      除了[LF] 0x80标志问题外,我还有两个问题:

      • 为什么没有[xon]这个时间?
      • 是在二进制数据或ASCII十六进制数据上计算的CRC?如果它是在二进制数据上,我得到0x197c,如果它在ASCII十六进制数据上,我得到0xF775;这些都不是框架(0xbe50)中实际上的东西以ASCII十六进制模式为单位,它是ASCII十六进制字符所代表的CRC。)

        服务器使用zfile帧响应:

        2A 18 43 04 00 00 00 00 DD 51 A2 33               *.C.....ÝQ¢3
        
        .

        好的。这个是有道理的。如果我计算[04 00 00 00 00 00]的CRC32,则确实获得0x33a251dd。但现在我们最后没有任何[cr] [lf] [xon]。为什么是?

        在此框架之后,服务器还会发送文件的元数据:

        68 65 6C 6C 6F 77 6F 72 6C 64 2E 74 78 74 00 31   helloworld.txt.1
        33 20 32 34 30 20 31 30 30 36 34 34 20 30 20 31   3 240 100644 0 1
        20 31 33 00 18 6B 18 50 D3 0F F1 11                13..k.PÓ.ñ.
        
        .

        甚至没有标题,它只是跳转到数据。好的,我可以忍受那个。但是:

          我们有第一个神秘的ZCRCW框架:[18 6B]。这帧有多长? CRC数据在哪里,它是CRC16还是CRC32?它没有定义规范中的任何地方。
        • msdn文章指定[18 6b]应该是[00],但不是。
        • 然后我们有一个未定义类型的框架:[18 50 d3 0f f1 11]。这是一个单独的帧还是zcrcw的一部分?

          客户端需要使用ZRPOS帧响应,再次从MSDN文章中获取:

          2A 2A 18 42 30 39 30 30 30 30 30 30 30 30 61 38   **.B0900000000a8
          37 63 0D 8A                                       7c.Š
          
          .

          与Zrinit帧相同的问题: CRC是错误的,[LF]有位0x80设置,并且没有[Xon]。

          服务器用zdata帧响应:

          2A 18 43 0A 00 00 00 00 BC EF 92 8C               *.C.....¼ï’Œ
          
          .

          与zfile相同的问题:crc都很好,但在哪里[cr] [lf] [xon]?

          在此之后,服务器发送文件的有效载荷。由于这是一个很短的例子,它适合一个块(最大尺寸为1024):

          48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0A            Hello world!.
          
          .

          从文章似乎提及的情况下,有效载荷逃离了[zdle]。那么如何传输遇到匹配[zdle]的值的有效载荷字节?是否有这样的其他值?

          服务器以这些帧结尾:

          18 68 05 DE 02 18 D0                              .h.Þ..Ð
          2A 18 43 0B 0D 00 00 00 D1 1E 98 43               *.C.....Ñ.˜C
          
          .

          我完全迷失在第一个。 secon.

d与Zrinit和Zdata帧一样多的感觉。
有帮助吗?

解决方案

如果你正在实施时间,我的好友奇迹 机器。

我不知道我可以回答你的所有问题 - 我从来没有 实际上必须自己实施ZMODEM - 但这里很少答案:

文章似乎提及的内容,有效载荷逃脱了 [zdle]。那么如何传输恰好匹配的有效载荷字节 [zdle]的价值?是否有这样的其他值?

在您链接到的文档中明确地解决了 开始你的问题,说:

The ZDLE character is special.  ZDLE represents a control sequence
of some sort.  If a ZDLE character appears in binary data, it is
prefixed with ZDLE, then sent   as ZDLEE.
.

它不断参考Zdle编码,但它是什么?具体什么时候 我是否使用它,当我不使用它? 在旧时代,某些“控制字符”用于控制 通信频道(因此名称)。例如,发送Xon / Xoff 字符可能会暂停传输。 Zdle用于逃避 可能有问题的字符。根据规格,这些是 默认逃逸的字符:

ZMODEM software escapes ZDLE, 020, 0220, 021, 0221, 023, and 0223.
If preceded by 0100 or 0300 (@), 015 and 0215 are also escaped to
protect the Telenet command escape CR-@-CR.  The receiver ignores
021, 0221, 023, and 0223 characters in the data stream.
.

我围绕了参考代码,但我能找到的就是 从90年代初到90年代早期的未读取。

这包括 lrzsz

那里有许多其他实现,包括 在 freecode 中列出了几个软件,包括 qodem syncterm mbse ,和别的。我相信 syncterm 实现写为库可以很容易合理 从您自己的代码中使用(但我不确定)。

如果您探讨了较老的收藏,您可能会找到附加代码 MS-DOS软件。

其他提示

我不能怪你。用户手册不是以用户友好的方式组织

是填充字节(0x2a)任意何种?

否,从第14,15页:

二进制报头以序列ZPAD,ZDLE,ZBIN开始。

六角标题以序列zpad,zpad,zdle,zhex开头。

规范在最后没有提到[CR] [LF] [XON],但MSDN文章确实如此。为什么有?

page 15

* * Zdle B型F3 / P0 F2 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 CR LF XON 。 为什么[LF]有位0x80设置?

不确定。来自Tera术语我得到了两个控制字符,X / P> X / P>

我们有第一个神秘的ZCRCW框架:[18 6B]。这帧有多长? CRC数据在哪里,它是CRC16还是CRC32?它没有定义规范中的任何地方。

zcrcw不是标题或帧类型,它更像是一个页脚,它告诉接收者接下来需要什么。在这种情况下,它是包含文件名的数据子组件的页脚。它将是32位校验和,因为您正在使用“C”类型二进制标头。

  • Zdle C 型式F3 / P0 F2 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 CRC-3 CRC-4

    然后我们有一个未定义类型的帧:[18 50 d3 0f f1 11]。这是一个单独的帧还是zcrcw的一部分?

    这是ZCRCW数据子包的CRC。它是5个字节,因为第一个是0x10,一个需要曲线逃逸的控制字符。我不确定0x11是什么。

    并且没有[xon]。

    xon只是六角标头。您不将其用于二进制标题。

    • Zdle A型F3 / P0 F2 / P1 F1 / P2 F0 / P3 CRC-1 CRC-2 。 那么如何传输恰好匹配[zdle]的值的有效载荷字节?

      18 58(aka zdlee)

      18 68 05 de 02 18 d0

      这是数据子帧的页脚。接下来的5个字节是CRC(最后一个字节是Zdle编码)

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top