嵌入式多節點的無線批量程序更新系統設計(二)

　3.2 可靠數據分發協議的設計

　　在闡述具體的設計思路之前，先提出以下應用場景的假設。

　　假設一：網絡節點不支持高級的操作系統?？梢岳斫鉃楸仨毧紤]節點處理和通信能力有限，而且通信協議要從底層(如MAC層)實現。

　　假設二：大部分待燒錄節點分布在數據基站的通訊范圍之內?？梢岳斫鉃橥ㄐ艆f議不需要實現復雜的多跳通信和流水線，可以充分利用數據基站第一次數據廣播，這一點下文會詳細闡述。

　　基于以上兩點假設，可靠性數據分發協議的具體設計如下。

　　考慮到不同平臺的無線收發模塊提供的服務接口和通信質量的差異以及程序更新對網絡可靠性的要求，通信協議選擇在網絡層實現可靠數據分發的機制，協議只需要硬件平臺在MAC層提供收發數據幀的應用接口即可。協議中，數據分發分為兩個階段：第一輪發送階段和節點間交流階段。圖4.2為兩個階段通信方式示意圖。

　　(實線代表發送完整數據文件，虛線表示發送數據頁)

　　1、第一輪發送階段。

　　數據基站(如PC)在接收節點準備好后不間斷廣播數據幀，直至數據發送結束;接收節點盡力接收數據，并記錄自己已有數據幀的id信息，期間不向源節點發送反饋信息。

　　在原始的Deluge協議中沒有這一階段，因為Deluge協議中可能無線傳感器網絡龐大，分布范圍也較廣，所以數據分發一旦啟動，所有接收到數據的節點都參與到數據發送中來;而本設計中，網絡充分利用了假設二中的節點分布條件，通常情況下，在第一輪發送結束后，相當大比例的節點就已經接收到了大部分的數據，而這個過程中因為只有數據基站在發送廣播，網絡中數據傳輸的效率是最高的。當然，這種節點分布條件不滿足的情況也不會明顯降低數據分發效率。

　　節點間交流階段。

　　交流階段參考了trickle算法的“polite gossip”策略，所有節點(包括數據基站)都參與到交流中去。每個節點的交流的目的都是相同的，即將自己擁有的數據包發送給需要的節點和請求并接收自己需要的數據包。

　　第2階段是保證可靠性的關鍵，協議中讓源節點也參與到交流中來，這是為了防止網絡狀況極差以至在第一輪發送結束之后所有節點接收數據的總和都不構成完整數據文件的極端情況。這一步中，節點長時間處于“維護”狀態標志數據分發結束。

　　節點首先廣播廣告，每一個廣告包含一個摘要(φ)，摘要(φ)由兩部分組成：(1)本節點的IP標識v。(2)本節點的最大可用頁號p，即φ(v,p)?？捎庙撎杙的定義：頁p所包含的包被節點全部接收，稱頁p完成。頁p被完成并且它之前的所有的頁(0,p)也被節點全部接收，稱頁p可用。節點通過廣告來了解對方擁有的數據信息，繼而向比自己數據更完備的節點發送數據頁請求。協議中將時間分成時間片(round)，在每一個時間片中，節點來決定是否廣播一個廣告。假設時間片的長度由Tm,i來表示，它的上下界由Tl和Th來表示，則有取Tl

　　交流階段中，節點擁有“維護”、“請求”和“發送”中的人一個狀態。節點在“維護”狀態廣播廣告并聽取其他節點的廣播;在請求階段向其他節點發送數據頁請求，并接收對方發來的數據;在發送狀態廣播被請求的數據頁。圖4.3為狀態轉換示意圖。主要的交流規則如下。

　　(1)“維護”狀態規則

　　M1: 假設時間片i的開始時間為ti，節點在ti+ri的時間段內，若接收不到廣告φ'=φ，則廣播廣告φ;若收到與φ不一致的廣告(包括φ'=φ、廣告幀和數據幀等)，則調整時間片為Tl，并立即重新開始時間片;若接收到廣告φ'=φ，則調整時間片為min(2*Tm,i ,Th )。

　　M2: 節點在收到廣告φ'(v',p')中p'大于自身的最大可用頁p時，轉向“請求”狀態，向節點v'發送數據頁請求;節點收到請求幀，則轉向“發送”狀態，廣播被請求數據頁。

　　規則1能控制冗余廣告的發送，節約網絡資源，并且根據網絡狀況動態調整時間片長度，從而是網絡資源得到有效的利用。

　　規則2實現從“維護”狀態到“請求”和“發送”狀態的轉換。

　　(2)“請求”狀態規則：

　　M3：若節點在向源節點發出數據頁請求后節點在時間t(t為自定義時間長度，是經驗值，根據網絡狀況而定)內沒有收到數據，則再次發送請求，若累計請求次數大于k(k為自定義次數)，則認為請求失敗，返回“維護”狀態;若節點接收到數據頁，則在接收結束后返回“維護”狀態。

　　規則3中考慮到網絡的質量因素，定義了等待時間t和最大請求次數k。

　　(3)“發送”狀態規則：

　　M4：節點進入“發送”狀態立即廣播被請求的數據頁，廣播結束后返回“維護”狀態。

　　規則4中要注意的是，節點以廣播的方式發送數據，這意味著處于“請求”狀態的節點可以接收任何節點(不一定是它請求的指定節點)發送的符合其需要的數據包，這也是協議中避免網絡冗余的一個體現。

　　以上是本設計中可靠數據分發協議的全部內容，本文在下一節中將詳細論述協議的軟件設計實現。

　　3.3 可靠數據分發協議的軟件設計實現

　　協議的軟件設計在網絡層實現，涉及到MAC層接口的調用。本節先簡單介紹本設計實驗平臺上網絡模塊提供的MAC層應用接口，然后詳細論述軟件的設計和實現。

　　3.3.1 MAC層接口簡介

　　首先做兩點說明。

　　第一，設計中使用的MAC層接口不提供絕對可靠的網絡通信。一方面是因為設計使用實驗室自制的硬件平臺主要用于做群體實驗，而群體實驗不需要可靠的網絡通信，所以平臺的通信模塊也沒有能實現可靠通信的機制;另一方面要求MAC層提供可靠通信也不是必要的。

　　第二，網絡層只使用了MAC層提供的數據幀發送和數據幀接收兩個接口，網絡層的幀結構包含在MAC數據幀的數據域中。

　　從第一點可以看到，協議在網絡層實現可靠數據傳輸的機制，降低了對MAC層通信質量的要求，而第二點說明協議僅僅需要MAC層提供兩個最基本的應用接口。本設計中的可靠數據分發協議對底層通信的要求很低，具有較好的魯棒性和可移植性。

　　本設計實驗平臺上提供的MAC層數據幀發送命令結構如圖4.4所示，其中區域3為數據域，包含網絡層的幀結構，另外節點在MAC層以廣播的方式通信，所以命令中不包含源節點和目的節點的地址信息。MAC層接收到數據幀后，將數據域分離出來存儲到接收緩存區;發送數據時，將發送緩存區中的數據加上MAC層數據幀的頭部和尾部并發送出去，網絡層只關心發送和接收緩沖區中的數據。這里規定以下章節中提到的各種幀結構均指網絡層幀結構。

　　3.3.2 可靠數據分發協議的數據結構設計

　　網絡層數據要經過緩存，解析再到存儲或者執行三步操作，并且不同種類的幀要區別處理，因此一個好的數據結構設計方案對簡化數據處理操作和提高數據處理效率是非常有必要的。圖4.5為網絡層數據流圖，數據幀的流向為：

　　從MAC層讀入后放入原始數據緩沖區;

　　經解析后得到幀結構;

　　將幀結構作相關處理后僅提取頁號(p)、幀號(id)和數據(data)放到寫flash緩沖區;

　　寫flash。

　　注意以上是數據幀的流向，除數據幀以外的其他類型幀(如請求幀，結束幀等)只執行第(1)、(2)步操作。下面著重論述圖中每個階段涉及到的數據結構。