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

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

1.DDS規(guī)范概述

2.DCPS規(guī)范解讀

3. DDS-XTypes與IDL解讀

4. RTPS規(guī)范解讀

5. DDS安全規(guī)范解讀

6. DDS-RPC規(guī)范解讀

7. DDS-TSN規(guī)范解讀

8. DDS-XRCE規(guī)范解讀

1. 概述

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

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

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

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

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

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

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

? 資源使用配置：DDS可以通過QoS來配置使用的系統(tǒng)資源，典型的包括：歷史數(shù)據(jù)、資源限制、發(fā)端數(shù)據(jù)周期、收端數(shù)據(jù)周期；

? 發(fā)現(xiàn)階段配置：實體攜帶數(shù)據(jù)、組攜帶數(shù)據(jù)、主題攜帶數(shù)據(jù)、分區(qū)、存活性；

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

2.QoS檢查

2.1. 組合

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

2.2. 有效性和兼容性

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

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

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

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

2.3. QoS影響

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

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

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

3. QoS應用

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

3.1. 可靠性策略

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

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

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

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

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

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

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

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

3.1.3. 應用場景

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

3.2. 持久化策略

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

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

? T0時刻，數(shù)據(jù)寫者和數(shù)據(jù)讀者1同時上線，通過自動發(fā)現(xiàn)協(xié)議相互感知；

? T1時刻，用戶調用接口發(fā)送3個樣本數(shù)據(jù)；

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

? T3時刻，數(shù)據(jù)讀者2上線，通過自動發(fā)現(xiàn)協(xié)議和數(shù)據(jù)寫者相互感知；

? T4時刻，數(shù)據(jù)寫者發(fā)現(xiàn)數(shù)據(jù)讀者2需要歷史數(shù)據(jù)，則會將緩存的3個數(shù)據(jù)樣本發(fā)送給數(shù)據(jù)讀者2。

3.2.1. 應用場景

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

3.3.分區(qū)策略

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

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

3.3.1. 應用場景

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

3.4. 截止時間策略

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

3.4.1. 應用場景

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

3.5. 所有權/權值策略

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

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

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

3.5.1. 應用場景

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