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

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

本期還是DCPS規(guī)范，填上期沒有聊完的QoS的坑。本系列文章將包括以下內(nèi)容陸續(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ù)還可以通過靈活的服務(wù)質(zhì)量 (QoS) 規(guī)范進(jìn)行共享，包括可靠性、系統(tǒng)運(yùn)行狀況（活躍性）甚至安全性。在真實(shí)的系統(tǒng)中，并非所有其他端點(diǎn)都需要本地存儲(chǔ)中的所有數(shù)據(jù)。DDS很聰明，只發(fā)送它需要的內(nèi)容。如果消息并不總是到達(dá)預(yù)期目的地，中間件會(huì)在需要時(shí)實(shí)現(xiàn)可靠性。當(dāng)系統(tǒng)發(fā)生變化時(shí)，中間件會(huì)動(dòng)態(tài)地確定將哪些數(shù)據(jù)發(fā)送到哪里，并智能地將變化通知參與者。如果總數(shù)據(jù)量很大，DDS會(huì)智能過濾并僅發(fā)送每個(gè)端點(diǎn)真正需要的數(shù)據(jù)。當(dāng)需要快速更新時(shí)，DDS會(huì)發(fā)送多播消息來同時(shí)更新許多遠(yuǎn)程應(yīng)用程序。隨著數(shù)據(jù)格式的發(fā)展，DDS會(huì)跟蹤系統(tǒng)各個(gè)部分使用的版本并自動(dòng)進(jìn)行轉(zhuǎn)換。對(duì)于安全關(guān)鍵型應(yīng)用程序，DDS控制訪問、強(qiáng)制執(zhí)行數(shù)據(jù)流路徑并動(dòng)態(tài)加密數(shù)據(jù)?！?/p>

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

“當(dāng)您在非常動(dòng)態(tài)、要求嚴(yán)格且不可預(yù)測的環(huán)境中以極高的速度同時(shí)指定所有這些內(nèi)容時(shí)，DDS 的真正威力就會(huì)顯現(xiàn)出來?！?/p>

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

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

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

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

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

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

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

2.QoS檢查

2.1. 組合

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

2.2. 有效性和兼容性

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

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

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

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

2.3. QoS影響

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

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

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

3. QoS應(yīng)用

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

3.1. 可靠性策略

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

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

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

3.1.2. 設(shè)置為RELIABLE就一定可靠嗎？

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

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

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

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

3.1.3. 應(yīng)用場景

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

3.2. 持久化策略

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

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

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

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

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

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

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

3.2.1. 應(yīng)用場景

持久化策略是實(shí)現(xiàn)“時(shí)間解耦”的重要QoS，即用戶可以通過該QoS解除系統(tǒng)中應(yīng)用啟動(dòng)先后順序的限制?；蛘呤窃谏暇€后需要及時(shí)獲取系統(tǒng)中關(guān)心的最新狀態(tài)的場景。

3.3.分區(qū)策略

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

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

3.3.1. 應(yīng)用場景

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

3.4. 截止時(shí)間策略

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

3.4.1. 應(yīng)用場景

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

3.5. 所有權(quán)/權(quán)值策略

所有權(quán)策略主要有兩個(gè)配置：

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

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

3.5.1. 應(yīng)用場景

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