涂 平 ，朱曉鈴 ，2，滿 旺 ，2

(1.福州大學 福建省空間信息工程研究中心，福建 福州 350002；2.廈門理工學院 空間信息科學與工程系，福建 廈門 361024)

隨著“數(shù)字福建”工程建設與政府信息整合、資源的交換與共享的深入，各個機構(gòu)內(nèi)部產(chǎn)生的大量業(yè)務數(shù)據(jù)信息、基礎(chǔ)數(shù)據(jù)庫信息，以及各種圖像文件等需要及時快速地從機構(gòu)的服務器或終端匯總到數(shù)字福建數(shù)據(jù)中心，以便在各個機構(gòu)的服務器或終端之間互傳。由于傳輸?shù)臄?shù)據(jù)量巨大，傳輸過程中經(jīng)過的服務器及網(wǎng)絡環(huán)節(jié)眾多，因此，對數(shù)據(jù)傳輸?shù)男?、可靠性、安全等方面提出了諸多要求，同時，現(xiàn)有應用需求對數(shù)據(jù)資源傳輸?shù)囊笠苍絹碓礁遊1]。而傳統(tǒng)的文件傳輸工具已經(jīng)無法勝任機構(gòu)級應用環(huán)境的需求[2-3]。為此，快速、安全、穩(wěn)定地實現(xiàn)大數(shù)據(jù)量網(wǎng)絡傳輸技術(shù)的研究是一個亟待解決的問題。

本文依據(jù)數(shù)據(jù)傳輸端之間所處的網(wǎng)絡環(huán)境，提出了大數(shù)據(jù)量傳輸系統(tǒng)架構(gòu)，分別研究實現(xiàn)了即時數(shù)據(jù)傳輸與離線數(shù)據(jù)傳輸，并進行了性能測試。

1 數(shù)據(jù)傳輸系統(tǒng)架構(gòu)

依據(jù)開放互聯(lián)參考模型，本文設計的大數(shù)據(jù)量數(shù)據(jù)傳輸系統(tǒng)架構(gòu)，主要包括網(wǎng)絡監(jiān)測模塊、數(shù)據(jù)傳輸模塊、數(shù)據(jù)管理模塊、數(shù)據(jù)處理模塊，其系統(tǒng)架構(gòu)如圖1所示。

(1)數(shù)據(jù)處理模塊。負責發(fā)送、接收數(shù)據(jù)，根據(jù)數(shù)據(jù)的處理規(guī)則，對數(shù)據(jù)進行一系列加密、解密、壓縮、解壓縮、指定編碼、解碼格式等操作，并將其封裝成若干UDP數(shù)據(jù)包(反之將若干UDP數(shù)據(jù)包組合)的內(nèi)部模塊。

(2)數(shù)據(jù)管理模塊。負責對經(jīng)過數(shù)據(jù)處理后的待發(fā)送數(shù)據(jù)包或剛接收到的數(shù)據(jù)包進行統(tǒng)一管理分配，負責數(shù)據(jù)的緩存管理、并發(fā)管理以及完整性管理。

(3)數(shù)據(jù)傳輸模塊。負責數(shù)據(jù)傳輸路徑的管理，通過對網(wǎng)絡鏈路環(huán)境的判斷來決定傳輸路徑(直發(fā)、打通直發(fā)、通過服務器轉(zhuǎn)發(fā))，并實現(xiàn)數(shù)據(jù)包準確的收、發(fā)過程。

(4)網(wǎng)絡監(jiān)測模塊。負責監(jiān)控本地與服務器連接超時，報告服務器下線通知，處理本地網(wǎng)絡異常及對數(shù)據(jù)傳輸雙方的網(wǎng)絡帶寬進行測試等功能。

2 即時數(shù)據(jù)傳輸

即時數(shù)據(jù)傳輸要求通信雙方均保持在線狀態(tài)，經(jīng)過一次“握手”之后，方能進行數(shù)據(jù)傳輸。若通信雙方“握手”不成功，發(fā)送方會自動將數(shù)據(jù)發(fā)往服務端，由服務端將數(shù)據(jù)轉(zhuǎn)發(fā)給接收方。同時為應對意外斷線的情況發(fā)生，提供了斷線續(xù)傳的功能，即使在傳輸過程中意外中斷，用戶仍可從斷點處重新開始傳輸，大大節(jié)省了時間和帶寬資源。其工作原理如圖2所示。

即時數(shù)據(jù)傳輸實現(xiàn)了SOCKET通信，其中包括P2P隧道穿梭、帶寬測試、在線心跳維護、補充包機制、數(shù)據(jù)加密校驗和多線程組多緩沖區(qū)協(xié)同操作模塊。在線數(shù)據(jù)傳輸?shù)臄?shù)據(jù)分為3種類型：小數(shù)據(jù)塊傳輸、大數(shù)據(jù)塊傳輸和即時性數(shù)據(jù)傳輸。

文字聊天、操作訓令、組織機構(gòu)和UI控制層指令等稱為小數(shù)據(jù)塊傳輸。硬盤文件、數(shù)據(jù)庫大數(shù)據(jù)流等稱為大數(shù)據(jù)流，因為大數(shù)據(jù)流只為一個數(shù)據(jù)流接口進行底層讀取數(shù)據(jù)，例如文件數(shù)據(jù)傳輸，當用戶需要傳輸文件時，只要編輯消息和文件路徑觸發(fā)在線發(fā)送接口就可以完成數(shù)據(jù)傳輸，簡化了上層序列化等操作，直接提升傳輸效率。即時數(shù)據(jù)稱為可丟失數(shù)據(jù)，如音視頻數(shù)據(jù)，因為為了保障通信即時、不延時而被迫丟棄延時數(shù)據(jù)。

3 離線數(shù)據(jù)傳輸

即時數(shù)據(jù)傳輸要求雙方都在線，并且接收方必須確認接收后才能開始傳輸。而在繁忙的工作中，數(shù)據(jù)通信雙方不可能一直保持在線狀態(tài)，為了能保障數(shù)據(jù)通信的及時有效性，特別對離線數(shù)據(jù)傳輸進行了研究。當通信的一方不在線的情況下，數(shù)據(jù)發(fā)起方也可以向?qū)Ψ桨l(fā)送數(shù)據(jù)，該數(shù)據(jù)暫時存放在數(shù)據(jù)服務器中進行中轉(zhuǎn)，當數(shù)據(jù)接收方上線時，將自動從數(shù)據(jù)服務器中獲取緩存的離線數(shù)據(jù)。同時為應對意外斷線的情況發(fā)生，提供了斷線續(xù)傳的功能，即使在傳輸過程中意外中斷，用戶仍可從斷點處重新開始傳輸，大大節(jié)省了時間和帶寬資源。

3.1 數(shù)據(jù)離線上傳

數(shù)據(jù)離線上傳功能包括斷點續(xù)傳、多線程并行發(fā)送離線數(shù)據(jù)、內(nèi)部執(zhí)行信令和接收。使用ATL開發(fā)了離線上傳控件，可以嵌入其他語言的二次開發(fā)，具有可擴展性，其最高速率達3.5 Mb/s(100 M網(wǎng)卡)。離線上傳包含UI控制層、上傳客戶端組件、上傳組件服務器端組件和服務器上傳日志管理中心。離線上傳組件是系統(tǒng)的核心部位，嵌入UI監(jiān)控層和服務器業(yè)務層，只提供特定接口響應或被響應。數(shù)據(jù)上傳工作原理圖如圖3所示。

3.2 數(shù)據(jù)離線下載

數(shù)據(jù)離線下載主要是負責數(shù)據(jù)下載，其工作原理如圖4所示。

該模塊主要包含HTTP下載組件和業(yè)務控制層模塊兩部分。HTTP下載組件是整個離線下載的核心部件，同時它很好地封裝了斷點續(xù)傳、線程負載調(diào)配、轉(zhuǎn)地址等操作而只為外部提供了啟動、暫停和關(guān)閉3種方法和一種事件委托方法及多個配置屬性，通過組件封裝可以很好地降低工程的耦合；且由于HTTP是一個基于請求與響應模式的、無狀態(tài)的、應用層的協(xié)議，?；赥CP的連接方式，HTTP1.1版本中給出一種持續(xù)連接的機制，絕大多數(shù)的Web開發(fā)，都是構(gòu)建在HTTP協(xié)議之上的Web應用以及嵌入其他語言使用。

圖4 數(shù)據(jù)離線下載工作原理圖

3.3 數(shù)據(jù)緩存服務器

數(shù)據(jù)緩存服務器主要有：離線數(shù)據(jù)上傳服務組件、WebServer和服務器管理層模塊。

上傳服務組件主要功能是接收離線數(shù)據(jù)上傳處理，其功能包括數(shù)據(jù)接收、本地保存以及傳輸進度等信息響應。

為了構(gòu)建一個穩(wěn)定而簡易且功能強大的數(shù)據(jù)服務器體系，離線傳輸?shù)南螺d客戶端選擇了HTTP下載組件，但由于HTTP下載是基于Web數(shù)據(jù)的下載，由此服務器必須是基于HTTP協(xié)議的WebServer。因為Web Server在當今IT界有許多成熟、穩(wěn)定且配置簡單的產(chǎn)品。

服務器管理層模塊負責各種業(yè)務邏輯處理，包括用戶信息存儲、下載進度或斷點信息保存，以及上傳組件與WebServer兩個模塊間的調(diào)度和調(diào)配。

4 數(shù)據(jù)傳輸測試結(jié)果

針對以上提出的傳輸模型，在Windows平臺下，基于.NET平臺，分別開發(fā)了相關(guān)控件，并在內(nèi)網(wǎng)與政務網(wǎng)內(nèi)部進行了測試。局域網(wǎng)測試客戶端為WindowsXP操作系統(tǒng)，1 GB內(nèi)存，雙核CPU，10 M網(wǎng)卡；政務網(wǎng)測試客戶端為Windows2003操作系統(tǒng)，768 MB內(nèi)存，普通100 M網(wǎng)卡。各類控件使用說明如表1所示，測試結(jié)果如表2所示。

表1 使用說明

表2 測試結(jié)果

從表2測試結(jié)果可以看出，無論是在內(nèi)網(wǎng)還是政務網(wǎng)，無論是90 MB文件還是190 MB文件，無論是單個還是多個文件，P2P傳輸模式效率都要比HTTP下載控件及離線文件上傳效率高得多；而且數(shù)據(jù)量越大，即時數(shù)據(jù)傳輸方式的優(yōu)勢越明顯。

本文提出了大數(shù)據(jù)量數(shù)據(jù)網(wǎng)絡傳輸架構(gòu)，開發(fā)了相關(guān)傳輸組件，并進行了測試。測試表明，發(fā)送效率最高的為即時數(shù)據(jù)傳輸模式，而且由于內(nèi)部編程都由手工完成，理論上還能有很大的提升空間。下一步將進一步完善服務細節(jié)設計，完善離線數(shù)據(jù)傳輸服務功能。

[1]徐朝暉，錢樸慧.UDP協(xié)議的海量信息快速傳輸解決方案[J].火力與指揮控制，2005，30(1)：46-49.

[2]張忠平，欒建鋒，王昆波.網(wǎng)格環(huán)境下基于P2P的數(shù)據(jù)集成方法[J].計算機工程，2009，35(12)：54-55.

[3]喻占武，鄭勝，李忠民.一種混合式P2P下的大規(guī)模地形數(shù)據(jù)傳輸機制[J].測繪學報，2008，37(2)：243-249.