劉喜作,周 晶,梁德清

(海軍大連艦艇學院模擬訓練中心,遼寧大連116018)

1 引 言

當前,運用模擬器在艦艇部隊和院校進行訓練已經(jīng)非常普遍,其中網(wǎng)絡服務組件是模擬訓練系統(tǒng)的重要組成部分,要求有很好的可擴展通信能力[1,2]。這主要表現(xiàn)為以下幾點:數(shù)據(jù)傳輸?shù)膶崟r性和可靠性,支持組播通信方式,支持對等的通信方式(各個網(wǎng)絡單元之間無明顯的客戶端與服務器端之分),支持大數(shù)據(jù)量的數(shù)據(jù)傳輸。

但現(xiàn)在網(wǎng)絡通信普遍采用標準TCP/IP協(xié)議,針對上述要求存在很多不足。如采用TCP進行網(wǎng)絡通信,勢必要建立服務器端和客戶端,增加了通信復雜度。TCP是一種可靠數(shù)據(jù)傳輸協(xié)議,協(xié)議中增加了糾錯和重發(fā)機制,影響了數(shù)據(jù)傳輸?shù)膶崟r性[3]。另外,TCP只支持點對點的傳輸方式,不支持組播通信。而UDP是一種不可靠的網(wǎng)絡通信協(xié)議,無法保證數(shù)據(jù)的可靠傳輸。另外,UDP一次能夠傳輸?shù)淖止?jié)數(shù)是有限的,不能大于65 467 byte[4],也就是說UDP不支持大數(shù)據(jù)量的數(shù)據(jù)傳輸。

在基于UDP協(xié)議用于大數(shù)據(jù)量和可靠性數(shù)據(jù)傳輸方面,很多人也進行了研究。陸海[5]針對多用戶使用UDP協(xié)議實現(xiàn)大數(shù)據(jù)量的可靠傳輸需求,提出了一種簡單實用的分包與重組方法,但沒有對可靠性進行描述。尹然然[6]通過比較分析傳輸層傳輸協(xié)議UDP的不可靠性和TCP的低效率,在UDP協(xié)議基礎上提出并實現(xiàn)了嵌入式設備的可靠數(shù)據(jù)傳輸協(xié)議(RUDP協(xié)議),但文中只描述實現(xiàn)RUDP協(xié)議的一個程序流程。很多文獻沒有分析基于UDP協(xié)議可靠傳輸大數(shù)據(jù)包的性能問題[7,8]。

本文在前人研究的基礎上,利用UDP協(xié)議傳輸速度快、網(wǎng)絡利用效率高的優(yōu)勢,提出AUDP(Augmented UDP)模型。該模型在網(wǎng)絡通信的應用層,通過增加用于可靠傳輸?shù)膮f(xié)議頭、智能重發(fā)機制、大數(shù)據(jù)包智能分包重組機制,實現(xiàn)戰(zhàn)術模擬器中網(wǎng)絡服務組件高效可靠的數(shù)據(jù)傳輸,并通過實驗分析了該模型數(shù)據(jù)傳輸性能。

2 AUDP模型

在戰(zhàn)術模擬器中傳輸?shù)臄?shù)據(jù)大量是動態(tài)目標信息和指令數(shù)據(jù),這些數(shù)據(jù)包大多是幾百字節(jié),即使仿真目標增加到幾百批,字節(jié)數(shù)也不會超過1 Mbyte,為了滿足系統(tǒng)對數(shù)據(jù)實時性和可靠性的要求,本文提出AUDP模型。

如圖1所示,普通UDP/IP協(xié)議中共有4個層次,分別為應用層、傳輸層、網(wǎng)際層和網(wǎng)絡接口層[9]。其中傳輸層、網(wǎng)際層和網(wǎng)絡接口層是運用UDP/IP進行網(wǎng)絡通信必須遵守的協(xié)議,否則,要更改相應的網(wǎng)絡硬件驅動程序。而利用UDP/IP協(xié)議進行可靠性和大數(shù)據(jù)量的網(wǎng)絡數(shù)據(jù)傳輸,只能在協(xié)議的最高層(應用層)添加相應協(xié)議模型,即圖1中的可靠時序協(xié)議層。這個可靠時序協(xié)議層要完成下面幾項功能:繼承UDP通信的高效性和組播通信機制;自動辨識發(fā)送與接收數(shù)據(jù)包的時序性;完成可靠性傳輸?shù)幕貜椭匕l(fā)機制;完成大數(shù)據(jù)量傳輸機制,即對于大于65 467 byte的數(shù)據(jù)包采用自動分包發(fā)送,接收時自動重組機制。

圖1 UDP/IP協(xié)議和AUDP/IP協(xié)議對比圖Fig.1 Relationship between UDP/IP model and AUDP/IP model

3 AUDP的內部機制具體實現(xiàn)

事實上,基于UDP可靠性傳輸包含了網(wǎng)絡通信中很多層,即從網(wǎng)絡接口層到程序的應用層。為了繼承UDP通信的高效性和組播通信機制,我們在通信協(xié)議的最高層(應用層)添加可靠時序協(xié)議層模型。下面將系統(tǒng)闡述可靠時序協(xié)議層模型中的協(xié)議報文頭屬性項的定義、智能數(shù)據(jù)交換傳輸方法和多線程處理機制等,證明本文方法的可行性和有效性。

3.1 報文頭屬性項定義

為了達到上述目的,在發(fā)送每個數(shù)據(jù)包前增加一個報文頭,如表1所示。

表1 報文頭屬性項定義Table 1 The structure of the header

這個報文頭總共25 byte,它與收發(fā)方IP地址和端口號信息一樣,作為UDP協(xié)議頭文件的一部分進行數(shù)據(jù)通信。為了與UDP協(xié)議完全兼容,在報文頭最后增加了一個字節(jié),這個字節(jié)為0x01時,用普通UDP通信,而當這個字節(jié)為0x02時,用改進的UDP通信。

每一個數(shù)據(jù)包通過發(fā)送方IP、接收方IP和數(shù)據(jù)包標志唯一確定,上述報文頭的定義和各項約束提供了基于UDP進行可靠性傳輸?shù)臋C制和實現(xiàn)的基礎。

3.2 智能數(shù)據(jù)交換

圖2為基于UDP進行網(wǎng)絡可靠性傳輸?shù)牧鞒?。為了完成?shù)據(jù)的智能交換和可靠性傳輸,流程中設置了相應的自動分包重組和重發(fā)機制,下面說明其中關鍵步驟和實現(xiàn)方法。

圖2 智能數(shù)據(jù)傳輸交換機制Fig.2 Flowchart of smart data interchange

3.2.1 智能存儲

動態(tài)智能存儲信息和數(shù)據(jù)是上述機制的能夠實現(xiàn)的核心技術,它包括狀態(tài)信息存儲、發(fā)送數(shù)據(jù)存儲和接收數(shù)據(jù)存儲。

狀態(tài)信息存儲是在發(fā)送數(shù)據(jù)時自動存儲發(fā)送時間,在接收數(shù)據(jù)時自動存儲接收數(shù)據(jù)包的標識和序列號。存儲的發(fā)送時間用來判斷此數(shù)據(jù)包在沒有收到確認報文時再次發(fā)送的時機,這個時間間隔根據(jù)實際情況可以動態(tài)選擇。在局域網(wǎng)通信狀況比較好時,可選為100 ms;在廣域網(wǎng)或通信狀況一般時,該時間間隔可以適當加大,并且根據(jù)收到確認報文狀況進行動態(tài)調節(jié)。但如果長時間沒有收到確認報文,默認值為發(fā)送255次,被視為網(wǎng)絡不通,將終止網(wǎng)絡通信。而存儲接收數(shù)據(jù)包的標識和序列號是用來對分包的數(shù)據(jù)進行重組,相同標識而不同序列號的數(shù)據(jù)包視為同一數(shù)據(jù)信息的不同部分。為了高效地對數(shù)據(jù)信息進行重組,我們采用了具有排序能力鏈表進行序列號存儲,按照小于或等于鏈表開頭的序列號視為已被接收。例如現(xiàn)在鏈表中保存有{5,7,8,9,11,12},說明小于或等于序列號5和等于序列號7、8、9、11、12的數(shù)據(jù)包已經(jīng)被接收到了。為確保數(shù)據(jù)可靠傳輸,發(fā)送端增加了重發(fā)機制,接收端可能對同一數(shù)據(jù)包接收到幾次,如果這時接收到序列號為2的數(shù)據(jù)包,根據(jù)上述判斷機制,這個數(shù)據(jù)包將會被自動丟掉,如果接收到序列號為6的數(shù)據(jù)包,將會保存此數(shù)據(jù)包,然后鏈表變?yōu)閧9,11,12},如果整個數(shù)據(jù)全部被接收完,鏈表中只保存此數(shù)據(jù)信息最大的序列號。

發(fā)送數(shù)據(jù)存儲是指在發(fā)送數(shù)據(jù)信息時,根據(jù)數(shù)據(jù)信息的大小自動分包,并且每個數(shù)據(jù)包要加上面定義的協(xié)議報文頭,在發(fā)送此數(shù)據(jù)包的同時把其存儲到發(fā)送數(shù)據(jù)倉庫中。如果沒有收到此數(shù)據(jù)包的接收確認報文,系統(tǒng)會根據(jù)重發(fā)間隔調用發(fā)送數(shù)據(jù)倉庫中該數(shù)據(jù)包進行重發(fā);如果收到此數(shù)據(jù)包接收確認報文,系統(tǒng)會刪除發(fā)送數(shù)據(jù)倉庫中該數(shù)據(jù)包,自動釋放內存。

接收數(shù)據(jù)存儲是指根據(jù)不同的數(shù)據(jù)包標識建立相對應的數(shù)據(jù)包存儲倉庫,然后按照接收數(shù)據(jù)包的序列號進行數(shù)據(jù)保存,同時對各個分數(shù)據(jù)包進行排序,這樣便于數(shù)據(jù)查找和整理,當數(shù)據(jù)信息所有的分數(shù)據(jù)包收到之后,系統(tǒng)會通過線程通知用戶的應用層整個數(shù)據(jù)信息已經(jīng)接收完畢。

3.2.2 接收確認報文

為了傳送報文的可靠性,接收端在接收到報文時要向發(fā)送端反饋接收確認報文。接收確認報文的格式就是上面定義的協(xié)議報文頭,與普通的協(xié)議報文頭相比有3點不同:數(shù)據(jù)包長度為協(xié)議報文頭的長度(25 byte),命令標志的最高位置為1,信息總長度為0。

3.2.3 重發(fā)回饋實現(xiàn)機制

重發(fā)回饋機制為數(shù)據(jù)的可靠性傳輸而設計,我們從接收端來闡明該機制的實現(xiàn)。首先,接收端接收到一個數(shù)據(jù)包,如果該數(shù)據(jù)包從來沒有接收到,該數(shù)據(jù)包將被存儲到接收數(shù)據(jù)倉庫中,同時向發(fā)送端發(fā)送接收確認報文。如果該數(shù)據(jù)包已經(jīng)接收到了,說明發(fā)送端沒有接收到確認報文,此時,接收端重新發(fā)送此數(shù)據(jù)包的接收確認報文,并且丟棄此報文,同時等待下一個數(shù)據(jù)包。

發(fā)送端接收到相應數(shù)據(jù)包的接收確認報文,將從發(fā)送數(shù)據(jù)倉庫中刪除該數(shù)據(jù)包,直到從發(fā)送數(shù)據(jù)倉庫刪除所有數(shù)據(jù)包,表明數(shù)據(jù)信息可靠傳輸完畢。

3.3 多線程處理機制

為了提高數(shù)據(jù)處理和傳送的效率,我們采用了多線程機制,分為3種類型,即發(fā)送服務線程、接收服務線程和數(shù)據(jù)處理線程。

圖3 多線程處理示意圖Fig.3 The multi-threading implementation

發(fā)送服務線程負責對要發(fā)送的數(shù)據(jù)信息根據(jù)大小進行自動分包,對各個數(shù)據(jù)包加上長度為25 byte協(xié)議報文頭,填寫協(xié)議報文頭內容,并將其發(fā)送給接收方,同時把此數(shù)據(jù)包保存到發(fā)送數(shù)據(jù)倉庫中。

接收服務線程負責接收數(shù)據(jù)包、發(fā)送接收確認報文、大數(shù)據(jù)信息報文的排序重組,當接收到數(shù)據(jù)包時,接收服務線程判斷是否為普通數(shù)據(jù)包或分包數(shù)據(jù)包,如果為普通數(shù)據(jù)包,直接交給數(shù)據(jù)處理線程進行處理,但如果是分包數(shù)據(jù)包,將存儲到接收數(shù)據(jù)倉庫進行管理,直到所有分包數(shù)據(jù)接收完畢再交給數(shù)據(jù)處理線程進行處理。每一周期(默認100 ms),接收服務線程還負責檢查發(fā)送數(shù)據(jù)倉庫是否有需要重新發(fā)送的數(shù)據(jù)包,如果有還要對相應的數(shù)據(jù)包進行重新發(fā)送。

數(shù)據(jù)處理線程負責對接收服務線程提供的數(shù)據(jù)包進行數(shù)據(jù)整理,首先去掉數(shù)據(jù)包的協(xié)議報文頭,如果是普通數(shù)據(jù)包,數(shù)據(jù)處理線程將數(shù)據(jù)信息直接交給用戶應用層;如果是分包數(shù)據(jù)包,將按照數(shù)據(jù)協(xié)議頭的序列號進行數(shù)據(jù)拷貝組合,組合完畢后,數(shù)據(jù)處理線程將數(shù)據(jù)信息交給用戶應用層。

4 性能分析

在CPU為 1.0 GHz、內存為 2G、網(wǎng)卡為100 Mbit/s的兩臺計算機上,分別用 AUDP、TCP和UDP方法,通過網(wǎng)線直接連接進行點對點通信測試。為了能夠準確地記錄傳輸數(shù)據(jù)包所用的時間,盡量減少Windows多任務系統(tǒng)本身和系統(tǒng)時鐘記錄引起的誤差,我們把100 Mbit/s的網(wǎng)卡設置為10 Mbit/s全雙工模式,增加傳輸時間,擴大誤差量級;同時設置接收端計算機接收到數(shù)據(jù)要返回到發(fā)送端,這樣使數(shù)據(jù)發(fā)送的時刻和接收的時刻由同一臺計算機記錄,從而避免不同計算機系統(tǒng)時鐘記錄引起的誤差,并且同一數(shù)據(jù)包傳輸100次后取平均值。測試結果如表2所示。

表2 AUDP、TCP和UDP傳輸不同數(shù)據(jù)包所用時間Table 2 Time of interchange via AUDP,TCP and UDP

從測試結果可以看出,在每次傳輸幾萬字節(jié)時,AUDP的效率要比TCP高20%左右,而與UDP相比幾乎差不多;而在3Mbyte以上時,TCP的效率要高。

5 總 結

通過比較可以看到AUDP、TCP和UDP方法之間的差別,并分析出它們各自的優(yōu)勢和缺點。另外,在采用AUDP與TCP進行數(shù)據(jù)傳輸時不存在粘包現(xiàn)象,減少了程序應用層處理數(shù)據(jù)的復雜性。

在戰(zhàn)術模擬器中,傳輸?shù)臄?shù)據(jù)大量是動態(tài)目標信息和指令數(shù)據(jù),大多是幾百字節(jié),即使仿真目標增加到幾百批,字節(jié)數(shù)也不會超過1Mbyte,并且還可以采用分批發(fā)送數(shù)據(jù)包,但系統(tǒng)要求的實時性和可靠性很高,采用AUDP協(xié)議模型,可以很好地滿足要求。

本文只研究了基于UDP點對點的可靠性數(shù)據(jù)傳輸,基于UDP獨有的組播和廣播模式的可靠性傳輸和性能分析是下一步研究的工作。

[1]劉宇.基于戰(zhàn)場仿真的智能指揮控制系統(tǒng)總體設計[J].電訊技術,2011,51(7):38-41.LIU Yu.Overall Design of Intelligent Command and Control System Based on Battlefield Simulation[J].Telecommunication Engineering,2011,51(7):38-41.(in Chinese)

[2]李軍,黃紹君,龔光紅.戰(zhàn)術仿真系統(tǒng)中數(shù)據(jù)交互的實時性研究[J].系統(tǒng)仿真學報,2006,18(增2):381-389.LI Jun,HUANG Shao-jun,GONG Guang-hong.Realtime Research in Data Interchange in Tactic Training Simulation System[J].Journal of System Simulation,2006,18(Suppl.2):381-389.(in Chinese)

[3]Humaira K.SCTP versus TCP for MPI[C]//Proceedings of the 2005 ACM/IEEE Conference on Supercomputing.Washington:ACM/IEEE,2005:30-40.

[4]Jones A,Ohlund J.Network Programming for Windows[M].California:Microsoft Press,2000.

[5]陸海,胡伯涵.UDP協(xié)議中分包與重組方法研究[J].無線電通信技術,2010,36(5):20-22.LU Hai,HU Bo-han.Simple Method of Packet Division and Reassembly on UDP Protocol[J].Radio Communications Technology,2010,36(5):20-22.(in Chinese)

[6]尹然然.基于UDP協(xié)議的可靠性改進協(xié)議[J].電腦知識與技術,2010,16(6):3479-3480.YIN Ran-ran.Reliable Improvement Agreement Based on UDP Agreement[J].Computer Knowledge and Technology,2010,16(6):3479-3480.(in Chinese)

[7]劉詩俊,羅藝.基于WinCap的UDP協(xié)議數(shù)據(jù)重發(fā)方法[J].計算機與數(shù)字工程,2009,37(8):196-199.LIU Shi-jun,LUO Yi.A Method of UDP Data Retransmission Based on WinCap[J].Computer&Digital Engineering,2009,37(8):196-199.(in Chinese)

[8]朱華剛,周祥龍,吳永剛.簡單可靠實時傳送UDP協(xié)議的研究和應用[J].水雷戰(zhàn)與艦船防護,2010,18(3):50-53.ZHU Hua-gang,ZHOU Xiang-long,WU Yong-gang.Research on and Application of simple and Reliable Realtime UDP Protocol[J].Mine Warfare&Ship Self-defence,2010,18(3):50-53.(in Chinese)

[9]謝希仁.計算機網(wǎng)絡教程[M].北京:人民郵電出版社,2002.XIE Xi-ren.Computer Network Guide[M].Beijing:Posts&Telecom Press,2002.(in Chinese)