KERMIT,XMODEM,YMODEM,ZMODEM傳輸協議小結

標籤：

源：KERMIT,XMODEM,YMODEM,ZMODEM傳輸協議小結 

Kermit協議

報文格式：

1.MARK，起始標記START_CHAR，為 0x01（CTRIL-A）；

2.LEN，報文剩餘部分的長度，取值範圍0~94，報文最大長度96，長度不包含分行符號或者定位字元；

3.SEQ，資料包編號，模數64,；

4.TYPE，k_state資料包類型

D	資料報文
Y	ACK報文（不能轉換編碼）
N	NAK，未收到
S	發送初始化報文
B	傳輸結束
F	檔案頭部
Z	檔案結束
E	Error
Q，T	保留

         NAK包用來說明等待的包沒有正常接收，它不提供別的資訊，例如不提供請求的服務之類。它的資料域總是空的。T報文用於內部kermit程式說明逾時。

5．DATA，0~31,127這33個控制字元需要進行轉換，前面加’#’，0~31之間加上64,127減去64處理。加過首碼的序列不要分散在不同的包。前置詞字元也包含在計數之內。除S,I,A報文及其響應，都不能進行編碼。

6．CHECK，假如S是整個報文字元的算術和，只是校正0~5位的和。

這是基本的預設塊校正，所有的kermit都必須可以實施。

 

Kermit報文發送過程

1.發送方首先發送一個初始化報文S（以0x01起始），確定報文長度，逾時時間等；-->

<--接收方返回一個確認報文Y，在報文資料區段存放自己的參數

2.發送方傳送檔案頭報文F，在資料區段包含檔案名稱-->（如果發送多個檔案，重複此步驟即可）

<--返回ACK，資料區段可以不包含資料

3.開始傳送檔案內容，資料報文D，不在可列印ascii碼範圍內的，需要被提前替換成等價的可列印字元，每個資料報文都會收到ACK。

4.檔案資料發送結束後，發送方傳送檔案尾報文Z，收方接收後確認。

5.沒有檔案需要發送時，發送傳輸結束報文B，並接收ACK，然後關閉串連，物理串連依然保留

每個報文都有編號，0~63之間。

 XMODEM

　　簡單通用，傳輸資訊單位是“包=128B”,傳輸速度慢，適合電話線路品質差的情況下使用。

　　Xmodem是最廣泛使用的檔案傳輸通訊協定之一。原始的Xmodem協議使用128位元組的資料包和一個簡單的“校正和”的錯誤偵測方法。隨後的版本XMODEM-CRC，使用了更安全的迴圈冗餘校正（CRC）錯誤偵測方法。 Xmodem協議始終首先嘗試使用CRC。如果寄件者不響應CRC的請求，接收器轉移到校正和模式，並繼續其請求傳輸。

1．Xmodem協議是什嗎？

 　　XMODEM協議是一種串口通訊中 廣泛用到的非同步檔案傳輸通訊協定。分為標準Xmodem和1k-Xmodem兩種，前者以128位元組塊的形式傳輸資料，後者位元組塊為1k即1024位元組，並且每個塊都使用一個校正和過程來進行錯誤偵測。在校正過程中如果接收方關於一個塊的校正和與它在發送方的校正和相同時，接收方就向發送方發送一個確認位元組 (ACK)。由於Xmodem需要對每個塊都進行認可，這將導致效能有所下降，特別是延時比較長的場合，這種協議顯得效率更低。

 　　除了Xmodem，還有Ymodem，Zmodem協議。他們的協議內容和Xmodem類似，不同的是Ymodem允許批次檔傳輸，效率更高；Zmodem則是改進的了Xmodem，它只需要對損壞的塊進行重發，其它正確的塊不需要發送確認位元組。減少了通訊量。

 

2．Xmodem協議相關控制字元

    SOH                       0x01

    STX             　　　  0x02

    EOT                       0x04

    ACK                       0x06

    NAK                       0x15

    CAN                       0x18

    CTRLZ                   0x1A

 

3．標準Xmodem協議（每個資料包含有128位元組資料）框架格式

2-1

SOH

資訊包序號

資訊包序號的補碼

資料區段

校正和

 

4．1k-Xmodem（每個資料包含有1024位元組資料）框架格式

2-2

STX

資訊包序號

資訊包序號的補碼

資料區段

校正和

 

5．資料包說明

 　　對於標準Xmodem協議來說，如果傳送的檔案不是128的整數倍，那麼最後一個資料包的有效內容肯定小於幀長，不足的部分需要用CTRL- Z(0x1A)來填充。這裡可能有人會問，如果我傳送的是bootloader工程產生的.bin檔案，mcu收到後遇到0x1A字元會怎麼處理？其實如果傳送的是文字檔，那麼接收方對於接收的內容是很容易識別的，因為CTRL-Z不是前128個ascii碼，不是通用可見字元，如果是二進位檔案，mcu其實也不會把它當作代碼來執行。哪怕是excel檔案等，由於其內部會有些結構表示各個欄位長度等，所以不會讀取多餘的填充字元。否則 Xmodem太弱了。對於1k-Xmodem，同上理。

 

6．如何啟動傳輸？

　　傳輸由接收方啟動，方法是向發送方發送"C"或者NAK(注意，這裡提到的NAK是用來啟動傳輸的。以下我們會看到NAK還可以用來對資料產生重傳的機制)。接收方發送NAK訊號表示接收方打算用累加和校正；發送字元"C"則表示接收方想打算使用CRC校正（具體校正規則下文Xmodem源碼，源碼勝於雄辯)。

 

7．傳輸過程

　　當接收方發送的第一個"C"或者NAK到達發送方，發送方認為可以發送第一個資料包，傳輸已經啟動。發送方接著應該將資料以每次128位元組的資料加上包頭，包號，包號補碼，末尾加上校正和，打包成框架格式傳送。 發送方發了第一包後就等待接收方的確認位元組ACK，收到接收方傳來的ACK確認，就認為資料包被接收方正確接收，並且接收方要求發送方繼續發送下一個包；如果發送方收到接收方傳來的NAK(這裡，NAK用來告訴發送方重傳，不是用來啟動傳輸)位元組，則表示接收方請求重發剛才的資料包；如果發送方收到接收方傳來的CAN位元組，則表示接收方請求無條件停止傳輸。

 

8．如何結束傳輸？    

　　如果發送方正常傳輸完全部資料，需要結束傳輸，正常結束需要發送方發送EOT 位元組通知接收方。接收方回以ACK進行確認。當然接收方也可強制停止傳輸，當接收方發送CAN 位元組給發送方，表示接收方想無條件停止傳輸，發送方收到CAN後，不需要再發送 EOT確認（因為接收方已經不想理它了，呵呵）。

 

9．特殊處理    

　　雖然資料包是以 SOH 來標誌一個資訊包的起始的，但在 SOH 位置上如果出現EOT則表示資料轉送結束，再也沒有資料傳過來。 接收方首先應確認資料包序號的完整性，通過對資料包序號取補，然後和資料包序號的補碼異或，結果為0表示正確，結果不為0則發送NAK請求重傳。    

　　接收方確認資料包序號正確後，然後檢查是否期望的序號。如果不是期望得到的資料包序號，說明發生嚴重錯誤，應該發送一個 CAN 來中止傳輸。    

　　如果接收到的資料包的包序號和前一包相同，那麼接收方會忽略這個重複包，向發送方發出 ACK ，準備接收下一個包。    

　　接收方確認了資訊包序號的完整性和是正確期望的後，只對 128 位元組的資料區段進行算術和校正，結果與幀中最後一個位元組（算術校正和）比較，相同發送 ACK，不同發送 NAK。

 

10．校正和的說明    

　　Xmodem協議支援2種校正和，它們是累加和與CRC校正。     當接收方一開始啟動傳輸時發送的是NAK，表示它希望以累加和方式校正。    

　　當接收方一開始啟動傳輸時發送的是字元“C”，表示它希望以CRC方式校正。    

　　可能有人會問，接收方想怎麼校正發送方都得配合嗎，難道發送方必須都支援累加和校正和CRC校正？事實上Xmodem要求支援CRC的就必須同時支援累加和，如果發送方只支援累加和，而接收方用字元“C”來啟動，那麼發送方只要不管它，當接收方繼續發送“C”，三次後都沒收到應答，就自動會改為發送 NAK，因為它已經明白髮送方可能不支援CRC校正，現在接收方改為累加和校正和發送方通訊。發送方收到NAK就趕緊發送資料包響應。

YMODEM

　　由XMODEM演變來，效率可靠性高，包=128*8B；一次傳輸可發送或接受幾個檔案。

　　XMODEM1K本質上是XMODEM CRC1K（1024位元組）的資料包。在某些系統中，它也可以被稱為YMODEM。有些通訊軟體程式，著名的Procomm的1.x版本中，也將XMODEM-1K 稱為YMODEM，但在Procomm的2.0版本中不再稱XMODEM-1K為 YMODEM。

　　YMODEM -G：YMODEM-G是一種YMODEM的變種。它被設計成用於支援錯誤控制的數據機。該協議不提供軟體錯誤修正或恢複，但預計數據機提供的服務。這是一個流媒體協議，在一個連續的資料流上發送和接收1K的資料包，直顯式停止。每塊被發送後，它不會等待肯定的確認，而是快速連續地發送塊。如果任何塊傳輸失敗，本次傳輸將會失敗退出。

 

檔案傳輸過程的開啟：

（1）開啟是由接收方開啟傳輸，它發一個大寫字母C開啟傳輸。然後進入等待（SOH）狀態，如果沒有回應，就會逾時退出。

（2）發送方開始時處於等待過程中，等待C。收到C以後，發送（SOH）資料包開始訊號，發送序號（00），補碼（FF），“檔案名稱”，“空格”“檔案大小”“除去序號外，補滿128位元組”，CRC校正兩個位元組。進入等待（ACK）狀態。

（3）接收方收到以後，CRC校正滿足，則發送ACK。發送方接收到ACK，又進入等待“檔案傳輸開啟”訊號，即重新進入等待“C”的狀態。

 

（4）前面接收方只是收到了一個檔案名稱，限制正式開啟檔案傳輸，Ymodem支援128位元組和1024位元組一個資料包。128位元組以（SOH）開始，1024位元組以（STX）開始。

接收方又發出一個“C”訊號，開始準備接收檔案。進入等待“SOH”或者“STX”狀態。

（5）發送接收到“C”以後，發送資料包，（SOH）（01序號）（FE補碼）（128位元據）（CRC校正），等待接收方“ACK”。

（6）檔案發送完以後，發送方發出一個“EOT”訊號，接收方也以“ACK”回應。

然後接收方會再次發出“C”開啟另一次傳輸，若接著發送方會發出一個“全0資料包”，接收方“ACK”以後，本次通訊正式結束。

（7）當然YMODEM相對於XMODEM改進的地方就在於傳輸再次開啟以後，又可以發送另外一個檔案，即一次傳輸允許發送多個檔案。

所用到的符號

#define MODEM_SOH 0x01 //資料區塊起始字元

#define MODEM_STX 0x02 //1028位元組開始

#define MODEM_EOT 0x04 //檔案傳輸結束

#define MODEM_ACK 0x06 //確認應答

#define MODEM_NAK 0x15 //出現錯誤

#define MODEM_CAN 0x18 //取消傳輸

#define MODEM_C 0x43   //大寫字母Ｃ

CRC計算方法

in_ptr = mblock->buf; //指向要計算CRC的緩衝區開頭

cksum = 0; //

for (stat=mblock->len ; stat>0; stat--) //len是所要計算的長度

{

cksum = cksum^(int)(*in_ptr++) << 8; //

for (i=8; i!=0; i--)

{

if (cksum & 0x8000)

cksum = cksum << 1 ^ 0x1021;

else

cksum = cksum << 1;

}

}

 ZMODEM

　　與上兩種不同，可以連續的資料流發送資料，效率更高

　　在具體的環境中，通過多次採用的xmodem的傳輸可以發現，不管是直接傳輸，還是按照網上 的說法採用rz sz傳輸，都很難將檔案正確傳輸到嵌入式裝置上。當採用zmodem進行傳輸的時候卻發現傳輸的效率很高，幾乎沒有失敗。

　　Zmodem協議有兩個顯著的特點：它是非常有效，它提供了類似於YMODEM-G的崩潰恢複機制，Zmodem協議不會等待肯定的確認後，每個塊被發送，而是快速連續地發送塊。 Zmodem協議傳輸如果因任何原因被取消或中斷，恢複後，先前傳送的資訊都需要重新發送。

 

原文：小貓吃柿子的部落格——KERMIT,XMODEM,YMODEM,ZMODEM傳輸協議小結

KERMIT,XMODEM,YMODEM,ZMODEM傳輸協議小結（轉）