【轉】Xmodem、Ymodem協議總結

原文:https://blog.csdn.net/hkh5730/article/details/25145651

 

Xmodem、Ymodem協議總結

寫在前面:

   本文包含如下內容:

  一、文件傳輸簡介

  二、傳輸協議

  三、協議特點

  四、XModem協議解析

    (4-1)協議校驗和方式傳輸流程解析

    (4-2)CRC校驗信息包解析

  五、YModem協議解析

    (5-1)YModem起始幀的數據格式解析

    (5-2)YModem數據幀的數據格式解析

    (5-3)YModem結束幀的數據格式解析

    (5-4)YModem的文件傳輸流程解析

 

一、文件傳輸簡介

  文件傳輸是數據交換的主要形式。在進行文件傳輸時,爲使文件能被正確識別和傳送,我們需要在兩臺計算機之間建立統一的傳輸協議。這個協議包括了文件的識別、傳送的起止時間、錯誤的判斷與糾正等內容。Xmodem、Ymodem和Zmodem協議是最常用的三種通信協議。

 

二、傳輸協議

  在SecureCRT下的傳輸協議有ASCII、Xmodem、Ymodem、Zmodem等。如下圖所示,在開發中,可以使用SecureCRT軟件進行文件傳輸。

     

 

 三、協議特點

  (1)Xmodem協議是最早的,傳輸128字節信息塊。

  (2)Ymodem是Xmodem的改進版協議,具有傳輸快速穩定的優點。它可以一次傳輸1024字節的信息塊,同時還支持傳輸多個文件。  

  平常所說的Ymodem協議是指的Ymodem-1K,除此還有Ymodem-g(沒有CRC校驗,不常用)。


  YModem-1K用1024字節信息塊傳輸取代標準的128字節傳輸,數據的發送會使用CRC校驗,保證數據傳輸的正確性。它每傳輸一個信息塊數據時,就會等待接收端迴應ACK信號,接收到迴應後,纔會繼續傳輸下一個信息塊,保證數據已經全部接收。

四、XModem協議解析

  Xmodem協議傳輸有接收程序和發送程序完成,先由接收程序發送協商字符,協商校驗方式,協商通過之後發送程序就開始發送數據包,接收程序接收到完整的一個數據包之後按照協商的方式對數據包進行校驗。校驗通過之後發送確認字符,然後發送程序繼續發送下一包;如果校驗失敗,則發送否認字符,發送程序重傳此數據包。
  定義:
  

  SOH 01H(modem數據頭)
  EOT 04H(發送結束)
  ACK 06H(應答)
  NAK 15H(非應答)
  CAN 18H(取消發送)

 
  Xmodem數據包,包含一個標題開始字符,一個單字節包序號,一個包序號的補碼,128字節數據和一個雙字節的CRC校驗。數據包結構如下圖所示:

 

   (1)校驗和方式傳輸流程:
  接收方要求發送方以校驗和方式發送時以NAK來請求,發送方將對此做出應答。如下圖:

  

       

   (2)CRC校驗信息包

  計算16位CRC校驗的除數多項式爲X ^ 16 + X ^ 12 + X ^ 5 + 1,信息報中的128數據字節將參加CRC校驗的計算,在發送端CRC16的高字節在前,低字節在後。
傳輸流程:接收方要求發送方以CRC校驗方式發送時以‘C’來請求,發送方將對此作出應答。

  

 

   

   信息報中如果剩餘的數據不足128字節,不足的部分將以0x1A填充。

 

五、YModem協議解析
  (1)起始幀的數據格式

  YModem的起始幀並不直接傳輸文件的數據,而是將文件名與文件的大小放在數據幀中傳輸,它的幀長=3字節數據首部+128字節數據+2字節CRC16校驗碼=33字節。它的數據幀結構如下:
  

複製代碼

起始數據幀結構:
SOH | 00 | FF | filename | filezise | NUL | CRCH | CRCL

起始數據幀結構解析:
  1、其中SOH=0x01,表示這個數據幀中包含着128個字節的數據(STX表示1024字節,初始幀只有128個)

  2、00表示數據幀序號,初始是0,依次向下排

  3、FF是幀序號的取反

  4、filename是要傳輸的文件名,如USTB_V3_1.0.1.26_NMEA.Bin,它在數據幀中的格式爲:55 53 54 42 5F 56 33 5F 31 2E 30 2E 31 2E 32 36 5F 4E 4D 45 41 2E 42 69 6E 00,也就是把ASCII碼轉成十六進制,但是最後一定要在文件名後加上00,表示文件名的結束

  5、filesize表示文件的大小,如上面的USTB_V3_1.0.1.26_NMEA.Bin大小是132KB,也就是135168Byte,轉換成十六進制就是0x21000,它在數據幀中的格式就是32 31 30 30 30 00,也就是ASCII的“21000”,同樣最後要加上00表示結束

  6、NUL就是數據部分的128字節中除去文件名和文件大小佔據的剩下的字節都用00填充

  7、CRCH和CRCL分別表示16位CRC校驗碼的高8位與低8位。

複製代碼


  (2)數據幀的數據格式

      YModem的數據幀中會預留1024字節空間用來傳輸文件數據,它跟起始幀接收差不多,如下:

複製代碼

數據幀結構:
 STX | 01 | FE | data[1024] | CRCH | CRCL
數據幀結構解析
 1、其中STX=0x02,表示這幀數據幀後面包含着1024字節的數據部分;

 2、01是表示幀序號,FE是它的取反,再下一幀數據就是02 FD,以此類推;

 3、data[1024]表示存放着1024字節的文件數據;

 4、CRCH與CRCL是CRC16檢驗碼的高8位與低8位。

特殊情況
 1、如果文件數據的最後剩餘的數據在128~1024之前,則還是使用STX的1024字節傳輸,但是剩餘空間全部用0x1A填充,如下結構:

 STX | 01 | FE | data[1024] | 1A 1A……… CRCH | CRCL

 2、有一種特殊的情況:如果文件大小小於或等於128字節或者文件數據最後剩餘的數據小於128字節,則YModem會選擇SOH數據幀用128字節來傳輸數據,如果數據不滿128字節,剩餘的數據用0x1A填充 
 這時數據幀的結構就變成:

 1)、文件大小小於128字節:        SOH | 01 | FE | data[ ] | 1A ...1A | CRCH | CRCL  

 2)、文件最後剩餘數據小於128字節:  SOH | 01 | FE | data[ ] | 1A...1A | CRCH | CRCL

複製代碼


  (3)結束幀的數據格式
      YModem的結束幀數據也採用SOH的128字節數據幀,它的結構如下:

    SOH | 00 | FF | NUL | [128] | CRCH | CRCL

    結束幀同樣以SOH開頭,表示後面跟着128字節大小的數據;結束幀的幀序也認爲是00 FF;結束幀的128字節的數據部分不存放任何信息,即全部用00填充。

   (4)文件傳輸過程

       文件的傳輸過程,以具體的例子說明。把USTB_V3_1.0.1.26_NMEA.Bin,大小爲135168Byte(16進製爲0x21000,它在數據幀中的格式就是32 31 30 30 30 00)的文件作爲傳輸的對象,則它的傳輸過程如下:

  發送端                                                                                   接收端       

   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   C

  SOH 00 FF [55 53…6E 00]" "[32…30 00]'' NUL[96] CRC CRC >>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<    ACK

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<    C

  STX 01 FE data[1024] CRC CRC>>>>>>>>>>>>>>>>>>>>>>     

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   ACK

  STX 02 FD data[1024] CRC CRC>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   ACK

  STX 03 FC data[1024] CRC CRC>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   ACK

  STX 04 FB data[1024] CRC CRC>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   ACK

  SOH 05 FA data[100]  1A[28] CRC CRC>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   ACK

  EOT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   NAK

  EOT>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   ACK

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   C

  SOH 00 FF NUL[128] CRCCRC >>>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<   ACK
 

參考原文鏈接:

  https://blog.csdn.net/sinat_33323544/article/details/83994835

  https://blog.csdn.net/lcmsir/article/details/80550821

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章