基于OpenDDS和反射內存卡的信息分發技術

(上海航天電子技術研究所,上海 201109)

0 引言

軍事信息系統中的信息分發網絡作為數字化戰場的中樞，將各種信息按照通信協議規定的格式，實時、快速、自動、保密地進行數據交換，從而實現信息資源共享，最大限度地提高武器平臺的作戰技能[1]。因此，信息分發網絡面臨數據的分布性、準確性、實時性、正確性、協調性、和安全性等挑戰[2]。 OpenDDS是用于分發實時應用系統數據的網絡中間件，簡化了分布式應用程序的開發、部署和維護，應用程序簡單地發布和訂閱數據，發布方和訂閱方無需知道對方地址即可通信。其以數據為中心的發布訂閱模式極大地減少了在網絡上發送數據所需的消耗，為大容量傳輸網絡提供了針對關鍵數據快速且可靈活配置的傳輸方法[2-3]。此外，OpenDDS規范還定義了大量的服務質量(Quality of Service, QoS)策略，使得OpenDDS可以很好地配置和利用系統資源，協調通信質量和執行效率之間的平衡，增加了通信的可靠性[4-5]。目前，許多軍事領域已廣泛采用OpenDDS技術[6]。

OpenDDS是建立在公共對象請求代理體系結構(common object request broker architecture, CORBA)上的應用框架，遠程調用通信是其信息分發的主要技術，在訂閱發布通信中起到重要作用，默認情況下傳輸介質為網卡[7-8]。為了進一步提高信息分發的效率，降低網絡間通訊的時延，屏蔽子網內部頻繁通訊對整個網絡中其他設備的干擾，本文使用光纖反射內存卡作為底層傳輸介質替換網卡，提出一種基于反射內存卡和OpenDDS通信模型的信息分發技術[9-10]。依據CORBA通信的原理，ACE中Reactor監控硬件數據到和多路分離方法，以及反射內存卡應用函數實現相應功能，將本通過DIOP完成的通信使用反射內存實現，設計了OpenDDS下基于反射內存卡的信息分發網絡。

1 系統結構及原理

1.1 OpenDDS

OpenDDS采用以數據為中心的發布訂閱機制，其通信網絡由一個或者多個數據域組成。每個域包含一套域參與者(發布者和訂閱者)，參與者為網絡中分布式通信節點，節點間使用OpenDDS通信。完整的OpenDDS網絡域包括域參與者和主題，域參與者又可分為數據寫入者、發布者、訂閱者、數據讀取者。OpenDDS中各分布式節點身份可以是發布者、訂閱者或兩者兼有，節點間關系平等，數據域內使用主題標識數據，每個主題有唯一的名稱、數據類型和一套QoS策略。發布者發布主題和數據，訂閱者根據自己需要的主題訂閱數據。OpenDDS網絡發現模型為集中式發現模型，網絡通信節點中除了域參與者，還需要一個DCPSInfpRepo (信息倉庫)節點提供發現服務，允許發布者和訂閱者通過DCPSInfpRepo根據主題發現彼此。OpenDDS模型提供匿名、對上透明、多對多的通信，通信時隨時可有新的節點注冊入全局數據空間發布/訂閱信息，或隨時退出該網絡而不影響其余各節點，解決了因網絡結構動態變化需要重構整個通信系統的問題，增強了通信組網的靈活性[2-3,11]。

OpenDDS節點框架如圖1所示，最上層為應用程序，底層為操作系統和通信介質，OpenDDS作為網絡中間件構建在ACE環境和CORBA模型上。其中CORBA使用遠程調用完成了分布式通信的功能，ACE完成了操作系統的適配、包裝，為CORBA通信提供了框架和模式。本文使用反射內存卡替換遠程分布式通信中使用的底層硬件，是在CORBA中間件的基礎上實現的。

圖1 OpenDDS 節點框架圖

1.2 OpenDDS網絡通信

集中式發現的OpenDDS網絡通信分為分布式遠程調用通信和本地通信。信息倉庫(DCPSInfpRepo)節點提供發現服務，允許發布者和訂閱者通過DCPSInfpRepo根據主題發現彼此.DCPSInfpRepo與發布者和訂閱者之間采用遠程調用通信。發布者和訂閱者相互發現后，發布者直接向訂閱者發送數據，使用本地通信。如圖2所示。

圖2 OpenDDS通信模型

遠程調用通信節點使用的Discovery模塊包含CORBA中間件，采用基于UDP的DIOP協議，CORBA的核心是ORB (對象請求代理)，通過ORB實現了客戶端和服務對象的完全分開，客戶端不需要了解服務對象的實現過程和具體位置，就可以使用服務對象。本文主要研究OpenDDS基于CORBA的遠程通信。

1.3 CORBA通信

CORBA為可移植的、面向對象的分布式計算應用程序解決了遠程對象之間的互操作問題。CORBA基于客戶端/服務器模型，在OpenDDS框架中，DCPSInfpRepo作為CORBA服務器，發布者和訂閱者為客戶端。CORBA核心是對象請求代理(Object Request Broker, ORB)，通過ORB實現了客戶端和服務對象的完全分開，客戶端不需要了解服務對象的實現過程和具體位置，就可以使用服務對象。CORBA通信原理如圖3所示。

圖3 CORBA 通信原理圖

CORBA的基本工作方式如下：

1)客戶端使用靜態存根(IDL STUBS)或動態調用接口(DII)提出請求，將請求傳遞給ORB內核。

2)客戶端ORB內核通過網絡傳送到與服務器應用程序相連的服務器ORB內核。

3)服務器ORB內核將請求分配給對象適配器(Object ADAPTER)，產生目標內核。

4)服務器ORB內核將請求分配給目標對象的伺服程序。

5)伺服程序執行客戶機請求后，將結果返回。

客戶端和服務器端的ORB必須協同起來完成工作。ORB間通信協議為通用對象請求代理間協議(General Inter-ORB Protocol, GIOP)，存在于ORB內核中，結合不同的通信硬件，GIOP可以具體化為很多協議，基于UDP數據報的傳輸協議是DIOP。DIOP協議框架主要由Acceptor，Connector、Connection Handler、Endpoint、Profile、Protocol Factory、Transport類的子類組成。其中Profile是基于CORBA的IOR定義的，封裝了所有創建和解析一個特定協議的IOR所需的全部方法和成員，在ORB啟動服務時，Protocol Factory負責根據給定的可插拔協議在服務器端創建一個Acceptor，監聽客戶端發來的請求，同時為每個客戶端啟動一個Connector。當客戶端涉及對象時，ORB必須獲得相應IOR的profile列表。該profile被選定后, Connector注冊會將一個具體的connector實例與相應的profile類型進行匹配并向ORB發出連接請求。而Acceptor一旦監聽到客戶的連接請求，就將他送給ORB處理。只要連接關系確立，客戶端與服務器端就可以通過可插拔協議進行數據通信[7-9]。DIOP協議的主要部分繼承了7個基類，并加入了自己的特性。

1.4 反射內存卡

反射內存卡類似于共享內存，硬件安裝在不同的計算機主機上，所有節點共享同一片存儲區域，同一時刻允許系統中所有節點同時讀寫共享內存。由于不需要通信協議，在任意一塊反射內存卡被寫入數據后，可以在極短的時間內更新數據，網絡上所有計算機都可以訪問這個新數據[11]，傳輸延遲小，可以實時進行信息傳輸，更能滿足大型通信網絡的數據分發要求。

反射內存卡對于任意節點的數據讀寫沒有硬件限制，在實際使用時需要制定具體的協議監控數據收發，數據的收發監控可以使用查詢或中斷模式：查詢模式需要有監控線程監控數據的讀寫，中斷模式需要使用反射內存卡提供的中斷函數。

1.5 ACE Reactor

ACE Reactor處于OpenDDS中的底層模塊ACE中間件。ACE Reactor類似一種監控程序，提供多路分離和事件分派框架，簡化了事件驅動應用的開發。通過在操作系統事件多路分離接口上進行偵聽事件發生，ACE Reactor觸發對用戶預先登記事件處理器(event handler)對象中方法的回調(callback)。該回調方法由應用開發者實現，其中含有應用程序處理此事件的特定代碼[9-10]。

OpenDDS中使用ACE Reactor進行UDP數據的接收和處理，當ACE Reactor監控到某個Socket上UDP數據到達這類事件時，觸發此Socket對應的DIOP模塊中的事件處理器函數。這樣的模式即查詢模式，由于ACE Reactor作為OpenDDS底層數據通信重要的環節，當傳輸介質由網卡替換成反射內存卡時，也使用ACE Reactor對反射內存卡上的數據進行監控。

2 基于反射內存卡通信的硬件設計

2.1 反射內存卡網絡地址設計

反射內存卡允許系統中所有節點同時讀寫共享內存，在OpenDDS分布式網絡應用中，設計最大有128個通信節點，需要對每個節點的反射內存卡進行地址分配。反射內存卡的地址以反射內存ID標識，反射內存ID由板卡硬件設置。網絡中的節點需要實現ID與UDP協議中的IP地址的對應，這里使用算法：

IP=0xc0a800+ID;

DCPSInfpRepo服務器在網絡中心，設置反射內存ID為129，其他反射內存節點為1～127。由此DCPSInfpRepo服務器和其他發布者/訂閱者對應的IP地址設為192.168.0.129和192.168.0.1～192.168.0.127。

2.2 反射內存卡節點存儲設計

反射內存卡存儲區設計如圖4所示，每塊反射內存卡地址分為2個部分，狀態區和數據區，狀態區記錄每個節點是否可讀寫，數據區記錄每個節點收到的幀內容。由于OpenDDS網絡通信分為分布式遠程調用通信和本地通信，遠程調用通信為DIOP幀，本地通信為DCPS幀。因此每個反射內存卡節點內部還需要針對不同的傳輸幀劃分為2個數據，將節點內部劃分地址可以實現數據在單個節點上的分離。這里實現了socket端口到反射內存卡數據區的映射。

圖4 反射內存卡存儲分配圖

3 基于反射內存卡通信的軟件設計

3.1 配置OpenDDS 的DIOP協議

OpenDDS使用DIOP前要配置DIOP協議，方法如下：

1)DIOP協議代碼被包含在TAO_Strategies庫中，將TAO_Strategies.lib加入到OpenDDS應用鏈接庫中。

2)通過服務配置器動態加載DIOP協議：在DCPSInfpRepo應用路徑下創建svc.conf文件，輸入動態加載DIOP協議指令：

dynamic DIOP_Factory Service_Object*

TAO_Strategies:_make_TAO_DIOP_Protocol_Factory () ""

Dynamic Advanced_Resource_Factory Service_Object*

TAO_Strategies:_make_TAO_Advanced_Resource_Factory ()

"-ORBProtocolFactory DIOP_Factory"

3)修改發布者訂閱者應用程序的配置文件dds_udp_conf.ini，將其中的DCPSInfoRepo=corbaloc::192.168.0.129:12345/DCPSInfoRepo

改成DCPSInfoRepo=corbaloc:diop:192.168.0.129:12345/DCPSInfoRepo

4)由于服務器和客戶端都需要創建TAO_DIOP_Acceptor,在運行應用程序時，服務器端和客戶端需要聲明DIOP端點,方法是在命令行數輸入-ORBListenEndpoints diop://主機號:端口號。

至此，配置DIOP協議配置完畢。

3.2 DIOP客戶端注冊

發布者和訂閱者作為客戶端與DCPSInfpRepo服務器端DIOP通信圖如圖5所示。

圖5 發布者/訂閱者與DCPSInfpRepo服務器DIOP通信圖

DIOP協議中，客戶端DIOP_Connector和DIOP_Acceptor創建的DIOP_Connection_Handler和TAO_DIOP_Transport負責與服務器端實現通信，為保證可以正確收到服務器發送的數據，因此需要在TAO_DIOP_Transport中將DIOP_Connection_Handler注冊到反應器上，使得反應器可以監控handler句柄上是否有數據到來。具體操作為在TAO_DIOP_Transport::register_handler函數中加入代碼:

ACE_Reactor * const r = this->orb_core_->reactor ();

if(r==this->event_handler_i()->reactor ()){

return 0;

}

this->ws_->is_registered (true);

return r->register_handler (this->event_handler_i (),

ACE_Event_Handler::READ_MASK);

3.3 反射內存卡通信設計

在OpenDDS的DIOP上實現反射內存卡的數據傳輸，需要解決反射內存卡數據監控問題，這里的數據監控使用程序查詢模式，通過ACE Reator觸發接收回調函數接收數據。圖5描述了在DIOP中使用反射內存卡作為通信介質的實現方法。

如圖6所示，在服務器端DIOP_Acceptor類中創建反射內存卡監控線程函數，用于監控數據是否已經寫入反射內存，監控到反射內存有數據寫完成時通過socket向本機發送可讀的1字節數據，ACE Reactor監視到事先注冊在其中的socket有數據到來，進而能夠觸發到事先注冊在Reactor中注冊的事件處理函數接收數據。反射內存卡監控函數作為一個單獨的線程創建位置較為重要，既要滿足用于監控網卡數據的socket已經建立并完成監聽端口綁定的初始化之后，又要滿足發送端發送第一幀數據之前，以確保接收端能及時準確地監控到發送端寫入反射內存卡的所有數據。這里監控線程函數的創建位置是DIOP_Acceptor.cpp的open_i函數中。

圖6 OpenDDS 反射內存卡替換原理圖

在觸發接收函數后，在接收數據函數內部從反射內存卡對應地址讀出發布端寫入的數據。由此，基于DIOP的反射內存卡數據傳輸，客戶端向反射內存寫數據，服務器端從反射內存讀數據的單詞流程得以實現。服務器端向客戶端傳輸數據流程與此類似。

3.4 反射內存卡數據同步

由于發送和接收方是2個不同的進程，而操作反射內存卡的同一塊地址范圍可能會出現接收端還未將前一次數據取走，發送端已將下一幀數據寫入的丟幀問題。為解決數據在反射內存卡中數據共享時的同步問題，程序中創建讀寫標志位，即設置兩個標志：

f1:寫入標志位，置位時表示發布端已將完整一幀數據寫入反射內存卡對應地址。

f2：讀取標志位，置位時表示訂閱端已將數據從反射內存卡對應地址讀走，此時可寫。

標志位配合反射內存讀寫的流程如圖7所示。

圖7 反射內存卡讀寫流程圖

1)TAO_DIOP_Transport::send依據讀標志f2是否置位，決定是否將將要發布的數據寫入反射內存卡，寫入后清除讀標志f2,置位寫標志f1。

2)線程函數ThreadProc依據寫標志f1是否置位，決定是否向自己進程的發送1個字節通知數據以便觸發ACE reactor，并清除寫標志f1。

3)TAO_DIOP_Transport:recv首先通過this->connection_handler_->peer ().recv()接收由線程函數發來的一字節通知數據，從反射內存卡取出訂閱的數據，并置位讀標志f2。

4 實驗結果與分析

實驗驗證使用3臺計算機分別作為DCPSInfoRepo，發布者和訂閱者，運行DCPSInfoRepo服務器程序如圖8，命令行輸入:

DCPSInfoRepo -ORBListenEndpoints diop://192.168.0.129:12345

圖8 DCPSInfoRepo服務器運行示意圖

運行發布者程序，命令行輸入：

./subscriber -ORBListenEndpoints diop://192.168.0.1:10000 -DCPSConfigFile dds_udp_conf.ini

運行訂閱者程序，命令行輸入：

./publisher -ORBListenEndpoints diop://192.168.0.4:10001 -DCPSConfigFile dds_udp_conf.ini

發布者發送數據，訂閱者可以順利接收到數據，如圖9和圖10所示。

圖9 發布者發布數據

圖10 訂閱者接收數據

實驗結果證明，基于反射內存卡和OpenDDS的通信模型能夠順利實現OpenDDS發布訂閱的過程，數據可以正確分發。

5 結束語

以數據為中心的OpenDDS增加了信息分發系統通信的靈活性。反射內存卡作為網絡的底層硬件允許系統中所有節點同時讀取共享的內存數據，其無需通信協議，減少了網絡中不必要的數據，提高了數據的傳輸效率，是一種非常適合實時信息網絡的底層硬件。基于OpenDDS的分層架構，采用修改DIOP協議的方法，使遠程調用數據通過反射內存卡傳輸，實現了基于OpenDDS和反射內存卡的信息分發系統。將反射內存卡和發布/訂閱模式結合設計的信息分發網絡，更好地滿足軍事領域中信息分發系統實時性、可靠性的要求。