使用可靠多播與OPENDDS進行數據分發

介紹

也許應用程序設計人員在創建分布式系統時面臨的最關鍵決策之一是如何在感興趣的各方之間交換數據。通常，這涉及選擇一個或多個通信協議并確定向每個端點分派數據的最有效手段。實現較低級別的通信軟件可能是耗時的，昂貴的并且容易出錯。很多時候，經過大量的時間和精力投入后，許多設計師發現最初設計中的最后一刻需求變化或缺陷會浪費在這個關鍵的軟件層上。

中間件解決方案旨在幫助（如果不能解決）這些類型的問題。設計人員可以依賴于給定中間件產品中存在的功能來充當事實上的兼容層，而不是讓每個應用程序實現自定義通信套件。數據分發服務（DDS）規范是對象管理組提出的一種解決方案。如前一篇文章所述，OpenDDS是DDS規范的開源實現，它提供了許多可插拔的傳輸選項，以滿足各種通信需求。結合富有表現力的服務質量（QoS）設施，OpenDDS是那些需要可配置且高效的數據分發方式的項目的理想解決方案，設計人員幾乎沒有風險。

從版本2.1開始，OpenDDS提供了一種新的IP多播傳輸，在有損網絡上具有更高的可靠性和更好的確定性。本文詳細介紹了多播傳輸實現，它在基于IP的網絡上的交互，以及OpenDDS支持的其他基于IP的傳輸的比較分析。

履行

從版本2.1開始，multicast 傳輸提供對IP多播的支持。該 multicast 運輸被設計為舊的ReliableMulticast 和 SimpleMcast 運輸的替代品。與其他OpenDDS傳輸實施不同， multicast 它為基于傳輸配置的盡力而為可靠的傳送提供統一支持。

盡管在同行之間交換數據，但盡力交付會產生最少的開銷，但是它不提供任何交付保證。數據可能由于無響應或無法訪問的對等方丟失或一式兩份收到。

可靠的傳送提供了保證向關聯對等方傳送數據而不會以額外處理和帶寬為代價進行重復。通過兩種主要機制實現可靠的交付：雙向對等握手和對缺失數據的否定確認。這些機制中的每一個都是有限的，以確保確定性行為，并且可配置以確保用戶環境可能的最廣泛的適用性。

通過兩個主要機制實現可靠的交付：

雙向對等握手（SYN / SYN + ACK）
對缺失數據的否定確認（NAK / NAK + ACK）

為了討論可靠對等體之間的交互，有助于將多播組的視圖縮小到兩個特定對等體：主動和被動。該活性對等體是一個關聯的發布側。在被動同行總是訂閱同行。重要的是要記住控制數據在多播組內的所有對等體之間交換; 然而，不感興趣的同伴會丟棄直接向他們發送的有效載荷。

同行握手（SYN / SYN + ACK）

用于確保可靠性的第一種機制是相關對等體之間的雙向握手。握手機制提供了給定對等體等待形成關聯多長時間的確定性約束。此功能還用于防止發布對等方過早發送數據。這種機制詳述如下：
這里寫圖片描述
活動（即發布MULTICAST_SYN 者）對等體通過以超時限制的周期性間隔向被動（即訂戶）對等體發送控制樣本來發起握手，以確保傳送。基于重試次數觀察到指數退避。

在接收到 MULTICAST_SYN 對照樣本后，被動對等體記錄活動對等體的當前傳輸序列值并用MULTICAST_SYNACK 對照樣本進行響應。該序列號建立了一個值，從該值可以在將來識別接收間隙。

如果活動對等體接收到 MULTICAST_SYNACK 控制樣本，則它通知應用程序該關聯已完成。如果 MULTICAST_SYNACK 未收到控件樣本，則會記錄錯誤。

否定確認（NAK / NAK + ACK）

否定確認是確保數據可靠性的主要機制。該機制將檢測數據丟失的責任放在每個訂戶上，這允許發布者盡可能快速有效地分派數據。這種機制詳述如下：
這里寫圖片描述
當每個數據報被傳遞給被動對等體時，傳輸序列值針對識別接收間隙的特殊容器進行評分。通過重置序列低水位標記并記錄錯誤，監視程序定期執行并使最舊的未完成修復請求老化。一旦清除了未完成的請求，監視器就會檢查接收間隙。如果識別出新的（或現有的）接收間隙，則對等體記錄傳輸序列的當前間隔和高水位標記。然后 MULTICAST_NAK ，它將控制樣本發送到缺少數據的活動對等體。被動對等體基于發往同一活動對等體的所有修復請求來執行NAK抑制。如果以前 MULTICAST_NAK 請求已由其他被動對等體發送，被動對等體暫時省略當前間隔的先前請求的范圍。該間隔是隨機的，以防止類似關聯的對等體之間的潛在沖突。

如果活動對等體接收到 MULTICAST_NAK 控制樣本，則檢查其發送緩沖區以查找丟失的數據報。如果數據報不再可用，它會將MULTICAST_NAKACK 控制樣本發送到整個多播組以抑制進一步的修復請求。如果數據報仍然可用，它會將丟失的數據重新發送到整個多播組。

如果被動對等體接收到 MULTICAST_NAKACK 控制樣本，則其行為就像修復請求已經老化一樣，從而抑制了進一步的修復請求并記錄了錯誤。

組態

該 multicast 運輸支持許多配置選項：

在 default_to_ipv6 和 port_offset 選項會影響組播組地址的方式默認選中。如果
default_to_ipv6 設置為 1 （啟用），則使用默認IPv6地址。該 port_offset 選項確定使用的默認端口;此值將添加到傳輸ID以確定實際端口號。默認值分別為 0 （禁用）和 49400 。
該 group_address 選項可用于手動定義要加入的多播組以交換數據。支持IPv4和IPv6地址。與此同時 SimpleTcp，OpenDDS IPv6支持要求在啟用IPv6支持的情況下構建基礎ACE / TAO組件。224.0.0.128: IPv4和 [FF01::80]: IPv6 的默認值。
如果需要可靠的交付，則 reliable可以指定選項。其余配置選項會影響多播傳輸使用的可靠性機制。默認值為 1 （啟用）。
syn_backoff，syn_interval和 syn_timeout 配置選項會影響握手機制。 syn_backoff 是計算重試之間的退避延遲時使用的指數基數。該 syn_interval 選項定義重試握手之前等待的最小毫秒數。該syn_timeout 定義millseconds的最大數量的握手放棄之前等待。默認值分別為 2.0， 250和 30000 （30秒）。
給定的值 syn_backoff 和 syn_interval，可以計算握手嘗試之間的延遲（由界定 syn_timeout）：

delay = syn_interval * syn_backoff ^ <#retries>

例如，如果假定默認配置選項，則握手嘗試之間的延遲將為：0,250,1000,2000,4000,8000和16000毫秒。

nak_depth， nak_interval和 nak_timeout 配置選項影響否定確認機制。 nak_depth 確定傳輸為傳入的修復請求提供服務所保留的最大數據報數。該 nak_interval 配置選項定義毫秒的最小數量的維修請求之間等待。該間隔是隨機的，以防止類似關聯的對等體之間的潛在沖突。修復請求之間的最大延遲限制為最小值的兩倍。該 nak_timeout 配置選項定義的時間放棄之前等待修理請求的最大數量。默認值分別為 32， 500和 30000 （30秒）。

為方便起見，OpenDDS發行版中的以下位置提供了一個示例.ini文件： $DDS_ROOT/dds/DCPS/transport/multicast/multicast.ini-dist

目前，使用傳輸時必須遵守一些限制：

最多，每個唯一的多播組可以僅由一個DDS域使用。
給定 DomainParticipant 對象可能僅為特定多播組附加一個多播傳輸。例如，對于a Publisher 和 Subscriber 從同一DomainParticipant 對象創建的應用程序，應用程序可能不會在傳輸中使用相同的多播組。如果應用程序希望在同一進程中同一組播組上發送和接收樣本，則應用程序必須DomainParticipant 為同一個域創建兩個不同的對象 - 一個用于 Publisher，另一個用于 Subscriber。

與其他傳輸一樣，ACE Service Configurator Framework也啟用了動態配置。一個 svc.conf 文件應該被創建了包含以下內容：

dynamic OpenDDS_DCPS_Multicast_Service Service_Object * OpenDDS_Multicast:_make_MulticastLoader()

通過將以下參數傳遞給應用程序的命令行，在運行時加載傳輸：

-ORBSvcConf svc.conf

或者，可以通過包含dds/DCPS/transport/multicast/Multicast.h 標頭（暗示靜態鏈接）靜態加載傳輸：

#ifdef ACE_AS_STATIC_LIBS
# include <dds/DCPS/transport/multicast/Multicast.h>
#endif

最后，多播傳輸的配置和附加方式與其他傳輸實現類似：

OpenDDS::DCPS::TransportImpl_rch transport_impl =TheTransportFactory->create_transport_impl(OpenDDS::DCPS::DEFAULT_MULTICAST_ID,OpenDDS::DCPS::AUTO_CONFIG);OpenDDS::DCPS::AttachStatus status = transport_impl->attach(...);
if (status != OpenDDS::DCPS::ATTACH_OK) {exit(EXIT_FAILURE);
}

互動

在討論有線協議時，提供協議交互的圖形表示通常很有幫助。如上所述，protcol狀態機使用四種傳輸控制樣本類型：

MULTICAST_SYN
MULTICAST_SYNACK
MULTICAST_NAK
MULTICAST_NAKACK

下面提供這些PDU的示例。這些數據包是使用odds_dissector Wireshark插件從SunOS（SPARC）工作站捕獲的，該插件在OpenDDS 2.1.1版中提供：
這里寫圖片描述
MULTICAST_SYN 控制樣本從活動（即發布者）對等體發送。這些樣本聲明了與特定被動對等體形成關聯的意圖。被動對等體由最后四個八位字節標識（以藍色突出顯示）。此值對應于被動對等方的源ID。

MULTICAST_SYNACK 控制樣本從被動（即用戶）對等體發送。發送這些樣本以確認活動對等體的握手嘗試。收到后，由最后四個八位字節標識的活動對等體（以藍色突出顯示）完成與被動對等體的關聯。此值對應于活動對等方的源ID。
這里寫圖片描述
MULTICAST_NAK 控制樣本從被動對等體發送。當識別出接收間隙時，發送這些樣本。以藍色突出顯示的八位字節表示缺少數據的活動對等體的源ID。以紫色突出顯示的以下四個八位字節表示缺少數據的范圍。前兩個八位字節表示缺失范圍的下限，而后兩個八位字節表示上限。這些值對應于數據報的序列號。
這里寫圖片描述
MULTICAST_NAKACK 控制樣本從活動對等體發送。當無法滿足維修請求時，將發送這些樣本。最后兩個八位字節（以紫色突出顯示）表示可以恢復的第一個數據報的序列號。

對照

構建了一個非正式測試來展示IP多播通信的可擴展性方面。擴展測試（作為OpenDDS-Bench基準測試框架的一部分提供 $DDS_ROOT/performance-tests/Bench）收集用于將樣本傳播到一個或多個端點的延遲度量。使用 multicast 針對udp （UDP / IP）和 SimpleTcp （TCP / IP）傳輸的可靠和盡力而為的傳送模式測試傳輸。下圖表示通過交換式以太網網絡在八個類似配置的主機之間運行擴展測試時收集的結果：
這里寫圖片描述
值得注意的是，不應將這些測試運行中收集的絕對數字用作比較基礎。相反，應該使用每個數據點之間的相對差異。

與單播IP傳輸相比， udp 是唯一一種在multicast 延遲方面表現優于傳輸的傳輸（注意，延遲隨著單播的訂閱端點數量線性增加）。一旦訂閱進程的數量大于2，則調度多播數據因素的一般開銷。這表明在這種特定硬件上仍應考慮單播傳輸的兩個或更少的扇出。需要注意的一點是可靠和盡力交付模式之間的相對差異。可靠性確實會產生少量開銷，但是與基于單播的傳輸相比，所述開銷不會相對于訂戶數量線性增加。

上述結果很好地表明何時應該認為IP多播通信是可行的。鑒于發布者可能具有多個（即多于兩個）訂閱端點的情況，IP多播在分派數據時提供最低延遲。相反，在發布者僅維護一個或兩個訂戶的情況下，IP多播不太可能很好地擴展。

概要

本文詳細介紹了OpenDDS 2.1版中提供的新IP多播傳輸。該 multicast 運輸為那些誰愿意派遣可靠低延遲數據到一個或多個用戶的設計理想的解決方案。雖然IP多播通信在管理可靠性方面存在許多限制因素，但我們已經證明，仍然可以以最小的開銷實現可靠的通信 - 特別是隨著用戶數量的增加。OpenDDS由OCI專業開發和商業支持，OCI是一家提供全方位服務的軟件工程，開源產品和培訓公司。