基于云分支服務(wù)器的數(shù)據(jù)更新系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

葉文芳，潘國(guó)峰，華 中，齊景愛(ài)

(1.河北工業(yè)大學(xué) 電子信息工程學(xué)院，天津 300401；2.天津鉑創(chuàng)國(guó)茂電子科技發(fā)展有限公司，天津 300384)

?

基于云分支服務(wù)器的數(shù)據(jù)更新系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

葉文芳1，潘國(guó)峰1，華 中2，齊景愛(ài)1

(1.河北工業(yè)大學(xué) 電子信息工程學(xué)院，天津 300401；2.天津鉑創(chuàng)國(guó)茂電子科技發(fā)展有限公司，天津 300384)

基于海思Hi3716C嵌入式云分支服務(wù)器，提出了一種數(shù)據(jù)快速更新的解決方案。服務(wù)器采用Linux操作系統(tǒng)和B/S架構(gòu)，搭建了數(shù)據(jù)更新服務(wù)平臺(tái)。為滿足云分支服務(wù)器實(shí)際需求，通過(guò)增加丟包重傳和分組確認(rèn)機(jī)制，改進(jìn)了傳輸層UDP協(xié)議，然后利用分離請(qǐng)求和更新端口并行傳輸數(shù)據(jù)的多線程機(jī)制，設(shè)計(jì)了應(yīng)用層的數(shù)據(jù)更新協(xié)議。本系統(tǒng)可同時(shí)更新多個(gè)云分支服務(wù)器的不同類型數(shù)據(jù)，特別是在大文件傳輸中，改進(jìn)的UDP傳輸協(xié)議保證了數(shù)據(jù)更新的可靠性，提高了傳輸速度，增強(qiáng)了系統(tǒng)穩(wěn)定性。測(cè)試結(jié)果表明，數(shù)據(jù)更新系統(tǒng)比傳統(tǒng)方法傳輸速度更快，丟包率穩(wěn)定在1%左右，能夠?qū)崿F(xiàn)數(shù)據(jù)快速傳輸，對(duì)大數(shù)據(jù)交互具有重要的實(shí)用價(jià)值。

云分支服務(wù)器；數(shù)據(jù)更新；UDP協(xié)議；海思Hi3716；多線程

云平臺(tái)大數(shù)據(jù)技術(shù)的發(fā)展與應(yīng)用已經(jīng)對(duì)社會(huì)的方方面面產(chǎn)生了深遠(yuǎn)影響。特別在醫(yī)療、教育和服務(wù)業(yè)領(lǐng)域中，大數(shù)據(jù)技術(shù)逐漸成為催生各個(gè)領(lǐng)域變革的科技力量。云服務(wù)器作為一種處理能力可彈性收縮的計(jì)算服務(wù)[1]，與用戶終端之間進(jìn)行的音視頻、圖像以及系統(tǒng)鏡像等數(shù)據(jù)的交互量呈倍數(shù)增長(zhǎng)，當(dāng)云服務(wù)器上海量數(shù)據(jù)的傳輸超過(guò)網(wǎng)絡(luò)負(fù)荷時(shí)，傳輸速度必將成為大數(shù)據(jù)技術(shù)發(fā)展的瓶頸。數(shù)據(jù)交互過(guò)程中消耗大量網(wǎng)絡(luò)帶寬，降低吞吐量的同時(shí)，影響了更新效率和用戶體驗(yàn)。

本文提出一種基于海思Hi3716C的嵌入式云分支服務(wù)器的數(shù)據(jù)快速更新方法，該方案充分利用UDP傳輸協(xié)議報(bào)頭格式簡(jiǎn)單、數(shù)據(jù)傳輸速度快的優(yōu)勢(shì)[2]，增加了數(shù)據(jù)報(bào)丟包重傳和分組確認(rèn)來(lái)彌補(bǔ)UDP傳輸過(guò)程中數(shù)據(jù)包丟失嚴(yán)重的缺陷，同時(shí)根據(jù)數(shù)據(jù)更新需求設(shè)計(jì)了應(yīng)用層協(xié)議、分離請(qǐng)求和更新端口實(shí)現(xiàn)多線程更新任務(wù)。在保證了傳輸可靠性的同時(shí)，實(shí)現(xiàn)了快速更新數(shù)據(jù)的目的。

1 系統(tǒng)結(jié)構(gòu)

數(shù)據(jù)更新系統(tǒng)中架設(shè)的云分支服務(wù)器又稱為云節(jié)點(diǎn)服務(wù)器，應(yīng)用在商場(chǎng)、餐廳、酒店、公交、高鐵、旅游區(qū)、社區(qū)、農(nóng)村等場(chǎng)所。該服務(wù)器可實(shí)現(xiàn)區(qū)域WiFi覆蓋[3]、視頻點(diǎn)播和直播、定制化服務(wù)、在線商品推廣和后臺(tái)管理等功能，同時(shí)保存了包括用戶數(shù)據(jù)、服務(wù)信息、應(yīng)用軟件和媒體文件等在內(nèi)的各種資源。因此，基于云分支服務(wù)器，設(shè)計(jì)合理的數(shù)據(jù)更新系統(tǒng)完成數(shù)據(jù)交換對(duì)該設(shè)備在實(shí)際場(chǎng)景中的應(yīng)用至關(guān)重要。

本文所設(shè)計(jì)的數(shù)據(jù)更新系統(tǒng)共分為3部分，控制端為云中心服務(wù)器，中轉(zhuǎn)節(jié)點(diǎn)和終端均為嵌入式云分支服務(wù)器，其結(jié)構(gòu)如圖1所示。

圖1 數(shù)據(jù)更新系統(tǒng)結(jié)構(gòu)圖

云中心服務(wù)器制定分配策略，將數(shù)據(jù)資源配置到不同更新服務(wù)器，并向終端的嵌入式分支服務(wù)器發(fā)送更新數(shù)據(jù)庫(kù)；更新服務(wù)器根據(jù)調(diào)度策略，將云中心的不同屬性文件下載并存儲(chǔ)在本地磁盤(pán)，然后更新數(shù)據(jù)庫(kù)索引列表；終端分支服務(wù)器接收中心服務(wù)器的更新索引，查找所需要更新的該類型數(shù)據(jù)所在的中轉(zhuǎn)節(jié)點(diǎn)，向該更新服務(wù)器請(qǐng)求資源完成更新。

2 數(shù)據(jù)更新系統(tǒng)設(shè)計(jì)

2.1 硬件設(shè)計(jì)

中轉(zhuǎn)節(jié)點(diǎn)和終端的嵌入式云分支服務(wù)器采用海思Hi3716C芯片，內(nèi)置Cortex A9處理器，雙核CPU，頻率在1.5 GHz，集成2路千兆以太網(wǎng)口和3路USB2.0接口，1路SATA3.0外設(shè)接口用于擴(kuò)展2 Tbyte硬盤(pán)，存儲(chǔ)更新數(shù)據(jù)資源。Hi3716C支持H.264/MPEG-2等多種格式高清視頻編解碼，可滿足終端云分支服務(wù)器的多媒體播放、可視通信等應(yīng)用需求，其硬件結(jié)構(gòu)如圖2所示。

圖2 云分支服務(wù)器硬件結(jié)構(gòu)

服務(wù)器采用經(jīng)過(guò)裁剪的輕量級(jí)Linux操作系統(tǒng)和定制的ext4文件系統(tǒng)，通過(guò)移植Apache，PHP和SQLite搭建Web服務(wù)器。B/S架構(gòu)的組件便于用戶通過(guò)網(wǎng)絡(luò)登錄系統(tǒng)。此外經(jīng)過(guò)對(duì)內(nèi)核的開(kāi)發(fā)，增加外圍設(shè)備搭建的云分支服務(wù)器可以支持無(wú)線WiFi上網(wǎng)、視頻直播、RFID數(shù)據(jù)采集等應(yīng)用。

2.2 數(shù)據(jù)更新協(xié)議設(shè)計(jì)

TCP/IP技術(shù)作為控制網(wǎng)絡(luò)的通信手段，實(shí)現(xiàn)一系列遠(yuǎn)程控制功能[4]。傳輸層的TCP協(xié)議面向連接，經(jīng)“三次握手后”發(fā)送數(shù)據(jù)，提供可靠傳輸，但TCP[5]報(bào)頭冗余信息多，擁塞控制機(jī)制使網(wǎng)絡(luò)忙碌時(shí)發(fā)生大量丟包狀況，數(shù)據(jù)傳輸速度變慢，且不支持廣播，也不適合較大的圖像文件傳輸[6]。

UDP協(xié)議面向報(bào)文[7]，無(wú)須提前建立連接，只是在接收到應(yīng)用層數(shù)據(jù)后封裝成數(shù)據(jù)報(bào)并從一臺(tái)主機(jī)發(fā)送到另一臺(tái)主機(jī)，不考慮數(shù)據(jù)報(bào)丟失的狀況，與TCP協(xié)議相比，UDP雖然格式精簡(jiǎn)，傳輸效率高，但不能保證數(shù)據(jù)報(bào)能否達(dá)到，所有可靠性必須由應(yīng)用層提供。

嵌入式云分支服務(wù)器存儲(chǔ)的文件類型復(fù)雜。除了要在廣域網(wǎng)中傳輸鏡像、圖像和文件等數(shù)據(jù)外，還需在局域網(wǎng)內(nèi)以組播方式更新大的音視頻文件。直接使用現(xiàn)有的TCP或UDP協(xié)議均無(wú)法滿足系統(tǒng)傳輸數(shù)據(jù)的需求。基于UDP良好的傳輸特性，本系統(tǒng)所設(shè)計(jì)的協(xié)議結(jié)構(gòu)如圖3所示。

圖3 可靠傳輸協(xié)議結(jié)構(gòu)

傳輸層選用UDP協(xié)議提高傳輸效率，應(yīng)用層增加可靠傳輸機(jī)制，彌補(bǔ)數(shù)據(jù)傳輸過(guò)程中的丟包率大的缺陷，可靠傳輸機(jī)制和應(yīng)用層協(xié)議共同構(gòu)成數(shù)據(jù)更新的上層應(yīng)用。其中，可靠數(shù)據(jù)傳輸?shù)膶?shí)現(xiàn)主要包括對(duì)數(shù)據(jù)報(bào)進(jìn)行超時(shí)重傳、分組確認(rèn)和數(shù)據(jù)校驗(yàn)等處理過(guò)程。

2.3 數(shù)據(jù)報(bào)格式設(shè)計(jì)

原始數(shù)據(jù)送入?yún)f(xié)議棧逐級(jí)封裝，然后才能通過(guò)以太網(wǎng)傳輸[7]。應(yīng)用層更新協(xié)議設(shè)計(jì)的報(bào)文由傳輸信息和數(shù)據(jù)信息兩部分構(gòu)成，其格式如圖4所示。

圖4 應(yīng)用層報(bào)文格式

傳輸信息指定源、目的IP地址以及端口號(hào)，并預(yù)留傳輸層協(xié)議類型，在進(jìn)行不同數(shù)據(jù)更新時(shí)靈活選用傳輸協(xié)議。數(shù)據(jù)信息指定更新數(shù)據(jù)序列號(hào)、數(shù)據(jù)報(bào)總數(shù)、數(shù)據(jù)報(bào)大小、更新時(shí)間和數(shù)據(jù)校驗(yàn)用于控制數(shù)據(jù)分包、排序、重傳和校驗(yàn)，指定文件名稱以及存儲(chǔ)路徑是為上層更新應(yīng)用提供接口。

更新數(shù)據(jù)時(shí)，上層應(yīng)用將數(shù)據(jù)和傳輸路徑信息交付于數(shù)據(jù)更新協(xié)議，協(xié)議自動(dòng)將報(bào)頭和數(shù)據(jù)封裝成圖4所示格式的報(bào)文交付傳輸層完成數(shù)據(jù)傳輸。同時(shí)接收端以對(duì)等的方式解析報(bào)文，獲取傳輸信息。

3 數(shù)據(jù)更新系統(tǒng)實(shí)現(xiàn)

3.1 多線程實(shí)現(xiàn)

中心服務(wù)器向更新服務(wù)器發(fā)送數(shù)據(jù)應(yīng)用多線程技術(shù)。主線程Pmain用于監(jiān)聽(tīng)固定端口port_main，等待接收分支服務(wù)器bi(i=1，2，…，n)請(qǐng)求更新的數(shù)據(jù)報(bào)，一旦接收到數(shù)據(jù)報(bào)便為bi隨機(jī)分配更新端口port_i，而后繼續(xù)循環(huán)監(jiān)聽(tīng)。輔助線程Psub_i將新分配的端口port_i綁定在Socket上，建立傳輸通路，向分支服務(wù)器bi發(fā)送更新數(shù)據(jù)，更新示意圖如圖5所示。

圖5 多線程更新

主線程和輔助線程之間采用消息傳遞機(jī)制和緩沖狀態(tài)管理機(jī)制[8]。分支服務(wù)器請(qǐng)求增多時(shí)，主線程循環(huán)接收更新請(qǐng)求，成功后鎖定數(shù)據(jù)緩沖區(qū)并獲取數(shù)據(jù)報(bào)信息，然后為需要更新的分支服務(wù)器bi分配端口，進(jìn)入輔助數(shù)據(jù)更新線程。輔助線程運(yùn)行后，通過(guò)解析數(shù)據(jù)報(bào)，獲取得到分支服務(wù)器基本信息，向分支bi發(fā)送響應(yīng)數(shù)據(jù)報(bào)，將新的更新端口和IP地址等信息打包發(fā)送到分支服務(wù)器，等待再次收到回復(fù)數(shù)據(jù)報(bào)后開(kāi)始傳輸數(shù)據(jù)。軟件運(yùn)行流程如圖6所示。

圖6 多線程處理程序圖

3.2 數(shù)據(jù)分組發(fā)送過(guò)程實(shí)現(xiàn)

利用UDP協(xié)議進(jìn)行可靠傳輸時(shí)，要對(duì)大的文件分包處理。應(yīng)用層將網(wǎng)頁(yè)端傳來(lái)的數(shù)據(jù)所在路徑和文件名寫(xiě)入對(duì)應(yīng)數(shù)據(jù)格式中，并通過(guò)調(diào)用函數(shù)計(jì)算得到數(shù)據(jù)報(bào)總長(zhǎng)度，判斷更新文件是否需要分包。如果分包，則計(jì)算總的分包數(shù)量，以及當(dāng)前分包的大小；否則設(shè)置分包數(shù)量為1，當(dāng)前分包大小為總長(zhǎng)度，并將此部分參數(shù)寫(xiě)入結(jié)構(gòu)體。數(shù)據(jù)報(bào)具體分包流程如圖7所示。

圖7 數(shù)據(jù)報(bào)分包流程圖

分解后，數(shù)據(jù)報(bào)頭部增加控制信息，打包發(fā)送到終端進(jìn)行接收確認(rèn)和請(qǐng)求重傳。通過(guò)設(shè)計(jì)的數(shù)據(jù)包格式定義的結(jié)構(gòu)體如下所示：

typedef struct data_info_s{

u16 Flag， Type， Order；

u32 DataCk， PacketSize， PacketSum， PacketNum；

char Time[N]， FileName[N]， SendDir[N]， RecvDir[N]；

}DataInfo_S；

其中，PacketSize為本數(shù)據(jù)報(bào)的大小，除最后一個(gè)，其他數(shù)據(jù)報(bào)均為固定值。PacketNum為更新數(shù)據(jù)序列號(hào)，定義為無(wú)符號(hào)整型，記錄云分支服務(wù)器更新數(shù)據(jù)報(bào)的序號(hào)，其范圍為0～65 535；PacketSum為總共分出的數(shù)據(jù)報(bào)數(shù)目，DataCk是對(duì)數(shù)據(jù)進(jìn)行CRC32校驗(yàn)后的值，此參數(shù)用來(lái)對(duì)數(shù)據(jù)進(jìn)行差錯(cuò)控制。

3.3 數(shù)據(jù)超時(shí)重傳過(guò)程實(shí)現(xiàn)

打包發(fā)送后更新服務(wù)器等待分支服務(wù)器返回信息，并啟動(dòng)時(shí)鐘判斷返回信息是否超時(shí)。如果超時(shí)，則重新發(fā)送上個(gè)數(shù)據(jù)報(bào)，當(dāng)超時(shí)次數(shù)多于給定值，則返回“連接錯(cuò)誤”顯示在網(wǎng)頁(yè)端。如果在限制時(shí)間內(nèi)收到回復(fù)信息，則判斷回復(fù)信息的內(nèi)容，如果為重發(fā)請(qǐng)求，則重新發(fā)送，如果為數(shù)據(jù)錯(cuò)誤，則返回“數(shù)據(jù)錯(cuò)誤”顯示在網(wǎng)頁(yè)端。如果不需重發(fā)，說(shuō)明數(shù)據(jù)正確，判斷全部數(shù)據(jù)是否已經(jīng)發(fā)送完全，若未發(fā)送完全，則發(fā)送下一個(gè)數(shù)據(jù)包；若已完全發(fā)送，則返回“發(fā)送成功”并返回信息給網(wǎng)頁(yè)端。數(shù)據(jù)報(bào)超時(shí)重發(fā)如圖8所示。

圖8 數(shù)據(jù)報(bào)超時(shí)重發(fā)流程圖

云分支服務(wù)器終端接收到數(shù)據(jù)報(bào)后，首先將所有數(shù)據(jù)進(jìn)行CRC校驗(yàn)，并與傳輸報(bào)文中的CRC值進(jìn)行比較，如果校驗(yàn)值相同則處理接收數(shù)據(jù)，返回處理結(jié)果，否則直接丟棄請(qǐng)求重發(fā)。分包重傳、超時(shí)重發(fā)和CRC校驗(yàn)使得采用UDP更新數(shù)據(jù)快速高效且傳輸可靠。

3.4 數(shù)據(jù)更新網(wǎng)頁(yè)實(shí)現(xiàn)

通過(guò)網(wǎng)頁(yè)選取更新服務(wù)器，后臺(tái)自動(dòng)填充更新服務(wù)器信息。發(fā)送更新數(shù)據(jù)時(shí)選擇分支服務(wù)器傳輸路徑和所要發(fā)送的文件，點(diǎn)擊發(fā)送后，后臺(tái)調(diào)用發(fā)送程序在固定路徑下自動(dòng)生成json格式文件，文件內(nèi)容如下所示：

{

"ip_port"： { "src_ip"："更新服務(wù)器IP地址"， "src_port"：端口號(hào)

}，

…… //傳輸數(shù)據(jù)類型信息

"file_data"：{ "filename"："TCP-IP.gif"， "send_dir"："文件所在路徑"， "recv_dir"："分支服務(wù)器接收文件后存放路徑"

}，

…… //其他更新文件信息

"timeout"：{ "seconds"：8， // 超時(shí)時(shí)間 "microseconds"：0

}

}

生成的文件中給出更新服務(wù)器IP地址、端口信息和更新的各文件的名稱、路徑信息，以及超時(shí)重傳時(shí)間等。分支服務(wù)器請(qǐng)求更新時(shí)，獲取此列表，經(jīng)過(guò)分析后觸發(fā)更新程序即可完成自動(dòng)更新。

4 系統(tǒng)測(cè)試

登錄到中心服務(wù)器的數(shù)據(jù)更新界面，選擇傳輸?shù)臄?shù)據(jù)文件和將要存儲(chǔ)的位置，來(lái)生成更新數(shù)據(jù)庫(kù)和json文件，網(wǎng)頁(yè)界面如圖9所示。

圖9 數(shù)據(jù)更新界面(截圖)

測(cè)試過(guò)程中設(shè)定分包大小64 bit，自動(dòng)重發(fā)間隔1 s，超時(shí)重傳3次。在網(wǎng)絡(luò)帶寬為10 Mbit/s，傳輸文件大小為10 Mbyte情況下對(duì)UDP單線程、改進(jìn)UDP單線程和改進(jìn)UDP多線程丟包率的測(cè)試結(jié)果如圖10所示。

圖10 丟包率測(cè)試結(jié)果

由圖可以看出，利用無(wú)控制的UDP協(xié)議更新數(shù)據(jù)時(shí)丟包率大，云分支服務(wù)器數(shù)量越多，數(shù)據(jù)包丟失越嚴(yán)重，當(dāng)分支服務(wù)器達(dá)到100個(gè)時(shí)丟包率接近7%。采用改進(jìn)的UDP協(xié)議更新數(shù)據(jù)，丟包率明顯下降，整體維持在1%左右，改善效果明顯。

就多線程機(jī)制而言，云分支服務(wù)器較少時(shí)，丟包率穩(wěn)定在較低水平，隨著服務(wù)器數(shù)量增多，多線程傳輸機(jī)制下的更新系統(tǒng)比單線程傳輸丟包率小，系統(tǒng)更穩(wěn)定。

相同條件下對(duì)傳輸時(shí)間進(jìn)行50次測(cè)試后結(jié)果如表1所示。

表1 不同文件下傳輸時(shí)間測(cè)試表

由表中數(shù)據(jù)可以看出，文件較小時(shí)，通用TCP更新和本系統(tǒng)時(shí)間差不大，但傳輸文件較大時(shí)，本系統(tǒng)所采用的UDP傳輸時(shí)間更短，其中平均傳輸時(shí)間比為1.230，比TCP更新系統(tǒng)速度提高了18.21%。可見(jiàn)本系統(tǒng)傳輸效率更高，優(yōu)勢(shì)更明顯。

5 結(jié)語(yǔ)

針對(duì)云分支服務(wù)器實(shí)際需求，基于云分支服務(wù)器的數(shù)據(jù)更新系統(tǒng)能同時(shí)更新多個(gè)云分支服務(wù)器的不同類型數(shù)據(jù)。在大文件傳輸中，改進(jìn)的UDP傳輸協(xié)議保證了數(shù)據(jù)更新的可靠性，更新協(xié)議的多線程傳輸機(jī)制提高了傳輸速度，增強(qiáng)了系統(tǒng)穩(wěn)定性。實(shí)際應(yīng)用結(jié)果表明，本系統(tǒng)數(shù)據(jù)在多任務(wù)數(shù)據(jù)更新上傳輸速度和丟包率的優(yōu)勢(shì)更明顯。

[1]董波，沈青，肖德寶.云計(jì)算集群服務(wù)器系統(tǒng)監(jiān)控方法的研究[J].計(jì)算機(jī)工程與科學(xué)，2012，34(10)：68-72.

[2]REN Y， TANG H， LI J， et al. Performance comparison of UDP-based protocols over fast long distance network[J]. Information technology journal，2009，8(4)：600-604.

[3]段小紅，潘國(guó)峰，楊帆，等.面向智慧社區(qū)的云分支服務(wù)器設(shè)計(jì)與實(shí)現(xiàn)[J].電視技術(shù)，2016， 40(1)：67-71.

[4]董思喬，趙榮建，孫通.基于WiFi構(gòu)建的智能家居控制系統(tǒng)的設(shè)計(jì)[J].電視技術(shù)，2015，39(4)：89-91.

[5]BALAKRISHNAN H，PADMANABHAN V N，SESHAN S，et al. A comparison of mechanisms for improving TCP performance over wireless links[J]. IEEE/ACM transactions on networking，1997，5(6)：756-769.

[6]高毅，張曦煌，王廣翔.基于UDP的多媒體通信的研究與實(shí)現(xiàn)[J].計(jì)算機(jī)工程與應(yīng)用，2012，48(3)：95-98.

[7]STEVENS W R. TCP/IP詳解，卷1：協(xié)議[M]. 范建華，譯.北京：機(jī)械工業(yè)出版社，2011.

[8]張永峰. 基于UDP協(xié)議的航空發(fā)動(dòng)機(jī)振動(dòng)實(shí)時(shí)監(jiān)視系統(tǒng)設(shè)計(jì)[J]. 測(cè)控技術(shù)，2015， 34(3)：55-58.

葉文芳(1992— )，女，碩士生，主研電子與通信工程；

潘國(guó)峰(1968— )，教授，碩士生導(dǎo)師，本文通信作者，主要研究方向?yàn)閼?yīng)用電子技術(shù)、電子信息薄膜、敏感器件研究等；

華 中(1969— ),博士，主要研究方向?yàn)樵朴?jì)算、云服務(wù)器；

齊景愛(ài)(1966— )，高級(jí)工程師，主要研究方向?yàn)閮x器儀表。

責(zé)任編輯：閆雯雯

Design of data update system based on elastic compute branch service

YE Wenfang1，PAN Guofeng1，HUA Zhong2，QI Jing’ai1

(1.SchoolofInformationEngineering，HebeiUniversityofTechnology，Tianjin300401，China；2.TianjinBotroElectronicalTech.Co.，Ltd.，Tianjin300384，China)

Based on the Haisi Hi3716C embedded elastic compute branch service， a method of quick update is proposed. This service uses the Linux operation system and the B/S architecture to set up a platform of update service. In order to fit in the requirement of elastic compute branch service， the mechanism of retransmissing the loss packet and the one of confirming the sent packet is used to improve the UDP protocol， then the multi-threading transport mechanism， which can separate request port from update one， is used to design the update protocol in application layer. This system can update the different type of the data for server branch services at the same time. Especially for some big files，the improved UDP transport protocols can ensure the reliability of update， improve the speed of transmission， and enhance the stability of system. The test result show that for the update system， the transport speed is more faster than tradition way， the loss rate of packet can steady almost 1%，and the fast data transmission can be realized， and it is useful for big data to interact with each other.

elastic compute branch service；data update； UDP protocol； Hi3716C； multi-threaded

葉文芳，潘國(guó)峰，華中，等. 基于云分支服務(wù)器的數(shù)據(jù)更新系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].電視技術(shù)，2016，40(11)：25-29. YE W F，PAN G F，HUA Z，et al. Design of data update system based on elastic compute branch service[J]. Video engineering，2016，40(11)：25-29.

TN949.6

A

10.16280/j.videoe.2016.11.005

國(guó)家科技重大專項(xiàng)課題(2016ZX02301003-004-007)

2016-06-07