zoukankan      html  css  js  c++  java
  • Xmodem协议简介

    1.      Xmodem协议

    1.1.    简介

    在上一章中,BootLoader和APP在串口下的升级其实都用到了一种文件传输协议,即Xmodem协议,该协议因其简单,易实现和使用的特点在很多场合都得到了广泛的应用。

    Xmodem是在1978年由Ward Christensen创建的用于调制解调器纠错的协议,它实际上已经成了标准。使用此协议的调制解散调节器发送的数据包大小为128-byte (数据包的大小也可以为1K字节)。如果包成功接收,接收方会返回一个肯定应答信号(ACK),如果发现错误,则返回一个否定应答信号(NAK)并重新发送数据包。Xmodem使用奇偶校验作为查错控制的方法。

    这种协议以128字节块的形式传输数据,并且每个块都使用一个校验和过程来进行错误检测。如果接收方关于一个块的校验和与它在发送方的校验和相同时,接收方就向发送方发送一个认可字节。然而,这种对每个块都进行认可的策略将导致低性能,特别是具有很长传播延迟的卫星连接的情况时,问题更加严重。

    使用循环冗余校验的与XMODEM相应的一种协议称为XMODEM-CRC。还有一种是XMODEM-1K,它以1024字节一块来传输数据。ZMODEM是最有效的一个XMODEM版本,它不需要对每个块都进行认可。事实上,它只是简单地要求对损坏的块进行重发。ZMODEM对按块收费的分组交换网络是非常有用的。不需要认可回送分组在很大程度上减少了通信量。

    YMODEM也是一种XMODEM的实现。它包括XMODEM-1K的所有特征,另外在一次单一会话期间为发送一组文件,增加了批处理文件传输模式。

    1.2.    协议内容

    1.2.1.      协议相关控制字符

        SOH             0x01 

        STX             0x02 

        EOT             0x04 

        ACK             0x06 

        NAK             0x15 

        CAN             0x18 

        CTRLZ         0x1A 

    1.2.2.      标准帧格式(128字节)

    SOH

    信息包序号

    包序号的补码

    数据区段

    校验和

    起始字节

    包号

    取反加1

    128

    数据区段和

    1k-Xmodem帧格式如下:

    STX

    信息包序号

    包序号的补码

    数据区段

    校验和

    起始字节

    包号

    取反加1

    1024

    数据区段和

     

    说明:

    SOH 帧的开头字节,代表信息包中的第一个字节   

    信息包序号:对256取模所得到当前包号,第一个信息包的序号为1,而信息包序号范围 0~255;   

    信息包序号的补码:当前信息包号的补码;   

    数据区段: 数据区段的长度固定为128字节(最后一个区段数据字节数肯定小于128,由CTRLZ来填充),其内容没有任何限制,可以是文本数据或二进制数据; 

    算术校验和:1字节的算术校验和,只对数据区段求和后对256取模而得;

     

    1.2.3.      传输逻辑

    1> 收发双方拨号连通后,发送方等待接收方传来 NAK 信号。当第一个NAK 到达,发送方解释为开始发送第一个包;  

    2> 发送方一旦收到第一个 NAK,启动了传输,发送方就将数据以每次 128字节打包成帧格式传送,再等待接收方的确认信号;   

    3> 发送方收到接收方传来的ACK信号,解释为信息包被正确接收,并有发送下一个包的含义;   

    4> 发送方收到接收方传来的NAK信号,解释为请求重发同一数据包;   

    5> 发送方收到接收方传来的 CAN 信号,解释为请求无条件停止传输过程;

    6> 发送方正常传输完全部数据,需要正常结束,发送EOT信号通知接收方。接收方用 ACK 进行确认;   

    7> 接收方发送CAN无条件停止传输过程,发送方收到CAN后,不发送 EOT 确认;   

    8> 虽然信息包是以 SOH 来标志一个信息包的起始的,但在 SOH 位置上出现的 EOT则表示数据传输结束,再也没有数据传过来;   

    9> 接收方首先应确认信息包序号的完整性,通过对信息包序号取补,然后和信息包序号的补码异或,结果为0表示正确,结果不为0则发送NAK请求重传;   

    10> 接收方确认信息包序号正确后,然后检查是否期望的序号。如果不是期望得到的信息包序号,说明发生严重错误,应该发送一个 CAN 来中止传输;   

    11> 对于10>情况的唯一例外,是收到的包的信息包序号与前一个信息包序号相同,此中情况,接收方简单忽略这个重复的包,向发送方发出 ACK ,准备接收下一个包。

    12>接收方确认了信息包序号的完整性和是正确期望的后,只对 128 字节的数据区段进行算术和校验,结果与帧中最后一个字节(算术校验和)比较,相同发送 ACK,不同发送 NAK;

    1.2.4.      超时处理 

    1> 接收方等待一个信息包的到来所具有的超时时限为 10 秒,每个超时后发送 NAK;   

    2> 当收到包时,接收过程中每个字符的超时间隔为1秒;   

    3> 为保持“接收方驱动”,发送方在等待一个启动字节时不应该采用超时处理

    4> 一旦传输开始,发送方采用单独的1分钟超时时限,给接收方充足的时间做发送ACK 、NAK 、CAN之前的必须处理;   

    5> 所有的超时及错误事件至少重试10次;

    1.2.5.      校验和的说明

    Xmodem协议支持2种校验和,它们是累加和与CRC校验。当接收方一开始启动传输时发送的是NAK,表示它希望以累加和方式校验。当接收方一开始启动传输时发送的是字符“C”,表示它希望以CRC方式校验。

    可能有人会问,接收方想怎么校验发送方都得配合吗,难道发送方必须都支持累加和校验和CRC校验?事实上Xmodem要求支持CRC的就必须同时支持累加和,如果发送方只支持累加和,而接收方用字符“C”来启动,那么发送方只要不管它,当接收方继续发送“C”,三次后都没收到应答,就自动会改为发送NAK,因为它已经明白发送方可能不支持CRC校验,现在接收方改为累加和校验和发送方通讯。发送方收到NAK就赶紧发送数据包响应。

    1.2.6.      Xmodem-1K

    Xmodem-1K在标准协议的基础上,加大了传输封包的大小(1K),用来提高传输速率;增加了 CRC 校验,用来提高传输的可靠性;

    区别在于:当启用Xmodem时,接收方发送C字符。发送方收到C字符判定为采用Xmodem-1K扩展;否则,当超时后,按照基本的版本传输。

  • 相关阅读:
    redis乐观锁
    redis
    解决创建Redis容器没有conf配置文件
    redis缓存配置
    Docker架构
    Flask获取数据的一些方法
    Nginx正向代理、反向代理与负载均衡
    Sanic
    Dockerfile详解
    Centos7上安装docker
  • 原文地址:https://www.cnblogs.com/beyonne/p/5689735.html
Copyright © 2011-2022 走看看