基于MQTT的物聯(lián)網(wǎng)系統(tǒng)文件傳輸方法的實現(xiàn)

張玉杰， 劉 麗, 馮春倩, 張婷婷

(陜西科技大學 電氣與信息工程學院， 陜西 西安 710021)

0 引言

MQTT(Message Queue Telemetry Transport,消息隊列遙測傳輸)協(xié)議以其開銷小、及時性好和可靠性高等優(yōu)勢在物聯(lián)網(wǎng)系統(tǒng)中得到廣泛的應用[1]，其基于主題的發(fā)布訂閱模型，可方便實現(xiàn)物聯(lián)網(wǎng)系統(tǒng)中節(jié)點設備一對一，一對多的消息通信[2].在物聯(lián)網(wǎng)系統(tǒng)中，常存在設備節(jié)點參數(shù)配置、設備與設備之間需要共享信息量較大的數(shù)據(jù)的場合[3]，而這類文件數(shù)據(jù)大小僅為幾十kB的等級.因此，提供一種開銷小、可靠性高、簡單靈活的文件傳輸方案就顯得尤為必要.

TFTP協(xié)議常被用于解決資源有限的嵌入式系統(tǒng)中的文件傳輸[4]，將通信雙方一方設置為客戶端模式，另一方為服務器模式，即可實現(xiàn)設備到設備之間的文件傳輸.由于物聯(lián)網(wǎng)系統(tǒng)中終端節(jié)點設備大都分散在不同區(qū)域的局域網(wǎng)內(nèi)，使用該種方式，難以避免通信過程中設備IP動態(tài)分配和內(nèi)網(wǎng)穿透的問題.若采取在公網(wǎng)中建立文件服務器，設備做客戶端的方式實現(xiàn)設備與設備的文件傳輸[5]，需要系統(tǒng)額外增加文件服務器和文件消息通知功能，增加了系統(tǒng)的復雜程度.

針對傳統(tǒng)文件傳輸方法難以適應物聯(lián)網(wǎng)系統(tǒng)設備到設備之間文件傳輸?shù)膱龊系膯栴}，本文利用MQTT協(xié)議在物聯(lián)網(wǎng)系統(tǒng)中設備與設備間消息通信的優(yōu)勢，在MQTT通信的基礎上，通過文件拆分傳輸?shù)姆绞?，能夠快速實現(xiàn)物聯(lián)網(wǎng)系統(tǒng)中設備到設備間的小文件傳輸，具有實際應用價值.

1 文件傳輸方案的設計

1.1 文件傳輸問題分析

MQTT是基于TCP/IP的即時通訊協(xié)議，采用輕量級基于代理的發(fā)布/訂閱式消息傳輸模式.其結構如圖1所示，由MQTT客戶端和服務器組成[6].本文提出的基于MQTT協(xié)議的文件傳輸系統(tǒng)中，通信的雙方既可以是數(shù)據(jù)的發(fā)送方也可以是數(shù)據(jù)的接收方，均屬于MQTT客戶端，而MQTT代理服務器作為文件傳輸過程中的中轉(zhuǎn)站，不作為文件傳輸?shù)膶ο筮M行考慮.

圖1 MQTT協(xié)議基于主題發(fā)布/訂閱通信結構圖

MQTT協(xié)議是一種針對小數(shù)據(jù)量消息傳輸?shù)妮p量級協(xié)議，消息體主要由三部分組成：固定報頭，可變報頭和有效載荷，固定報頭是每個命令消息都必須要包含的部分，長度固定為2bytes，最大可表示的消息長度范圍為0～256 Mbyte[7].雖然協(xié)議規(guī)定MQTT消息體中最大可以發(fā)送的字節(jié)數(shù)為256 Mbyte，但是若直接以最大長度進行文件傳輸，會存在以下問題：

(1)設備端在實現(xiàn)文件傳輸過程中，需要開辟緩沖區(qū)存放所要發(fā)送的數(shù)據(jù)，當傳輸?shù)臄?shù)據(jù)較大時，相應的緩沖區(qū)的容量將會增大，而工作在物聯(lián)網(wǎng)底層的小型嵌入式硬件設備的資源是有限的[8]，其內(nèi)存資源很難滿足需求；

(2)由于文件傳輸系統(tǒng)中用于MQTT通信的通道是單一的，若以最大長度進行文件傳輸，當文件較大傳輸時間較長時，傳輸通道將會被長時間占用，從而無法保證系統(tǒng)中其它使用MQTT協(xié)議傳輸?shù)臉I(yè)務消息的及時傳輸.

(3)MQTT協(xié)議適應于工作在帶寬低、網(wǎng)絡環(huán)境不穩(wěn)定的物聯(lián)網(wǎng)環(huán)境中.一旦出現(xiàn)網(wǎng)絡故障等原因造成的文件傳輸出錯現(xiàn)象，由于MQTT協(xié)議本身不具備斷點續(xù)傳等功能[9]，在恢復新一次文件傳輸時，之前已經(jīng)傳輸?shù)奈募?shù)據(jù)將會丟棄，造成了流量的浪費，也降低了整個文件傳輸?shù)男?

因此，需要綜合考慮設備的硬件存儲資源、傳輸通道占用情況、文件傳輸效率等多個因素，設計基于MQTT協(xié)議的文件傳輸方法.

1.2 文件傳輸方案設計

針對上面的分析，基于MQTT協(xié)議的文件傳輸方法，以MQTT通信為基礎[10]，使用文件拆分傳輸方式進行文件傳輸，在此基礎上增加應答、重傳等機制，目的在于彌補文件拆分傳輸過程中可能會出現(xiàn)的丟包現(xiàn)象，從而增強文件傳輸?shù)目煽啃?

文件拆分傳輸包含以下幾個環(huán)節(jié)：提取信息-拆分-傳輸-接收-組裝-檢查.為確保文件傳輸?shù)目煽啃裕ㄐ胚^程中，一方傳輸數(shù)據(jù)并接收應答，另一方接收數(shù)據(jù)并給出應答.并且通信雙方各自實現(xiàn)超時重傳，若發(fā)送方超時將重新發(fā)送上次的數(shù)據(jù)包，若接收方超時，則將重傳應答數(shù)據(jù)包.圖2為基于MQTT協(xié)議的文件傳輸方法的實現(xiàn)過程.該文件傳輸方案描述了發(fā)送設備端向接收設備端傳送文件的基本過程，主要包括文件傳輸請求階段、文件數(shù)據(jù)傳輸階段、文件傳輸結束階段三個階段.

圖2 基于MQTT協(xié)議的文件傳輸方法的實現(xiàn)過程

文件傳輸請求階段：發(fā)送方提取有關發(fā)送文件的大小屬性，優(yōu)先向接收方發(fā)送文件屬性消息作為發(fā)起文件傳輸?shù)恼埱?，接收方接收并保存文件屬性消息，讀取文件大小，判斷硬件資源是否滿足，若滿足則回復應答包，表示文件傳輸過程建立，進入文件數(shù)據(jù)傳輸階段.文件數(shù)據(jù)傳輸階段：發(fā)送方向接收方發(fā)送文件數(shù)據(jù)，等待接收方回復的應答包，超時后重發(fā)未被確認的數(shù)據(jù)包；接收方接收到數(shù)據(jù)后，回復文件數(shù)據(jù)包正確或者錯誤；當數(shù)據(jù)長度小于定義的最大數(shù)據(jù)包長度，則表示傳輸結束，接收方成功接收到最后一幀文件數(shù)據(jù)包后，進入文件傳輸結束階段.

文件傳輸結束階段：發(fā)送方向接收方發(fā)送最后一幀文件數(shù)據(jù)包，收到來自接收方的應答包之后，回復一個確認信號，表示整個文件傳輸操作已經(jīng)結束.

2 文件傳輸?shù)能浖崿F(xiàn)

2.1 系統(tǒng)軟件架構

根據(jù)系統(tǒng)文件傳輸?shù)脑O計需求，軟件部分不僅包括MQTT通信的實現(xiàn)，還包括文件數(shù)據(jù)處理，文件傳輸，文件存儲功能的實現(xiàn).系統(tǒng)軟件設計采用分層設計的思想，軟件架構如圖3所示，由硬件驅(qū)動層、系統(tǒng)層、應用層三部分組成[11].

硬件驅(qū)動層主要包含以太網(wǎng)收發(fā)器LAN8720A驅(qū)動[12]、串口驅(qū)動、SD卡驅(qū)動等硬件驅(qū)動程序.系統(tǒng)層為上層應用層文件傳輸服務等功能的實現(xiàn)提供支持，包含操作系統(tǒng)，網(wǎng)絡協(xié)議棧，文件編碼數(shù)據(jù)格式等.其中FreeRTOS操作系統(tǒng)實現(xiàn)對整個系統(tǒng)的任務調(diào)度和管理；LWIP協(xié)議棧是輕量級的TCP/IP協(xié)議棧[13]，適應于底層資源有限的嵌入式設備，是網(wǎng)絡通信的基礎；FatFs文件系統(tǒng)提供對文件進行讀寫[14]，刪除等操作的標準接口，方便實現(xiàn)對SD卡中的文件進行管理；Base64編碼、Json庫為文件數(shù)據(jù)格式的統(tǒng)一規(guī)范提供支持，使文件傳輸方法適用于不同場合的系統(tǒng).應用層為功能的實現(xiàn)，主要包含MQTT通信實現(xiàn)、文件傳輸服務實現(xiàn)及其它相關的應用程序.

圖3 系統(tǒng)軟件架構圖

2.2 文件傳輸數(shù)據(jù)格式

根據(jù)文件傳輸?shù)男枨?，將文件傳輸過程中數(shù)據(jù)幀主要分為以下幾類：文件請求命令幀，請求應答幀，文件數(shù)據(jù)幀，數(shù)據(jù)接收應答幀，文件結束請求命令幀，結束應答幀.數(shù)據(jù)幀格式如表1～6所示.

表1 文件請求命令幀格式

表2 文件請求應答幀格式

表3 文件數(shù)據(jù)幀格式

表4 文件數(shù)據(jù)應答幀格式

表5 文件結束請求命令幀格式

表6 文件結束請求應答幀格式

在本設計中，當進行文件傳輸時，采用JSON鍵值對“屬性，值”的形式[15]，來對文件傳輸?shù)臄?shù)據(jù)幀進行封裝.為避免二進制文件直接嵌入在JSON 字符串流中傳輸而破壞JSON字符串原有格式的問題，系統(tǒng)采用Base64編碼對源文件進行編碼[16]，將二進制文件數(shù)據(jù)轉(zhuǎn)換為Base64字符后再以JSON的形式進行傳輸.

2.3 文件傳輸功能實現(xiàn)

由于文件傳輸過程中請求、響應過程等具有時間的不確定性，采取了“事件驅(qū)動+狀態(tài)轉(zhuǎn)移”的編程思想，對設備端的文件上傳功能、文件下載功能進行實現(xiàn).采用該方法進行程序設計時，關鍵的是需要對文件上傳、文件下載的狀態(tài)以及驅(qū)動各狀態(tài)之間跳轉(zhuǎn)的事件進行劃分.

2.3.1 文件上傳的實現(xiàn)

文件上傳的實現(xiàn)過程劃分為以下狀態(tài)，包含空閑、上傳請求、等待請求響應、發(fā)送數(shù)據(jù)、等待回復、發(fā)送結束請求、等待結束回復、上傳成功、發(fā)送錯誤等九個狀態(tài).具體的狀態(tài)轉(zhuǎn)換過程如圖4所示.

圖4 文件上傳狀態(tài)轉(zhuǎn)換圖

(1)發(fā)送端執(zhí)行文件上傳初始化操作后，進入空閑狀態(tài).

(2)啟動文件傳輸事件觸發(fā)狀態(tài)進行跳轉(zhuǎn)，進入上傳請求狀態(tài).

(3)發(fā)布文件請求消息之后，進入到等待請求響應狀態(tài).

(4)若接收到拒絕請求回復，則返回至上傳請求狀態(tài)，若請求成功，發(fā)送文件數(shù)據(jù)命令，進入發(fā)送數(shù)據(jù)狀態(tài).

(5)發(fā)送數(shù)據(jù)狀態(tài)作為文件上傳實現(xiàn)過程中的核心狀態(tài)，通過與等待回復狀態(tài)的配合，確保文件上傳時確認應答以及超時重傳機制的完整實現(xiàn).該狀態(tài)下，實現(xiàn)數(shù)據(jù)幀的打包、上傳工作.

(6)超時時間內(nèi)，接收到數(shù)據(jù)回復后，繼續(xù)返回發(fā)送數(shù)據(jù)狀態(tài)；當超時時間到達，仍未接收到回復時，返回數(shù)據(jù)發(fā)送狀態(tài)，重新發(fā)送上一幀數(shù)據(jù)；當數(shù)據(jù)都上傳結束后，進入發(fā)送結束請求狀態(tài).

(7)發(fā)布上傳結束請求后，進入等待結束回復狀態(tài).

(8)回復成功，進入上傳成功狀態(tài).

(9)上傳成功狀態(tài)中，置發(fā)送成功標志位，釋放相關內(nèi)存空間，返回至空閑狀態(tài).

2.3.2 文件下載的實現(xiàn)

文件下載的實現(xiàn)包含空閑、等待請求、準備接收、接收數(shù)據(jù)、等待文件傳輸結束、下載成功、下載錯誤等狀態(tài)，具體的轉(zhuǎn)換過程如圖5所示.

(1)接收端執(zhí)行文件下載初始化操作后，進入空閑狀態(tài)；

(2)在空閑狀態(tài)中，接收到發(fā)送端發(fā)來的文件傳輸請求時，啟動文件下載，進入等待請求狀態(tài)；

(3)若響應請求成功，則跳轉(zhuǎn)至準備接收狀態(tài)，若請求響應失敗，則返回至等待請求狀態(tài)；

(4)當接收到文件數(shù)據(jù)命令時，進入接收數(shù)據(jù)狀態(tài)；

(5)接收數(shù)據(jù)狀態(tài)作為文件下載實現(xiàn)過程中的關鍵，實現(xiàn)文件數(shù)據(jù)的接收、保存工作，并對已接收的數(shù)據(jù)進行回復，若超時時間到達，仍未接收到數(shù)據(jù)，則重發(fā)上一幀回復應答幀.當接收到發(fā)送端的發(fā)送結束請求后，跳轉(zhuǎn)至等待文件傳輸結束狀態(tài).

(6)回復文件結束的請求成功后，進入下載成功狀態(tài)；

(7)文件下載狀態(tài)中，置文件接收成功標志位，釋放相關內(nèi)存空間，返回至空閑狀態(tài).

圖5 文件下載狀態(tài)轉(zhuǎn)換圖

3 系統(tǒng)測試

3.1 測試平臺的搭建

搭建一個完整的測試平臺，對文件傳輸?shù)男阅苓M行測試.該系統(tǒng)包括兩個MQTT設備端(均屬于MQTT客戶端，設備A發(fā)布消息的主題號為“deviceAout”，設備B發(fā)布消息的主題號為“deviceBout”)，一個MQTT服務器.MQTT服務器采用Apache Apollo服務器；MQTT設備端硬件設計框圖如圖6所示，采用STM32F407VET6作為主控制器，選用LAN8720A作為以太網(wǎng)收發(fā)器，通過RJ45接口接入網(wǎng)絡，此外還包括打印輸出信息的串口調(diào)試電路、LED狀態(tài)指示電路、SD卡存儲電路、電源電路等，硬件實物如圖7所示.

圖6 MQTT設備端硬件框圖

圖7 MQTT設備端硬件實物圖

3.2 文件傳輸性能測試

系統(tǒng)性能測試主要包含文件傳輸功能測試和文件傳輸可靠性測試.功能測試以一個固定大小的文件為例，利用MQTT測試工具監(jiān)測設備A與設備B之間的文件傳輸過程.測試時選用的文件大小為22 494 byte.首先設備A向設備B發(fā)送文件傳輸請求，在接收到設備B的請求應答后，開始傳送文件數(shù)據(jù)，出現(xiàn)丟包情況時，等待超時時間到后設備A會再次發(fā)送數(shù)據(jù)，當文件傳輸結束時，設備A發(fā)送結束請求，設備B回復結束請求應答，整個文件傳輸結束.測試結果如圖8所示.

(a) 文件傳輸請求

(b) 文件數(shù)據(jù)傳輸

(c) 超時重發(fā)

(d) 請求結束文件傳輸圖8 文件傳輸測試截圖

可靠性測試通過選擇3個不同大小的源文件在兩個MQTT設備端之間進行傳輸，實驗組數(shù)為50組，多次重復試驗，統(tǒng)計文件傳輸時的丟包重傳組數(shù)、成功組數(shù)，計算成功率.測試結果如表7所示.

表7 文件傳輸測試結果

由于文件傳輸工作相對比較耗時，進行文件傳輸時不可避免的會出現(xiàn)網(wǎng)絡環(huán)境不穩(wěn)定的狀況.當網(wǎng)絡環(huán)境較差，導致傳輸過程中出現(xiàn)丟包現(xiàn)象，系統(tǒng)會進入超時重傳，考慮到嵌入式設備不能長時間陷入某個固定狀態(tài)，導致其他任務無法響應，故在超時重傳機制中進行了閾值設置，當某一組重傳次數(shù)超過3次時，系統(tǒng)會自動中斷此次文件傳輸.

在表7中，丟包超時重傳組數(shù)表示文件傳輸過程中出現(xiàn)網(wǎng)絡丟包進入超時重傳的組數(shù)，前兩個文件傳輸實驗的超時重傳組數(shù)10組和9組，進入超時重傳的組中的每一組的重傳次數(shù)都沒有超過3次，所以文件傳輸成功率為100%.第三個實驗的超時重傳組數(shù)為11組，并且有一組實驗的超時重傳實驗次數(shù)超過設定閾值的3次，系統(tǒng)自動中斷了此次傳輸，故最終的成功率是98%.

實驗結果表明，當網(wǎng)絡環(huán)境不穩(wěn)定時，文件傳輸過程中會出現(xiàn)丟包的情況，超時重傳機制的增加，有效提高了系統(tǒng)文件傳輸?shù)目煽啃?

4 結束語

針對物聯(lián)網(wǎng)系統(tǒng)中設備之間存在的文件傳輸需求，以MQTT發(fā)布/訂閱模型為基礎，采用拆分傳輸方式，增加確保文件可靠傳輸?shù)拇_認應答、超時重傳機制，實現(xiàn)了物聯(lián)網(wǎng)系統(tǒng)中小型嵌入式設備節(jié)點之間的文件傳輸.通過軟件設計對文件傳輸方法進行實現(xiàn)，并搭建硬件平臺進行功能測試.測試結果表明，系統(tǒng)功能完整，可以實現(xiàn)物聯(lián)網(wǎng)系統(tǒng)中設備端到設備端之間可靠的文件傳輸.目前，已經(jīng)在實驗室遠程情感交互產(chǎn)品中得到應用.

[1] 許金喜,張新有.Android平臺基于MQTT協(xié)議的推送機制[J].計算機系統(tǒng)應用,2015,24(1):185-190.

[2] 姜 妮,張 宇.基于MQTT物聯(lián)網(wǎng)消息推送系統(tǒng)[J].網(wǎng)絡新媒體技術,2014,31(2):47-51.

[3] 樓亮亮,金彥亮.物聯(lián)網(wǎng)設備無線固件升級技術的研究[J].單片機與嵌入式系統(tǒng)應用,2015,54(6):34-38.

[4] 李小波.基于ARM的TFTP協(xié)議的實現(xiàn)[J].工業(yè)儀表與自動化裝置,2016,18(6):4-9.

[5] 周蘭鳳,孟 馳,彭俊杰.一種基于云環(huán)境的文件存儲策略的研究[J].計算機工程與科學,2016,38(2):262-268.

[6] 陳 旖,許 力,張美平.適用于大規(guī)模無線傳感器網(wǎng)的流量優(yōu)化系統(tǒng)設計[J].計算機應用,2015,35(4):905-909.

[7] 溫彬民.一種基于自適應心跳機制的MQTT通信協(xié)議的研究與應用[D].廣州：華南理工大學,2015.

[8] Lee S,Kim H,Hong D,et al.Correlation analysis of MQTT loss and delay according to QoS level[C]//Information Networking.Washington: IEEE Computer Society Washington,2013:714-717.

[9] Custura D.System for multicast file transfer[J].Journal of Mobile Embedded & Distributed Systems,2012,4(1):31-37.

[10] D Thangavel,X Ma,A Valera,et al.Performance evaluation of MQTT and CoAP via a common middleware[J].IEEE,2014,11(2):79-86.

[11] 張玉杰,鄭 培.KNX-TCP/IP 協(xié)議轉(zhuǎn)換網(wǎng)關的設計與實現(xiàn)[J].自動化儀表,2014,35(12):49-52.

[12] 陳紹煒,魏 剛.TMS320C6416程序以太網(wǎng)遠程更新技術研究[J].現(xiàn)代電子技術,2014,37(12):125-128.

[13] 孫棣華,陸 旭,廖孝勇,等.面向設備監(jiān)控的LwIP協(xié)議棧擴展設計[J].電子技術應用,2013,39(6):10-13.

[14] 高兆強,王紹舉,徐 偉,等,FATFS在嵌入式操作系統(tǒng)FreeRTOS中的移植與應用[J].現(xiàn)代電子技術,2017,40(6):65-67.

[15] 張為金.資源共享與移動學習平臺中若干JSON問題研究[D].西安:西安電子科技大學,2014.

[16] 羅江華.基于MD5與Base64的混合加密算法[J].計算機應用,2012,32(S1):47-49.