基于改進(jìn)代碼分發(fā)協(xié)議的遠(yuǎn)程代碼更新技術(shù)研究?

高 菲

基于改進(jìn)代碼分發(fā)協(xié)議的遠(yuǎn)程代碼更新技術(shù)研究?

高 菲

（寶雞職業(yè)技術(shù)學(xué)院 寶雞 721000）

首先對(duì)經(jīng)典的代碼分發(fā)協(xié)議進(jìn)行改進(jìn)，控制信息使用Trickle協(xié)議進(jìn)行維護(hù)，用于通知整個(gè)網(wǎng)絡(luò)當(dāng)前分發(fā)的版本信息，利用廣播的形式分發(fā)數(shù)據(jù)，使通信范圍內(nèi)所有節(jié)點(diǎn)都能接收到數(shù)據(jù)。之后，設(shè)計(jì)遠(yuǎn)程代碼更新系統(tǒng)，將系統(tǒng)分為三個(gè)部分，分別為上位機(jī)、網(wǎng)關(guān)節(jié)點(diǎn)以及傳感器節(jié)點(diǎn)。重點(diǎn)設(shè)計(jì)具有代碼更新功能的傳感器節(jié)點(diǎn)的軟件，將節(jié)點(diǎn)的存儲(chǔ)空間分為引導(dǎo)部分和程序部分，利用不同的存儲(chǔ)器映射進(jìn)行版本切換。實(shí)驗(yàn)結(jié)果表明系統(tǒng)能夠成功完成遠(yuǎn)程代碼更新；能夠同時(shí)更新多個(gè)節(jié)點(diǎn)，能夠支持多跳的更新，在發(fā)生丟包的情況下，能對(duì)丟失數(shù)據(jù)進(jìn)行請(qǐng)求，保證傳輸代碼的完整性。

無(wú)線傳感器網(wǎng)絡(luò)；遠(yuǎn)程代碼更新；數(shù)據(jù)分發(fā)；代碼分發(fā)

AbstractThis paper aims at improving the classic code distribution agreement，controlling information by the Trickle proto?col for maintenance and version information for the entire network current distributing，through broadcast in the form of a distributed data，which makes communication within the scope of all nodes receiving the data possible.After the remote code update system de?sign，the system is divided into three parts，respectively for PC，the gateway node and sensor node.The key design is softwear which has the function of code updating of sensor nodes.The nodes of the storage space is divided into guiding parts and procedures，using different memory mapping to switch from the version.Experimental results show that the system can successfully complete re?mote code updates，and it can update multiple nodes at the same time，can support multiple hops update.In the event of a lost pack?age，it can also request data loss to ensure the integrity of the transmission code.

Key W ord wireless sensor network，code update，data distribution，code distribution

Class NumberTP393

1 引言

無(wú)線傳感器網(wǎng)絡(luò)由大量擁有無(wú)線發(fā)射模塊的節(jié)點(diǎn)組成，節(jié)點(diǎn)依據(jù)各自的應(yīng)用環(huán)境配備不同的傳感器，利用傳感器采集數(shù)據(jù)后，以無(wú)線的方式傳輸至匯聚節(jié)點(diǎn)，以達(dá)到遠(yuǎn)程監(jiān)測(cè)的目的。節(jié)點(diǎn)部署完畢后，很多情況下需要對(duì)節(jié)點(diǎn)進(jìn)行代碼更新。遠(yuǎn)程代碼更新已成為無(wú)線傳感器網(wǎng)絡(luò)領(lǐng)域重要的研究課題。目前，國(guó)內(nèi)外研究人員針對(duì)遠(yuǎn)程代碼更新方法已進(jìn)行相關(guān)研究，研究方向主要為代碼分發(fā)以及數(shù)據(jù)壓縮。若要使用代碼更新技術(shù)需要額外的存儲(chǔ)空間，完成代碼更新需要完整的解決方案，因此對(duì)遠(yuǎn)程代碼更新技術(shù)的研究很有必要。

2 代碼分發(fā)協(xié)議

在實(shí)現(xiàn)代碼更新的過(guò)程中，各個(gè)節(jié)點(diǎn)需要各自廣播當(dāng)前節(jié)點(diǎn)的版本信息與網(wǎng)絡(luò)中的控制信息，以保證整個(gè)網(wǎng)絡(luò)均能收到網(wǎng)關(guān)節(jié)點(diǎn)發(fā)送的控制消息，并運(yùn)行在正確的版本上。各節(jié)點(diǎn)通過(guò)比對(duì)版本信息，判定是否需要進(jìn)行數(shù)據(jù)交換，完成整個(gè)代碼的分發(fā)工作。Trickle數(shù)據(jù)分發(fā)協(xié)議能夠解決小數(shù)據(jù)量的分發(fā)，可以用于代碼更新過(guò)程中控制字以及版本信息的分發(fā)。當(dāng)數(shù)據(jù)量達(dá)到一定規(guī)模的情況下，需要使用不同的協(xié)議用于完成整段代碼的分發(fā)功能。Deluge協(xié)議是一種泛洪式的代碼分發(fā)協(xié)議，即代碼通過(guò)廣播的形式，以擴(kuò)散的方式分發(fā)至各個(gè)節(jié)點(diǎn)。

為適應(yīng)低功耗、低成本的系統(tǒng)設(shè)計(jì)，需要對(duì)協(xié)議進(jìn)行適當(dāng)修改。同樣將分發(fā)過(guò)程分為三個(gè)階段：維護(hù)階段、RX階段以及TX階段。Deluge協(xié)議使用了流水線技術(shù)以提高代碼傳播速度，但其提高的程度不高，取消流水線技術(shù)，待節(jié)點(diǎn)完全接收完畢后再行使分發(fā)的功能，從而減輕了接收端的負(fù)擔(dān)。

Trickle協(xié)議可以滿足少量數(shù)據(jù)分發(fā)節(jié)點(diǎn)維護(hù)過(guò)程，使用Trickle協(xié)議進(jìn)行維護(hù)，維護(hù)的數(shù)據(jù)包括上位機(jī)發(fā)送的對(duì)全網(wǎng)的控制命令，如節(jié)點(diǎn)重啟、版本切換以及代碼分發(fā)，同時(shí)控制命令包含了待分發(fā)網(wǎng)絡(luò)的版本信息，通過(guò)網(wǎng)絡(luò)版本信息與節(jié)點(diǎn)當(dāng)前版本比對(duì)，節(jié)點(diǎn)即可知道自己應(yīng)該處于接收還是分發(fā)狀態(tài)。

更新過(guò)程如圖1所示，網(wǎng)絡(luò)由4個(gè)節(jié)點(diǎn)組成，分別為網(wǎng)關(guān)節(jié)點(diǎn)，傳感器節(jié)點(diǎn)A、B、C，其中網(wǎng)關(guān)節(jié)點(diǎn)與節(jié)點(diǎn)A、B在一跳的范圍內(nèi)，節(jié)點(diǎn)C與網(wǎng)關(guān)節(jié)點(diǎn)相距較遠(yuǎn)，無(wú)法直接通信。最初各節(jié)點(diǎn)處于維護(hù)狀態(tài)，各節(jié)點(diǎn)隨機(jī)地廣播ADV消息，以保證全網(wǎng)的版本一致。網(wǎng)關(guān)節(jié)點(diǎn)從上位機(jī)接收到了新版本代碼，需要分發(fā)至整個(gè)網(wǎng)絡(luò)。分發(fā)過(guò)程如下。

1）網(wǎng)關(guān)節(jié)點(diǎn)首先利用Trickle協(xié)議發(fā)送CTL消息，該消息中包含最新版本號(hào)以及最新版本文件大小，該消息將會(huì)發(fā)送至整個(gè)網(wǎng)絡(luò)。

2）當(dāng)CTL消息傳播完畢后，各節(jié)點(diǎn)將隨機(jī)發(fā)送ADV消息，ADV消息中包含當(dāng)前節(jié)點(diǎn)的版本信息新版本節(jié)點(diǎn)發(fā)現(xiàn)舊版本信息后盡快廣播一個(gè)ADV消息，讓周?chē)?jié)點(diǎn)知道該節(jié)點(diǎn)版本是最新的。

3）節(jié)點(diǎn)A、B接收到網(wǎng)關(guān)節(jié)點(diǎn)發(fā)送的ADV消息，從消息中解析出網(wǎng)關(guān)節(jié)點(diǎn)有新版本數(shù)據(jù)可用，隨即進(jìn)入RX狀態(tài)，節(jié)點(diǎn)A搶先向網(wǎng)關(guān)節(jié)點(diǎn)發(fā)送了REQ消息。

4）網(wǎng)關(guān)節(jié)點(diǎn)接收到來(lái)自節(jié)點(diǎn)A的發(fā)送消息后進(jìn)人TX狀態(tài)，廣播DATA數(shù)據(jù)。

5）節(jié)點(diǎn)A、B同時(shí)接收到來(lái)自網(wǎng)關(guān)節(jié)點(diǎn)的DA?TA數(shù)據(jù)，節(jié)點(diǎn)B受到抑制，無(wú)需再發(fā)送REQ消息。

6）節(jié)點(diǎn)A、B接收到完整更新數(shù)據(jù)，重啟節(jié)點(diǎn)，重新進(jìn)入維護(hù)狀態(tài)，此時(shí)節(jié)點(diǎn)A、B運(yùn)行新版本的程序。

7）節(jié)點(diǎn)B重啟后，發(fā)送ADV消息，由節(jié)點(diǎn)C接收到，轉(zhuǎn)入RX狀態(tài)，重復(fù)之前節(jié)點(diǎn)A、B接收的步驟。

圖1 分發(fā)流程

在更龐大的網(wǎng)絡(luò)中，更新代碼將一層層的向外擴(kuò)散，直至整個(gè)網(wǎng)絡(luò)都運(yùn)行最新的代碼。在更新過(guò)程中，待接收的節(jié)點(diǎn)永遠(yuǎn)處于接收狀態(tài)，直至代碼完全更新完畢對(duì)于節(jié)點(diǎn)而言，單一的接收、發(fā)送狀態(tài)，減輕了節(jié)點(diǎn)在同一時(shí)刻的負(fù)擔(dān)。

3 更新系統(tǒng)設(shè)計(jì)方案

遠(yuǎn)程代碼更新系統(tǒng)以硬件進(jìn)行劃分，可以劃分為三個(gè)部分，分別為：上位機(jī)、網(wǎng)關(guān)節(jié)點(diǎn)以及傳感器節(jié)點(diǎn)。為了能實(shí)現(xiàn)代碼的遠(yuǎn)程更新，需要對(duì)三部分進(jìn)行逐一設(shè)計(jì)，最終使得代碼能完整的從上位機(jī)傳至網(wǎng)關(guān)節(jié)點(diǎn)，再?gòu)木W(wǎng)關(guān)節(jié)點(diǎn)分發(fā)至整個(gè)網(wǎng)絡(luò)。

3.1 遠(yuǎn)程代碼更新過(guò)程

遠(yuǎn)程代碼更新過(guò)程如圖2所示：在上位機(jī)編寫(xiě)帶有分發(fā)協(xié)議的基本程序。將基本程序通過(guò)串口燒寫(xiě)至各個(gè)節(jié)點(diǎn)，各個(gè)節(jié)點(diǎn)在網(wǎng)絡(luò)上正常工作。需要進(jìn)行代碼更新時(shí)，在上位機(jī)編寫(xiě)新的程序，編譯完成后通過(guò)串口燒入網(wǎng)關(guān)節(jié)點(diǎn)。上位機(jī)通過(guò)串口向網(wǎng)關(guān)節(jié)點(diǎn)發(fā)送分發(fā)指令，網(wǎng)關(guān)節(jié)點(diǎn)收到指令后，將指令消息廣播至整個(gè)網(wǎng)絡(luò)。節(jié)點(diǎn)A、B利用分發(fā)協(xié)議先接收到完整程序，啟用新版本程序。節(jié)點(diǎn)C從節(jié)點(diǎn)B接收新版本程序，并重啟更新。

圖2 遠(yuǎn)程代碼更新圖

3.2 更新系統(tǒng)組成部分

為完成上述的代碼更新過(guò)程，需要分別設(shè)計(jì)上位機(jī)軟件、網(wǎng)關(guān)節(jié)點(diǎn)程序以及節(jié)點(diǎn)程序三部分。

上位機(jī)軟件使用C#編程，上位機(jī)程序共需要完成兩部分功能，首先將iHex文件發(fā)送至網(wǎng)關(guān)節(jié)點(diǎn)，其次需要給網(wǎng)關(guān)節(jié)點(diǎn)發(fā)送控制命令，控制整個(gè)網(wǎng)絡(luò)的分發(fā)狀態(tài)。

網(wǎng)關(guān)節(jié)點(diǎn)使用C編程，負(fù)責(zé)接收上位機(jī)發(fā)送的新版本程序，接收上位機(jī)發(fā)送的控制命令。做出相應(yīng)的響應(yīng)。解析上位機(jī)發(fā)送新版本程序的命令，負(fù)責(zé)將新版本程序分發(fā)至各個(gè)傳感器節(jié)點(diǎn)。傳感器節(jié)點(diǎn)的程序又分為兩個(gè)部分，啟動(dòng)引導(dǎo)部分與運(yùn)行程序部分。啟動(dòng)引導(dǎo)部分負(fù)責(zé)各版本之間的切換工作，在分發(fā)過(guò)程中，程序會(huì)對(duì)版本啟動(dòng)信息進(jìn)行修改，在啟動(dòng)過(guò)程中讀取啟動(dòng)信息，跳轉(zhuǎn)到特定版本的運(yùn)行程序。運(yùn)行程序包含正常的采集數(shù)據(jù)或其他節(jié)點(diǎn)功能程序，還包含了分發(fā)協(xié)議。在運(yùn)行過(guò)程中，節(jié)點(diǎn)功能程序與分發(fā)協(xié)議互不干擾。

4 代碼分發(fā)協(xié)議詳細(xì)設(shè)計(jì)

節(jié)點(diǎn)代碼分發(fā)協(xié)議與網(wǎng)關(guān)節(jié)點(diǎn)使用的協(xié)議一致，傳感器節(jié)點(diǎn)在模塊部分相比網(wǎng)關(guān)節(jié)點(diǎn)減少了串口接收功能。分發(fā)協(xié)議主要模塊如圖3所示，總模塊利用Trickle接收到的信息進(jìn)行判定分發(fā)方式，Object分發(fā)模塊負(fù)責(zé)對(duì)整個(gè)版本的分發(fā)或接收，調(diào)用頁(yè)分發(fā)模塊進(jìn)行每一頁(yè)的分發(fā)或接收，當(dāng)新版本程序接收完成后進(jìn)行重啟。新版本程序裝入節(jié)點(diǎn)，并成功重啟后，將作為分發(fā)節(jié)點(diǎn)，將新版本程序分發(fā)到更遠(yuǎn)的節(jié)點(diǎn)。

圖3 代碼分發(fā)模塊

4.1 分發(fā)總模塊

分發(fā)總模塊為分發(fā)協(xié)議最頂層的模塊，控制整個(gè)協(xié)議的工作狀態(tài)。在節(jié)點(diǎn)啟動(dòng)初始化完畢后。將調(diào)用Trickle分發(fā)模塊，開(kāi)啟Trickle分發(fā)功能，用于維護(hù)一段控制信息，該信息包括控制命令、分發(fā)代碼的版本號(hào)以及分發(fā)代碼的大小。

typedef nx_struct DelugeCmd｛

nx_uint8_t type；

nx_uint8_t uidhash；

nx_uintl6_t size；

｝DelugeCmd；

在維護(hù)階段，節(jié)點(diǎn)周期性的廣播該信息，以保證全網(wǎng)信息一致。當(dāng)Trickle模塊從其他節(jié)點(diǎn)接收到新的控制消息時(shí)，將會(huì)以事件的方式通知分發(fā)總模塊有新消息，分發(fā)總模塊對(duì)該事件進(jìn)行響應(yīng)。分發(fā)模塊讀取新消息的控制字，節(jié)點(diǎn)收到的控制命令有兩種情況，分別為停止分發(fā)和分發(fā)。

當(dāng)節(jié)點(diǎn)接收到停止分發(fā)命令，則調(diào)用Object分發(fā)模塊的接口停止代碼分發(fā)，Object分發(fā)模塊再調(diào)用頁(yè)模塊的接口停止當(dāng)前頁(yè)分發(fā)操作，最終整個(gè)程序停止分發(fā)或接收代碼。

當(dāng)節(jié)點(diǎn)接收到分發(fā)指令后，需要讀取分發(fā)指令的程序版本號(hào)以及程序大小。將讀取到的版本號(hào)與自身的版本號(hào)進(jìn)行比對(duì)，決定該節(jié)點(diǎn)是處于接收狀態(tài)還是分發(fā)狀態(tài)。調(diào)用Object分發(fā)模塊的pub?lish或receive接口，使程序進(jìn)入接收或分發(fā)狀態(tài)。調(diào)用方式如下。

task void taskRequest（）｛

switch（state）｛

case S_PUB：

call ObjectTransfer.publish（lastCmd.uidhash，lastC?md.size）；

break；

case SRECV：

call ObjectTransfer.receive（lastCmd.uidhash，lastCmd.size，bootArgs.bootBank）；

break；｝｝

收到版本信息后，會(huì)設(shè)置當(dāng)前節(jié)點(diǎn)狀態(tài)。并且在任務(wù)隊(duì)列中加入taskReguest任務(wù)，任務(wù)的調(diào)度方式是先進(jìn)先出的，用于處理對(duì)時(shí)間要求不高的事務(wù)。對(duì)于分發(fā)任務(wù)，需要傳遞代碼版本號(hào)以及代碼大小的參數(shù)。對(duì)于接收任務(wù)，需要額外傳遞啟動(dòng)Bank號(hào)的信息，通過(guò)當(dāng)前啟動(dòng)版本所在Bank位置的信息，決定新版本程序存放位置。

4.2 Ob ject分發(fā)模塊

Object分發(fā)模塊管理整個(gè)代碼的分發(fā)或接收進(jìn)度，全網(wǎng)廣播消息，使各節(jié)點(diǎn)完成各自的分發(fā)或接收工作。該模塊提供的接口被分發(fā)總模塊調(diào)用，向總模塊提供分發(fā)、接收和停止的功能，在同一時(shí)刻，節(jié)點(diǎn)僅可能有一種狀態(tài)，即分發(fā)、接收或停止。當(dāng)接收到停止指令時(shí)，停止一切消息的傳輸，并調(diào)用頁(yè)模塊的接口，使得頁(yè)模塊也停止傳輸數(shù)據(jù)，等待下一步的命令。

在該模塊中周期性地廣播ADV消息，與Trick?le維護(hù)的消息不同，該消息除了包含代碼版本號(hào)和代碼大小外，還包含了當(dāng)前節(jié)點(diǎn)已完成的頁(yè)數(shù)。通過(guò)已完成頁(yè)數(shù)，可判斷出該節(jié)點(diǎn)是處于接收還是分發(fā)模式。

typedef nx_struct ObjDesc｛

nx_object id t objid；

nx_page num_t numPgs；

nx_age_num_t numPgsComplete；

｝ObjDesc；

若節(jié)點(diǎn)接收到其他節(jié)點(diǎn)廣播的ADV消息，通過(guò)收到的ADV消息判斷廣播節(jié)點(diǎn)與當(dāng)前節(jié)點(diǎn)的狀態(tài)是否一致，如果狀態(tài)一致，即同時(shí)處于分發(fā)狀態(tài)或同時(shí)處于接收狀態(tài)，則抑制本輪廣播，并且當(dāng)節(jié)點(diǎn)多次抑制廣播信息后，將延長(zhǎng)廣播周期，以節(jié)省能耗。

若分發(fā)節(jié)點(diǎn)接收到由接收節(jié)點(diǎn)廣播的ADV消息，則繼續(xù)等待定時(shí)器的觸發(fā)，廣播當(dāng)前ADV消息，以使得接收節(jié)點(diǎn)可以從當(dāng)前節(jié)點(diǎn)獲取新版本信息。若接收節(jié)點(diǎn)接收到由分發(fā)節(jié)點(diǎn)廣播的ADV消息，則調(diào)用頁(yè)模塊提供的接口，準(zhǔn)備請(qǐng)求接收需要接收的頁(yè)，接收節(jié)點(diǎn)每次僅請(qǐng)求接收一頁(yè)消息。Object分發(fā)模塊管理著當(dāng)前節(jié)點(diǎn)已接收到的頁(yè)數(shù)，有分發(fā)節(jié)點(diǎn)時(shí)調(diào)用頁(yè)模塊接口請(qǐng)求接收下一頁(yè)。頁(yè)模塊完成一整頁(yè)的接收后，會(huì)通知Object分發(fā)模塊，Object分發(fā)模塊將完成頁(yè)數(shù)加一，等待ADV消息再請(qǐng)求接收下一頁(yè)。

4.3 頁(yè)分發(fā)模塊

在程序的分發(fā)過(guò)程中，以頁(yè)為一個(gè)單位進(jìn)行傳輸，定義每個(gè)頁(yè)的大小為1024個(gè)字節(jié)。Object分發(fā)模塊負(fù)責(zé)管理當(dāng)前程序以完成的頁(yè)數(shù)，頁(yè)分發(fā)模塊完成對(duì)某一頁(yè)的發(fā)送或接收操作。將程序分割成頁(yè)后，由于1024字節(jié)大小依舊超出了無(wú)線傳輸包的字節(jié)限制，需要使用位圖對(duì)數(shù)據(jù)包進(jìn)行管理。

定義一個(gè)byte類型數(shù)組pktsToReceive［N］，該數(shù)組的總位數(shù)表示一頁(yè)中共有多少數(shù)據(jù)包等待傳輸，例如一個(gè)包中可以裝100個(gè)字符的數(shù)據(jù)，則每一頁(yè)需要傳輸11個(gè)包，則此處N為2，數(shù)組中共有16位。數(shù)組中的每一位代表一個(gè)數(shù)據(jù)包是否接收，作為接收節(jié)點(diǎn)，將該數(shù)組包含在REQ消息中，向分發(fā)節(jié)點(diǎn)REQ消息。分發(fā)節(jié)點(diǎn)接收到REQ消息后，查看其中的請(qǐng)求頁(yè)號(hào)以及pktsToReceive數(shù)組，得知接收節(jié)點(diǎn)需要的數(shù)據(jù)部分，分發(fā)節(jié)點(diǎn)從Flash中讀取應(yīng)分發(fā)的數(shù)據(jù)，并且進(jìn)行廣播發(fā)送。

頁(yè)分發(fā)模塊負(fù)責(zé)傳輸和接收兩種消息，分別為請(qǐng)求消息與數(shù)據(jù)消息。

typedef nx_struct DelugeReqMsg｛

nx_uintl6_t dest；

nx_uintl6_t sourceAddr；

nx_object_id_t objid；

nx_page_num_t pgNum；

nx_uint8_t requestedPkts［DELUGET2-KTes BIT?VEC_SIZE］；

｝DelugeReqMsg；

請(qǐng)求消息包含了請(qǐng)求節(jié)點(diǎn)的地址、目的地址、請(qǐng)求的版本號(hào)、頁(yè)號(hào)以及位圖信息。

typedef nx_struct DelugeDataMsg｛

nx_object_id_t objid；

nx_page_num_t pgNum；

nx_uint8_t pktNum；

nx_uint8_t data［DELUGET2 PKT_PAYLOAD SIZE］；

｝DelugeDataMsg；

數(shù)據(jù)消息包含了發(fā)送的版本號(hào)、頁(yè)號(hào)、數(shù)據(jù)包號(hào)以及數(shù)據(jù)信息。

頁(yè)分發(fā)模塊同樣有三種狀態(tài)，分別為分發(fā)、接收和停止?fàn)顟B(tài)，其狀態(tài)與Object分發(fā)模塊的狀態(tài)一致，當(dāng)Object分發(fā)模塊狀態(tài)發(fā)生改變時(shí)，頁(yè)分發(fā)模塊的狀態(tài)也會(huì)隨之改變。

接收狀態(tài)下，頁(yè)分發(fā)模塊完成兩個(gè)功能。分別為數(shù)據(jù)請(qǐng)求與數(shù)據(jù)接收。每當(dāng)Object分發(fā)模塊得知有其他新版本節(jié)點(diǎn)時(shí)，將告知頁(yè)分發(fā)模塊，頁(yè)分發(fā)模塊準(zhǔn)備向新版本節(jié)點(diǎn)請(qǐng)求接收數(shù)據(jù)。由于可能有多個(gè)節(jié)點(diǎn)同時(shí)得知網(wǎng)絡(luò)中存在新版本節(jié)點(diǎn)防止多個(gè)節(jié)點(diǎn)同時(shí)向新版本節(jié)點(diǎn)發(fā)送請(qǐng)求數(shù)據(jù)，節(jié)點(diǎn)經(jīng)過(guò)一段隨機(jī)時(shí)間的延時(shí)后再向新版本節(jié)點(diǎn)發(fā)送請(qǐng)求。無(wú)論是否發(fā)送了請(qǐng)求數(shù)據(jù)，各節(jié)點(diǎn)均能接收到來(lái)自新版本節(jié)點(diǎn)的廣播數(shù)據(jù)，判斷該數(shù)據(jù)是否為當(dāng)前節(jié)點(diǎn)需要的數(shù)據(jù)，若需要該數(shù)據(jù)則寫(xiě)入Flash，并且抑制當(dāng)前即將發(fā)送的請(qǐng)求。當(dāng)節(jié)點(diǎn)接收到待接收頁(yè)的完整數(shù)據(jù)后，通知Object分發(fā)模塊，并將待接收頁(yè)設(shè)置為下一頁(yè)。分發(fā)狀態(tài)下，等待接收其他節(jié)點(diǎn)發(fā)送的請(qǐng)求數(shù)據(jù)。當(dāng)接收到其他節(jié)點(diǎn)的請(qǐng)求，分析請(qǐng)求信息，準(zhǔn)備請(qǐng)求信息中需求的數(shù)據(jù)，由于請(qǐng)求的數(shù)據(jù)可能需要多個(gè)數(shù)據(jù)包才能傳輸完畢，逐步廣播所有需要發(fā)送的數(shù)據(jù)包，在完整數(shù)據(jù)發(fā)送完成前，忽略其他節(jié)點(diǎn)的請(qǐng)求。

5 多節(jié)點(diǎn)更新實(shí)驗(yàn)

采用一個(gè)網(wǎng)關(guān)節(jié)點(diǎn)、多個(gè)傳感器節(jié)點(diǎn)進(jìn)行實(shí)驗(yàn)。傳感器節(jié)點(diǎn)分布在網(wǎng)關(guān)節(jié)點(diǎn)周?chē)Ｇ覀鞲衅鞴?jié)點(diǎn)可直接與網(wǎng)關(guān)節(jié)點(diǎn)進(jìn)行通信。分發(fā)代碼的大小為26.65KB，傳感器節(jié)點(diǎn)數(shù)量從一個(gè)逐步增加至二十個(gè)。其位置示意圖如圖4所示，網(wǎng)關(guān)節(jié)點(diǎn)通過(guò)上位機(jī)接收指令，進(jìn)行分發(fā)，傳感器節(jié)點(diǎn)均勻分布在網(wǎng)關(guān)節(jié)點(diǎn)周?chē)夷芟嗷ネㄐ拧?/p>

圖4 單跳節(jié)點(diǎn)位置示意圖

圖5 表示了分發(fā)至不同數(shù)量節(jié)點(diǎn)所需使用的時(shí)間。當(dāng)更新一個(gè)節(jié)點(diǎn)時(shí)需使用的時(shí)間為139s，隨著節(jié)點(diǎn)數(shù)量的增多，分發(fā)時(shí)間略有下降，時(shí)間穩(wěn)定在115s左右。由于發(fā)送REQ的等待時(shí)間是隨機(jī)的，當(dāng)節(jié)點(diǎn)數(shù)量增多，總體REQ時(shí)間會(huì)相對(duì)減小，從而分發(fā)速度變得更快了。且當(dāng)網(wǎng)絡(luò)中發(fā)生丟包的情況，當(dāng)一個(gè)節(jié)點(diǎn)接收到了ADV消息。而另一個(gè)節(jié)點(diǎn)沒(méi)接收到的情況下。依舊能夠有一個(gè)節(jié)點(diǎn)向網(wǎng)關(guān)節(jié)點(diǎn)發(fā)REQ消息。而不會(huì)等待網(wǎng)關(guān)節(jié)點(diǎn)發(fā)送第二次的ADV消息，同樣加快了分發(fā)速度。

圖5 節(jié)點(diǎn)更新時(shí)間

當(dāng)傳感器節(jié)點(diǎn)數(shù)量增加到12個(gè)后，分發(fā)速度顯著下降。由于無(wú)線信道的穩(wěn)定性相對(duì)有線傳輸較差，當(dāng)節(jié)點(diǎn)增多時(shí)，丟包的可能性增大，即重傳的次數(shù)增多，導(dǎo)致分發(fā)速度下降。大量節(jié)點(diǎn)同步更新的過(guò)程中。若有某個(gè)節(jié)點(diǎn)A未接收到某個(gè)數(shù)據(jù)包，其請(qǐng)求信息可能會(huì)淹沒(méi)在其他節(jié)點(diǎn)中，即其他節(jié)點(diǎn)搶先向網(wǎng)關(guān)節(jié)點(diǎn)請(qǐng)求數(shù)據(jù)包。其他節(jié)點(diǎn)請(qǐng)求的數(shù)據(jù)包不是節(jié)點(diǎn)A可用的數(shù)據(jù)，導(dǎo)致該節(jié)點(diǎn)無(wú)法直接從網(wǎng)關(guān)節(jié)點(diǎn)偷聽(tīng)得到數(shù)據(jù)，需等到其他節(jié)點(diǎn)完全更新完畢后，才能從之前丟失數(shù)據(jù)的地方繼續(xù)接收新的數(shù)據(jù)。單個(gè)節(jié)點(diǎn)的數(shù)據(jù)包丟失，將使得整個(gè)網(wǎng)絡(luò)的更新時(shí)間變得更長(zhǎng)，當(dāng)無(wú)線信道環(huán)境足夠理想時(shí)，如更新19個(gè)傳感器節(jié)點(diǎn)的情況，其更新速度與更新節(jié)點(diǎn)數(shù)量無(wú)關(guān)。

6 多跳更新實(shí)驗(yàn)

多跳實(shí)驗(yàn)中，各節(jié)點(diǎn)以圖6方式進(jìn)行放置，網(wǎng)關(guān)節(jié)點(diǎn)放置于實(shí)驗(yàn)室房間內(nèi)，傳感器節(jié)點(diǎn)A放置于門(mén)口，傳感器節(jié)點(diǎn)B放置于走廊。傳感器節(jié)點(diǎn)A可與網(wǎng)關(guān)節(jié)點(diǎn)或傳感器節(jié)點(diǎn)B直接通信，網(wǎng)關(guān)節(jié)點(diǎn)與傳感器節(jié)點(diǎn)B不能直接進(jìn)行通信，代碼分發(fā)需要通過(guò)傳感器節(jié)點(diǎn)B進(jìn)行分發(fā)。在更新過(guò)程中，首先需要將代碼分發(fā)至傳感器節(jié)點(diǎn)A，再由傳感器節(jié)點(diǎn)A將代碼分發(fā)至傳感器節(jié)點(diǎn)B，待更新代碼的大小同樣為26.65KB數(shù)據(jù)。

圖6 多跳節(jié)點(diǎn)位置示意圖

分發(fā)過(guò)程中，為了構(gòu)成多跳的網(wǎng)絡(luò)，將節(jié)點(diǎn)布置在距離較遠(yuǎn)的位置，由于接收信號(hào)強(qiáng)度較弱，更易受到干擾，因此丟包的概率顯著提升，觀察偵聽(tīng)軟件偵聽(tīng)到的數(shù)據(jù)包可發(fā)現(xiàn)，傳感器節(jié)點(diǎn)A多次向網(wǎng)關(guān)節(jié)點(diǎn)發(fā)送了重發(fā)的請(qǐng)求。在經(jīng)過(guò)220s后，完成了從網(wǎng)關(guān)節(jié)點(diǎn)傳輸至傳感器節(jié)點(diǎn)A的更新。又經(jīng)過(guò)了500s，最終完成了全部的更新，總共經(jīng)歷了720s。

在傳感器節(jié)點(diǎn)A與傳感器節(jié)點(diǎn)B旁各放置一個(gè)節(jié)點(diǎn)，同樣為一跳，多跳網(wǎng)絡(luò)完整更新的時(shí)間縮短為480s，相比2個(gè)傳感器節(jié)點(diǎn)的更新速度有顯著提升。當(dāng)節(jié)點(diǎn)增多時(shí)，收到包的概率也相對(duì)增加，從而縮短了更新所用的時(shí)間。多跳網(wǎng)絡(luò)的理想更新時(shí)間應(yīng)為當(dāng)前網(wǎng)絡(luò)跳數(shù)乘以單跳網(wǎng)絡(luò)的時(shí)間，未達(dá)到理想速度估計(jì)是由于無(wú)線信道的不穩(wěn)定，常有丟包出現(xiàn)，當(dāng)數(shù)據(jù)無(wú)法正常傳輸至節(jié)點(diǎn)，更新時(shí)間將會(huì)延長(zhǎng)。

7 結(jié)語(yǔ)

無(wú)線傳感器網(wǎng)絡(luò)，是近幾年來(lái)計(jì)算機(jī)技術(shù)方面的熱門(mén)研究對(duì)象之一，而遠(yuǎn)程代碼更新技術(shù)是無(wú)線傳感器網(wǎng)絡(luò)的一個(gè)重要技術(shù)，利用遠(yuǎn)程代碼更新技術(shù)，可以減少不必要的重復(fù)性操作，且對(duì)特殊環(huán)境下的程序調(diào)整尤為重要。本文是無(wú)線傳感器網(wǎng)絡(luò)遠(yuǎn)程代碼更新的系統(tǒng)設(shè)計(jì)方法研究，并進(jìn)行系統(tǒng)的實(shí)現(xiàn)。通過(guò)研究各協(xié)議，完成無(wú)線傳感網(wǎng)絡(luò)遠(yuǎn)程代碼更新的設(shè)計(jì)，更新程序能準(zhǔn)確無(wú)誤的分發(fā)至各個(gè)節(jié)點(diǎn)。

［1］Kulkarni S S，Wang L.MNP：Multihop Network Repro?gramming Service for Sensor Networks［C］//IEEE Interna?tional Conference on Distributed Computing Systems，2005.ICDCS 2005.Proceedings.IEEE，2005：285-286.

［2］Kulkarni S，Wang L.Energy-efficient multihop repro?gramming for sensor networks［J］.Acm Transactions on Sensor Networks，2009，5（2）：1-40.

［3］Rossi M，Bui N，Zanca G，et al.SYNAPSE++：Code Dis?semination in Wireless Sensor Networks Using Fountain Codes［J］.IEEE Transactions on Mobile Computing，2010，9（12）：1749-1765.

［4］Gao Y，Bu J，Dong W，et al.Exploiting Concurrency for Efficient Dissemination in Wireless Sensor Networks［C］//International Conference on Distributed Computing in Sen?sor Systems and Workshops.IEEE，2011：1-8.

［5］ZHAO.Integrated mutual selection based code dissemina?tion for reprogramming wireless sensor networks［J］.Jour?nal of China Universities of Posts&Telecommunications，2013，20（1）：79-84.

［6］Dong W，Liu Y，Zhao Z，et al.Link Quality Aware Code Dissemination in Wireless Sensor Networks［J］.IEEE Transactions on Parallel&Distributed Systems，2014，25（7）：1776-1786.

［7］Alam SM I，Sultana S，Hu Y C，et al.SYREN：Synergis?tic Link Correlation-Aware and Network Coding-Based Dissemination in Wireless Sensor Networks［C］//IEEE，International Symposium on Modeling，Analysis&Simula?tion of Computer and Telecommunication Systems.IEEE，2014：485-494.

［8］Kim D，Nam H，Kim D.Adaptive Code Dissemination Based on Link Quality in Wireless Sensor Networks［J］.IEEE Internet of Things Journal，2016，PP（99）：1-1.

［9］Concepts R.Wireless sensor networks：a survey［J］.Com?puter Networks the International Journal of Computer&Telecommunications Networking，2014，38（4）：393-422.

［10］Levis P，Madden S，Polastre J，et a1.TinyOS：An oper?ating system for sensor networks［J］.Ambient Intelli?gence，2004：383-396.

［11］Li J，Wang F，Duan W Research of TinyOS in Wireless Sensor Networks［J］.Computer Measurement&Control，2006，14（6）：838-840.

Research of Rem ote Code Update Technology Based on the Im proved Code Distribution Agreement

GAO Fei
（Baoji Vocational Technology College，Baoji 721000）

TP393

10.3969/j.issn.1672-9722.2017.09.029

2017年3月13日，

2017年4月20日

高菲，女，碩士研究生，研究方向：計(jì)算機(jī)教育。