DDS通信中間件——DCPS規范(下)

本期還是DCPS規范，填上期沒有聊完的QoS的坑。本系列文章將包括以下內容陸續更新：

1.DDS規范概述

2.DCPS規范解讀

3. DDS-XTypes與IDL解讀

4. RTPS規范解讀

5. DDS安全規范解讀

6. DDS-RPC規范解讀

7. DDS-TSN規范解讀

8. DDS-XRCE規范解讀

1. 概述

“數據還可以通過靈活的服務質量 (QoS) 規范進行共享，包括可靠性、系統運行狀況（活躍性）甚至安全性。在真實的系統中，并非所有其他端點都需要本地存儲中的所有數據。DDS很聰明，只發送它需要的內容。如果消息并不總是到達預期目的地，中間件會在需要時實現可靠性。當系統發生變化時，中間件會動態地確定將哪些數據發送到哪里，并智能地將變化通知參與者。如果總數據量很大，DDS會智能過濾并僅發送每個端點真正需要的數據。當需要快速更新時，DDS會發送多播消息來同時更新許多遠程應用程序。隨著數據格式的發展，DDS會跟蹤系統各個部分使用的版本并自動進行轉換。對于安全關鍵型應用程序，DDS控制訪問、強制執行數據流路徑并動態加密數據。”

以上這段話是DDS官網對QoS的說明，第一段中的描述涉及到：可靠性QoS、存活性QoS、基于時間過濾QoS、類型兼容QoS以及安全QoS。這些在后面會詳細說明。

“當您在非常動態、要求嚴格且不可預測的環境中以極高的速度同時指定所有這些內容時，DDS 的真正威力就會顯現出來。”

上面這句話里面的“同時”這個關鍵詞總結了QoS真正能夠發揮重要作用的場景。也就是說當一個大系統里面存在多種數據需要傳輸并且對不同數據的傳輸“需求”不同的場景。QoS是DDS標榜自己區別于其他中間件的重要特征，也是很多總師/設計師在選用DDS技術作為架構的理由，但實際情況是QoS到底在系統中有什么用，并沒有想清楚，我見過的大部分場景中用戶也只能提出來是否需要可靠外加底層通過什么通信協議通信，這種情況下起初因為“QoS”選擇DDS的初衷就沒辦法在系統中體現。

簡單來說，QoS就是DDS配置，類比到socket里面就是set_option，通過set_option可以配置緩沖區大小、阻塞/非阻塞模式，優先級等。QoS提供配置來完成以下幾類功能：

? 通信需求配置：DDS會總結常用的通信需求，并抽象為典型的配置項由用戶來選擇，典型的包括：可靠性、持久化、優先級、延遲預算、截止時間等；

? 數據呈現配置：控制DDS如何把數據呈現給收端，排序、分組、過濾等，包括：所有權/權值、基于時間過濾、樣本順序、數據表現、過期時間等；

? 資源使用配置：DDS可以通過QoS來配置使用的系統資源，典型的包括：歷史數據、資源限制、發端數據周期、收端數據周期；

? 發現階段配置：實體攜帶數據、組攜帶數據、主題攜帶數據、分區、存活性；

分類及其簡單的介紹、配置項參見下面兩張圖，這里只總結DCPS規范中的QoS，在其他規范中擴展的QoS暫時不考慮，例如：DDS安全規范中添加的安全配置、DDS-XTypes規范中添加的數據兼容性配置等。

2.QoS檢查

2.1. 組合

上期我們提到DDS中定義了多種實體：域參與者、發布者、訂閱者、數據讀者、數據寫者、主題，每個實體都可以配置上面列出來的多個QoS配置。具體的對應情況這里就不一一列出，可以參見DCPSV1.4規范的2.2.3章節的表格的Concerns列。

2.2. 有效性和兼容性

DDS對用戶配置的QoS進行幾個方面的檢查，具體的每個QoS的檢查同樣查看上面規范中的表格：

? 有效性：在本地判斷配置的QoS的值是否在允許的范圍內，比如：資源限制中的max_samples必須要大于0；

? 本地兼容性：在本地判斷同一個實體上配置的多個配置項不能互相矛盾，比如：截止時間配置至少1s接收一包，基于時間過濾的配置又配置報文間隔最小是2s，這就是屬于矛盾的配置；

? 匹配兼容性：在自動發現階段后匹配階段檢查，數據寫者與數據讀者端的QoS是否兼容，需要滿足：“提供的服務等級 > 需求的服務等級”，例如：數據寫者配置BEST-EFFORT，表示我提供盡力而為的傳輸服務，數據讀者配置RELIABLE，表示我需要可靠的傳輸服務，這種情況下數據讀者的可靠性配置無法滿足，這就是不兼容的QoS配置。

2.3. QoS影響

這里涉及到QoS如何作用，大概分為兩類：

? 影響DDS實體的狀態，這些狀態可以通過相應的接口獲取，具體可以參考上一篇文章中的 2.2.1.1. 實體狀態章節；

? 影響底層的傳輸模式，比如：配置可靠模式后，底層就是啟動反饋重傳的可靠機制等。

3. QoS應用

QoS個數比較多，每個都詳細分析篇幅會比較長，下面會選擇幾個比較常用的QoS進行詳細分析，對其他QoS感興趣的可以私信一起討論，QoS的應用還需要在實際應用中進行探索甚至擴展。

3.1. 可靠性策略

一般理解：應用是否需要DDS提供可靠傳輸，需要就是設置kind == RELIABLE，否則就設置kind == BEST-EFFORT。下面從兩個看起來比較愚蠢的疑問來進一步分析。

3.1.1. 設置為BEST-EFFORT就一定不可靠嗎？

答案是不一定。因為DDS里定義的可靠性QoS指的是“是否需要DDS做額外的可靠保證。”，比如傳輸層使用的是TCP傳輸或者其他RTPS底層的協議已經保證了可靠的傳輸，這時候配置DDS為BEST-EFFORT同樣可以實現可靠的傳輸。

3.1.2. 設置為RELIABLE就一定可靠嗎？

答案同樣是不一定。可靠的實現方式是確認重傳，簡單來說就是在接收到告知發送端數據已經收到之前，數據是需要緩存在隊列中以備可能需要的重傳，既然有隊列，就會有長度限制（無論是存儲在內存還是文件中，受限于存儲空間的大小），當隊列到達上限并需要發送新的樣本數據時，會有如下的幾個處理方式：

? 替換老的樣本數據，這種處理模式下，當被替換的數據丟包需要重傳時，無法重傳，從而造成“丟包”，就是無法實現可靠；

? 阻塞等待隊列有額外的空間，這種處理模式下可以實現“絕對”的可靠。

上面提到的隊列的長度限制在DDS中就體現在歷史數據測試（History）以及資源限制策略（ResourceLimits）。

3.1.3. 應用場景

可靠性的應用場景比較好定義，一般周期性的數據或者接收端只關心最新數據的場景下，設置為BEST-EFFORT；控制命令等關鍵的數據配置為可靠模式。

3.2. 持久化策略

對于數據寫者和數據讀者的含義分別是：? 數據寫者：控制是否保存當前所有匹配數據讀者端已經確認的樣本數據；? 數據讀者：控制數據讀者是否需要加入網絡前的歷史數據。主要分為兩類：? VOLATILE：不保留/不需要歷史數據，這是默認的配置，這種模式節省空間，只要當前所有的數據讀者均確認接收就可以把這包數據從DDS內部刪除；? TRANIENT_LOCAL/TRANSENT/PERSISTENT，這三種表示保留/需要歷史數據，只是歷史數據保存的方式不同，其中最常用的TRANSIENT_LOCAL是保存在數據寫者內部管理的內存隊列中，而后兩種則需要額外的服務（獨立的進程）來保存數據。

上圖是一個簡單的示意圖，其中數據寫者配置的是TRANSIENT_LOCAL，數據讀者1配置的VOLATILE，數據讀者2配置的TRANSIENT_LOCAL，按照時間描述系統運行的過程如下：

? T0時刻，數據寫者和數據讀者1同時上線，通過自動發現協議相互感知；

? T1時刻，用戶調用接口發送3個樣本數據；

? T2時刻，數據寫者根據自己配置的是TRANSIENT_LOCAL模式，將發送的3個樣本數據保存在內部的隊列中；

? T3時刻，數據讀者2上線，通過自動發現協議和數據寫者相互感知；

? T4時刻，數據寫者發現數據讀者2需要歷史數據，則會將緩存的3個數據樣本發送給數據讀者2。

3.2.1. 應用場景

持久化策略是實現“時間解耦”的重要QoS，即用戶可以通過該QoS解除系統中應用啟動先后順序的限制。或者是在上線后需要及時獲取系統中關心的最新狀態的場景。

3.3.分區策略

域內構成邏輯分區（通信平面的概念）由一個字符串序列組成，每個字符串表示一個分區的名稱。

• 分區策略與域隔離的主要區別：
• 分區策略與主題隔離的主要區別：
• 發送端與接收端匹配的條件如下：

3.3.1. 應用場景

? 分區可以在域不夠用的時候構建更多的邏輯通信平面；? 同一份數據需要屬于多個分類的場景可以用分區關聯。

3.4. 截止時間策略

? 在發布端，應用必須遵循這個約定，即在截止時間內必須發布一個數據（調用write()函數）。如果應用未遵循該約定， 則修改OFFERED_DEADLINE_MISSED _STATUS狀態以及調用監聽器中on_offered_deadline_missed方法。? 在訂閱端，表示對端的（所有匹配）發布者應該能夠滿足訂閱者期望得到數據的最低要求（最長允許時間）。若發布端未能遵循該約定，則修改REQUESTED_DEADLINE_MISSED _STATUS狀態以及調用監聽器中on_requested_deadline_missed方法。

3.4.1. 應用場景

截止時間可以用來檢測系統運行是否符合設計，并且提供當運行不符合設計時的異常處理，增加系統的魯棒性。在檢測再上一層，根據不同主題數據的截止時間的長短，用于底層調度不同主題數據發送或者處理的優先級以確保截止時間小的數據能夠盡快發送到接收端。

3.5. 所有權/權值策略

所有權策略主要有兩個配置：

? SHARED（共享型），這個是默認的配置，就是接收端可以收到所有匹配對端的樣本數據；

? EXCLUSIVE（獨占型），這個是數據讀者只會接收所有匹配對端中權值最高的樣本數據，下圖表示的就是一個示意場景，所有實體均配置EXCLUSIVE，并且其中一個數據寫者的權值是4大于另一個數據寫者的權值1，此時兩個數據寫者同時發送數據時，數據讀者只會接收到左邊這個權值較大的樣本數據。

3.5.1. 應用場景

所有權/權值策略可以用來實現系統簡單的熱備份容錯，如上圖所示的場景，權值低的右邊數據寫者作為左邊權值高的數據寫者的熱備（發送相同的數據，進行相同的業務），正常情況下接收端只會接收到一份數據，當配置存活性策略（Liveliness）感知到左邊的數據寫者失活（可能時由于硬件/軟件故障）后，右邊的數據寫者成為當前權值最高的對端，即可把數據提交給數據讀者，這樣整個系統還可以正常的運行。