前言

最近做畢設要做一個DDS系統和TISA系統的網關，完全沒有基礎，只好對著OpenDDS的Developers’ Guide和《分布式系統實時發布/訂閱數據分發技術》這本書一點一點學(順便吐槽這本書就是guide的翻譯版，很多語句不通)。遇到很多問題，持續更新，隨著慢慢看能解決一部分，希望高手指正。

一些概念

• entity是什么？
  答：DCPS entities包括topic, data writer,data reader, publisher, subscriber, domain participant。
• sample數據樣本?
  答：需要發布/訂閱的數據。
• DDS application是什么？
  答：dds應用程序，可以認為是需要發布、訂閱數據的雙方，datawriter,datareader是它們用于收發的一部分。
• 實例和對象的區別？
  答：抽象類是無法實例化的，它們的對象只能叫對象；一般類的實例化對象，即可簡稱對象，也可簡稱實例。
• sample，instance（實例），fields（字段）和key（鍵）的關系？
  
  OpenDDS要求數據類型是結構體（類），instance便是這個類的對象（實例），具體來說就是被傳輸的sample。
  一個域里有多種主題；發布消息時，一個主題下有按照結構體（類）創建多個實例instances；key用來識別同一主題下的不同的實例。發布時，擁有不同key的sample是同一主題下的不同實例。默認QOS下，同一個key下的后繼的樣本視為之前樣本的替代。而字段其實就是只源碼里的某一段代碼。

（漢語書中對example和instance的翻譯都是“實例”，我也是迷醉。。。。）其實有點面向對象的概念。

源文件解讀

Chap3的例子

• chap3的例子中message.subject_id是鍵，用來區分不同實例。可是明明Messenger::Message message;只創建了一個message實例,每次更改鍵值其實不是創建不同實例，而是同一個實例改變了值發出去。
• chap3例子里面用了一個for循環來發布不同的實例，所有發布出去之后，再等待subscriber接收。因此，wait_for_acknowledgements()是在for循環之外的。原因：

由于DDS內部數據的發布和訂閱是解耦的，因此，如果在發送的所有數據已經被訂閱所接收之前，發布被斷開/關閉，則不能保證數據被遞送。如果應用要求所有的發布數必須被接收，那么，可以進行wait_for_acknowledgements()操作，允許發布進行等待，直到subscriber接受完所有寫入數據。

其他例子

待解決的疑問

有關概念的疑問

• 域參與者工廠（Participantfactory）是個什么？
• 一個訂閱者、一個發布者的體系是怎么發布訂閱的？InfpRepo怎么工作？

有關創建工程的疑問

• Chapter3的messenger.idl和后面的publisher有什么關系？
• perl干什么用的？run_test.pl為什么可以在命令行中顯示發布/訂閱過程？
• chapter3示例中在cpp文件中先建立subscriber和publisher，然后是datawriter和datareader，是不是和實際情況相反？
• 如何拓展到多個訂閱/發布體系？
• 似乎只創建了發布者和訂閱者，和需要發布數據的應用程序如何建立聯系（接口）？

有關命令行運行的疑問

• 運行chapter3的示例老出現：
  [warning] Could not find FQDN. Using "QUBPJJDAV3WB803" as fully qualified hostname, please correct system configuration.
  什么原因？和系統configuration有什么關系？

Example使用和編譯工程

• 文件夾介紹
  /bin/中有DCPSInforepo.exe
  /DevGuideExamples/主要包含三個示例程序
  /docs中包含很多說明文檔，可以在github中閱讀效果更好
  /examples里有四個例子
  /tools/里有monitor和圖形化界面

• OpenDDS自帶的各種例子如何解讀、加以學習？
  漢語書和Developer’s Guide上只有一個例子，是此路徑
  D:\OpenDDS-3.13.1\DevGuideExamples\DCPS\Messenger下的publisher.exe和subscriber.exe罷了。example文件夾和Devexampl’e文件夾下的其他例程，運行方法參照README文檔，同樣命令行啟動就好。**自己編寫publisher和subscriber編譯之后運行，方法是一樣的。只是自己編寫的過程中需要注意頭文件的引用。

• 以D:\OpenDDS-3.13.1\DevGuideExamples\DCPS\Messenger.minimal為例，里面有三個工程文件:

  MessengerMinimal_Idl.vcxproj MessengerMinimal_Publisher.vcxproj MessengerMinimal_Subscriber.vcxproj

一個示例文件夾下，Messenger，Publisher’和Subscriber是三個工程，分別由三個工程文件.vcxproj組織。點開之后可以看到各種依賴項、頭文件、源程序等等。其中Messenger是沒有源文件和頭文件的，因為僅IDL文件編譯得到，沒有自己編寫的.cpp源文件，只有IDL編譯器編譯生成的.cpp文件。在MessengerMinimal_Idl.vcxproj工程中能看到定義數據類型的.IDL文件和輔助編譯的.mpc文件。另外，兩個中能看到Publisher.cpp和Subscriber.cpp源文件。

• 搞清楚一對一體系從頭開始，需要寫哪些文件，進行什么步驟的編譯，最后能生成在cmd中運行的.exe文件？
  答：

• 創建Demo.idl文件，在里面定義要傳輸的DCPS數據類型（定義結構體）、加入編譯指令、定義DCPS數據類型的鍵；
• 編寫Demo.mpc文件，里面定義了一個idl工程；
• 使用MPC命令生成Visual Studio的解決方案文件和工程文件.sln和.vcproj；
• VS中打開.sln文件，直接編譯，即可編譯前面的idl文件，生成各種支持文件；
• 在Demo.idl中加入publisher相關的內容，新建Publisher.cpp文件，再用之前的命令生成.sln文件。
• 更改publisher.cpp中的邏輯內容；
• 編譯publisher.cpp生成.exe，即得到publisher應用。
  build publisher from scratch

• 如何使用OpenDDS建立訂閱/發布體系？
  答： 總體分為兩步：寫IDL、cpp邏輯、編譯生成.exe文件，之后在命令行中采用共享文件或者其他方式啟動；只使用Inforepo，其他的可以自己改寫。

  • 建立發布者和訂閱者編譯過程：
    見上一個問題
  • 命令行啟動：
• 使用DCPS信息倉庫（DCSPInfoRepo.exe），在D:\OpenDDS-3.13.1\bin路徑之下，命令行中輸入D:\OpenDDS-3.13.1\bin\DCPSInfoRepo -o $publisher和subscriber的路徑\simple.ior 啟動信息倉庫，并將信息寫入simple.ior文件，供Publisher和Subscriber使用。注意,為了能被publisher使用，需要寫入publisher所在的目錄或者啟動publisher時注明.ior文件的系統路徑。
  2. 啟動訂閱者和發布者,命令行中輸入：//第一個命令行窗口 subscriber -DCPSInfoRepo file://simple.ior //再開一個新的命令行窗口輸入 publisher -DCPSInfoRepo file://simple.ior

結構

• Datawriter和DataReader的作用：
  每個Datawriter只能綁定一個topic。應用程序使用Datawriter的指定類型的接口，在該Datawriter主題上發布數據樣本。Datareader負責對數據進行編碼，并傳遞給Publisher準備進行傳輸，Publisher負責獲取待發布的數據并把它分發到所在域中所有的訂閱者處。一個Publisher可以管理一個或多個Datawriter。

  每個Datareader只能綁定一個Topic。Subscriber從Publisher處接受數據，并將其傳遞給所有與其相連的Datareader。Datareader負責從訂閱者那里獲取數據，并解碼為對應主題的適當類型，再將樣本傳遞給應用程序。

集中式發現InfoRepo

不參與數據傳遞，只用于DDS應用發現彼此；

在一個DDS域上，可以運行多個Inforepo，分別負責互不重疊的部分；

多個inforepo可以形成一個聯邦，聯邦中的不同repository為了互相識別，需要有識別碼；

點對點發現

• networtrk port和network endpoints都是什么？網絡端口和網絡節點。
• RTPS，可以和非OpenDDS交互。
• 怎么理解’Interoperability with other DDS implementations must utilize the peer-to-peer method, but can be useful in OpenDDS-only deployments.‘
  答：OpenDDS系統中的應用程序如果希望和非OpenDDS系統，但遵循OpenDDS規范的應用進行交互，需要用RTPS，形成peer to peer發現。

QoS策略

DEADLINE

• 功能：允許應用程序在指定的時間內檢測數據是否被寫入或者讀取，在訂閱端指定writer()發布樣本的最大間隔時間，在訂閱端制定接受實例的新樣本的最大時間間隔。
• 適用： 需要周期發布數據的應用程序，實體包括:DataWriter,DataReader，topic等。
• 生命周期：可在關聯的實體啟用之后修改策略，
  • 用于DataWriter和Datareader，需要所有關聯的寫著、讀者都修改
  • 用于Topic，策略修改后，只影響以后創建的寫者、讀者。

LIFESPAN

• 功能：允許應用程序指定樣本合適失效，失效的樣本不會傳遞給subscriber；
• 適用：topic，DataWriter
• 生命周期：可在運行時修改，只影響修改后發布的數據。

TIME_BASED_FILTER

• 功能：指定接收者以多大的時間間隔接收數據；
• 適用：Datawriter

Note:4,5,6是分別為三類實體提供附加信息的策略，分別為user，topic，和group，其中datawriter和datareader是用戶user，而publisher和subscriber屬于group，參照結構圖可以理解。

USER_DATA

• 功能：應用程序提供保護附加信息的方式；
• 適用：Domainparticipaint, DataReader, DataWriter;
• 生命周期：

TOPIC_DATA

• 功能：；
• 適用：topic;
• 生命周期：對于DataWriter， Datareader， 內置主題數據有效。

GROUP_DATA

• 功能：；
• 適用：topic;
• 生命周期：對于DataWriter， Datareader， 內置主題數據有效。

LIVELINESS

• 功能：控制何時以及如何檢測參與者是否還存活，存活表示參與者仍然處于可訪問和激活狀態；
• 適用：topic,datareader,datawriter,在主題上使用該策略，會是與該主題關聯的datawriter，datareader都有效;
• 選項：kind有三種選擇，表示自動或者實體手動檢測，檢測參與者存活。

RELIABILITY

• 功能：按策略設置控制數據寫者對數據樣本的處理方式。
• 適用：主題，寫者，讀者
• 選項：kind設為REALIABLE_REALIABILITY_QoS表示表示服務最終把數據樣本遞送給適當的Datareader。BEST_EFFORT_QOS表示數據寫者不保證數據有效性，允許丟棄樣本。

后面14個之后再更新。。感覺當務之急是如何使用，不是背手冊。

QOS的表示方法一個結構體

每個QoS策略都用一個結構來表示；每個實體都支持一部分策略，并用一個結構體把所支持的策略組合在一起。

QoS匹配模型

實體對象：除了前面說的實體，還包括DomainParticipantFactory

set_qos()用來為某個實體設置QoS,將新的策略添加到之前的策略集上，如果和之前的不一致，則更改失敗。

為了保證通信，發布端和訂閱端的QoS應當兼容。

RxO值是否N/A

適用	同時適用于發布端、訂閱端	同前	只能用于一種
兼容	必須設為兼容	自動兼容	無關

“能否改變”特性決定了某個QoS策略能否在實體有效后再改變。

從Rxo和“能否改變"兩個維度評價QoS。

第七章 傳輸配置

傳輸的概念

總結

以上是生活随笔為你收集整理的OpenDDS自学的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。