OPENDDS_開發者文檔系列_2

目錄

1.2 OpenDDS實作

1.2.1 合規性

1.2.2 DDS規範的擴充

1.2.3 OpenDDS架構

1.2 OpenDDS實作

1.2.1 合規性

    OpenDDS符合OMG DDS和OMG DDSI-RTPS規範。 這種合規的細節如下。

1.2.1.1 DDS合規性DDS規範的第2部分定義了DDS實施的五個合規點：

           1）最低檔案

           2）内容訂閱配置檔案

           3）持久性配置檔案

           4）所有權簡介

           5）對象模型簡介

OpenDDS符合整個DDS規範（包括所有可選配置檔案）。 這包括使用以下注釋實施所有服務品質政策：

           •   僅當使用TCP或IP多點傳播傳輸（配置為可靠）或使用RTPS_UDP傳輸時，才支援RELIABILITY.kind = RELIABLE。

           •   TRANSPORT_PRIORITY未實作為可更改。

1.2.1.2 DDSI-RTPS 合規性

OpenDDS實作符合OMG DDSI-RTPS規範的要求。

OpenDDS RTPS實施說明

      1）編寫者内容過濾-OpenDDS仍然可以丢棄任何相關讀者不需要的樣本（由于内容過濾） - 這是在傳輸層上面完成的

      2）示範QoS的相幹集

      3）定向寫

      4）财産清單

      5）DURABLE資料的原始編寫器資訊 - 這僅用于瞬态和持久耐久性，RTPS規範不支援這些

      6）不生成密鑰哈希，但它們是可選的

      7）nackSuppressionDuration和heartbeatSuppressionDuration。

注意：上述第3和第4項在DDSI-RTPS規範中有所描述。 但是，它們在DDS規範中沒有相應的概念。

1.2.2 DDS規範的擴充

DDS IDL子產品（C ++命名空間，Java包）中的資料類型，接口和常量直接對應于DDS規範，隻有極少數例外：

  •   DDS :: SampleInfo包含以“opendds_reserved”開頭的額外字段

  •   特定于類型的DataReader（包括内置主題的DataReader）具有其他操作read_instance_w_condition（）和take_instance_w_condition（）。

OpenDDS子產品/命名空間/包中的各種類和接口提供了額外的擴充行為。 其中包括Recorder和Replayer等功能以及：

  •    OpenDDS :: DCPS :: TypeSupport添加了DDS規範中未找到的unregister_type（）操作。

  •    OpenDDS :: DCPS :: ALL_STATUS_MASK，NO_STATUS_MASK和DEFAULT_STATUS_MASK是DDS :: Entity，DDS :: StatusCondition和各種create _ *（）操作使用的DDS :: StatusMask類型的有用常量。

1.2.3 OpenDDS架構

本節簡要概述了OpenDDS實作，其功能及其一些元件。 $ DDS_ROOT環境變量應指向OpenDDS分發的基本目錄。 OpenDDS的源代碼可以在$ DDS_ROOT / dds /目錄下找到。 DDS測試可以在$ DDS_ROOT / tests /下找到。

1.2.3.1 設計理念

       OpenDDS實作和API基于對OMG IDL PSM的相當嚴格的解釋。 在幾乎所有情況下，OMG的CORBA IDL C ++語言映射用于定義DDS規範中的IDL如何映射到OpenDDS向用戶端公開的C ++ API中。與OMG IDL PSM的主要偏差是本地接口用于實體和各種其他接口。 這些被定義為DDS規範中的無限制（非本地）接口。 将它們定義為本地接口可以提高性能，減少記憶體使用，簡化用戶端與這些接口的互動，并使用戶端更容易建構自己的實作。

1.2.3.2 可擴充傳輸架構（ETF）

       OpenDDS使用DDS規範定義的IDL接口來初始化和控制服務使用。 資料傳輸是通過OpenDDS特定的傳輸架構完成的，該架構允許服務與各種傳輸協定一起使用。 這被稱為可插拔傳輸，并使OpenDDS的可擴充性成為其體系結構的重要組成部分。 OpenDDS目前支援TCP / IP，UDP / IP，IP多點傳播，sharedmemory和RTPS_UDP傳輸協定，如圖所示。 傳輸通常通過配置檔案指定，并附加到釋出者和訂閱者程序中的各種實體。

        ETF使應用程式開發人員能夠實作自己的定制傳輸。實作自定義傳輸涉及專門化傳輸架構中定義的許多類。 udp傳輸為開發人員在建立自己的實作時可能使用提供了良好的基礎。 有關詳細資訊，請參閱$ DDS_ROOT / dds / DCPS / transport / udp /目錄。

1.2.3.3 使用DCPSInfoRepo進行集中發現

       DDS應用程式必須通過某個中央代理或通過某種分布式方案互相發現。 OpenDDS的一個重要特性是可以将DDS應用程式配置為使用DCPSInfoRepo或RTPS發現執行發現，但使用不同的傳輸類型在資料寫入器和資料讀取器之間進行資料傳輸。

OpenDDS提供了兩種發現選項。

1）資訊庫：一種集中的存儲庫樣式，作為一個單獨的過程運作，允許釋出者和訂閱者集中或互相發現

2）RTPS發現：一種對等的發現方式，利用RTPS協定來通告可用性和位置資訊。 與其他DDS實作的互操作性必須使用對等方法，但在僅限OpenDDS的部署中非常有用。

使用DCPSInfoRepo進行集中發現

        OpenDDS實作了一個名為DCPS資訊存儲庫（DCPSInfoRepo）的獨立服務，以實作集中式發現方法。 它作為CORBA伺服器實作。 當用戶端請求訂閱主題時，DCPS資訊存儲庫定位主題并通知任何現有釋出者新訂戶的位置。隻要在非RTPS配置中使用OpenDDS，就需要運作DCPSInfoRepo程序。 RTPS配置不使用DCPSInfoRepo。 DCPSInfoRepo不參與資料傳播，其作用範圍僅限于OpenDDS應用程式互相發現應用程式開發人員可以自由運作多個資訊庫，每個資訊庫都管理自己的非重疊DCPS域集。還可以操作具有多個存儲庫的域，進而形成分布式虛拟存儲庫。 這稱為存儲庫聯合。 為了使單個存儲庫參與聯合，每個存儲庫在啟動時必須指定其自己的聯合辨別符值（32位數值）。

使用RTPS進行點對點發現

       OpenDDS功能可以滿足需要點對點發現模式的DDS應用。這種發現方式僅通過使用目前版本的RTPS協定來完成。這種簡單的發現形式是通過簡單配置DDS應用程式資料讀取器和在應用程式程序中運作的資料編寫器來完成的，如錯誤：未找到參考源中所示。由于每個參與過程都在OpenDDS中為其資料讀取器和寫入器激活DDSI-RTPS發現機制，是以可以使用預設或配置的網絡端口建立網絡端點，以便DDS參與者可以開始宣傳其資料讀取器和資料寫入器的可用性。在一段時間之後，基于标準尋求彼此的人将找到彼此并基于配置的可插拔傳輸建立連接配接，如可擴充傳輸架構（ETF）中所讨論的。以下是開發人員在開發和部署使用RTPS發現的應用程式時需要考慮的其他實施限制：

1）由于UDP端口配置設定給域ID的方式，域ID應介于0和231之間（包括0和231）。 在每個OpenDDS流程中，每個域中最多支援120個域參與者。

2）主題名稱和類型辨別符限制為256個字元。

3）由于GUID的配置設定方式，OpenDDS的本地多點傳播傳輸不能與RTPS Discovery一起使用（如果嘗試這樣做，将發出警告）。

1.2.3.4 多線程

        OpenDDS建立自己的ORB（當需要一個ORB時）以及運作該ORB的單獨線程。 它還使用自己的線程來處理傳入和傳出的傳輸I / O. 建立單獨的線程以在意外連接配接關閉時清理資源。 您的應用程式可能會通過DCPS的偵聽器機制從這些線程回調。通過DDS釋出樣本時，OpenDDS通常會嘗試使用調用線程将樣本發送給任何連接配接的訂戶。 如果發送調用阻塞，則樣本可以排隊等待在單獨的服務線程上發送，這種行為依賴于QOS政策。訂戶中的所有傳入資料都由服務線程讀取，并排隊等待應用程式讀取。 從服務線程調用DataReader偵聽器。

1.2.3.5 配置

        OpenDDS包括一個基于檔案的配置架構，用于配置調試級别，記憶體配置設定和發現等全局項，以及釋出者和訂閱者的傳輸實作詳細資訊。 配置也可以直接在代碼中實作，但是，建議将配置外部化以便于維護和減少運作時錯誤。