前言

最近做畢設(shè)要做一個(gè)DDS系統(tǒng)和TISA系統(tǒng)的網(wǎng)關(guān)，完全沒(méi)有基礎(chǔ)，只好對(duì)著OpenDDS的Developers’ Guide和《分布式系統(tǒng)實(shí)時(shí)發(fā)布/訂閱數(shù)據(jù)分發(fā)技術(shù)》這本書(shū)一點(diǎn)一點(diǎn)學(xué)(順便吐槽這本書(shū)就是guide的翻譯版，很多語(yǔ)句不通)。遇到很多問(wèn)題，持續(xù)更新，隨著慢慢看能解決一部分，希望高手指正。

一些概念

• entity是什么？
  答：DCPS entities包括topic, data writer,data reader, publisher, subscriber, domain participant。
• sample數(shù)據(jù)樣本?
  答：需要發(fā)布/訂閱的數(shù)據(jù)。
• DDS application是什么？
  答：dds應(yīng)用程序，可以認(rèn)為是需要發(fā)布、訂閱數(shù)據(jù)的雙方，datawriter,datareader是它們用于收發(fā)的一部分。
• 實(shí)例和對(duì)象的區(qū)別？
  答：抽象類是無(wú)法實(shí)例化的，它們的對(duì)象只能叫對(duì)象；一般類的實(shí)例化對(duì)象，即可簡(jiǎn)稱對(duì)象，也可簡(jiǎn)稱實(shí)例。
• sample，instance（實(shí)例），fields（字段）和key（鍵）的關(guān)系？
  
  OpenDDS要求數(shù)據(jù)類型是結(jié)構(gòu)體（類），instance便是這個(gè)類的對(duì)象（實(shí)例），具體來(lái)說(shuō)就是被傳輸?shù)膕ample。
  一個(gè)域里有多種主題；發(fā)布消息時(shí)，一個(gè)主題下有按照結(jié)構(gòu)體（類）創(chuàng)建多個(gè)實(shí)例instances；key用來(lái)識(shí)別同一主題下的不同的實(shí)例。發(fā)布時(shí)，擁有不同key的sample是同一主題下的不同實(shí)例。默認(rèn)QOS下，同一個(gè)key下的后繼的樣本視為之前樣本的替代。而字段其實(shí)就是只源碼里的某一段代碼。

（漢語(yǔ)書(shū)中對(duì)example和instance的翻譯都是“實(shí)例”，我也是迷醉。。。。）其實(shí)有點(diǎn)面向?qū)ο蟮母拍睢?br />

源文件解讀

Chap3的例子

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

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

其他例子

待解決的疑問(wèn)

有關(guān)概念的疑問(wèn)

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

有關(guān)創(chuàng)建工程的疑問(wèn)

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

有關(guān)命令行運(yùn)行的疑問(wèn)

• 運(yùn)行chapter3的示例老出現(xiàn)：
  [warning] Could not find FQDN. Using "QUBPJJDAV3WB803" as fully qualified hostname, please correct system configuration.
  什么原因？和系統(tǒng)configuration有什么關(guān)系？

Example使用和編譯工程

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

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

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

  MessengerMinimal_Idl.vcxproj MessengerMinimal_Publisher.vcxproj MessengerMinimal_Subscriber.vcxproj

一個(gè)示例文件夾下，Messenger，Publisher’和Subscriber是三個(gè)工程，分別由三個(gè)工程文件.vcxproj組織。點(diǎn)開(kāi)之后可以看到各種依賴項(xiàng)、頭文件、源程序等等。其中Messenger是沒(méi)有源文件和頭文件的，因?yàn)閮HIDL文件編譯得到，沒(méi)有自己編寫(xiě)的.cpp源文件，只有IDL編譯器編譯生成的.cpp文件。在MessengerMinimal_Idl.vcxproj工程中能看到定義數(shù)據(jù)類型的.IDL文件和輔助編譯的.mpc文件。另外，兩個(gè)中能看到Publisher.cpp和Subscriber.cpp源文件。

• 搞清楚一對(duì)一體系從頭開(kāi)始，需要寫(xiě)哪些文件，進(jìn)行什么步驟的編譯，最后能生成在cmd中運(yùn)行的.exe文件？
  答：

• 創(chuàng)建Demo.idl文件，在里面定義要傳輸?shù)腄CPS數(shù)據(jù)類型（定義結(jié)構(gòu)體）、加入編譯指令、定義DCPS數(shù)據(jù)類型的鍵；
• 編寫(xiě)Demo.mpc文件，里面定義了一個(gè)idl工程；
• 使用MPC命令生成Visual Studio的解決方案文件和工程文件.sln和.vcproj；
• VS中打開(kāi).sln文件，直接編譯，即可編譯前面的idl文件，生成各種支持文件；
• 在Demo.idl中加入publisher相關(guān)的內(nèi)容，新建Publisher.cpp文件，再用之前的命令生成.sln文件。
• 更改publisher.cpp中的邏輯內(nèi)容；
• 編譯publisher.cpp生成.exe，即得到publisher應(yīng)用。
  build publisher from scratch

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

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

結(jié)構(gòu)

• Datawriter和DataReader的作用：
  每個(gè)Datawriter只能綁定一個(gè)topic。應(yīng)用程序使用Datawriter的指定類型的接口，在該Datawriter主題上發(fā)布數(shù)據(jù)樣本。Datareader負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行編碼，并傳遞給Publisher準(zhǔn)備進(jìn)行傳輸，Publisher負(fù)責(zé)獲取待發(fā)布的數(shù)據(jù)并把它分發(fā)到所在域中所有的訂閱者處。一個(gè)Publisher可以管理一個(gè)或多個(gè)Datawriter。

  每個(gè)Datareader只能綁定一個(gè)Topic。Subscriber從Publisher處接受數(shù)據(jù)，并將其傳遞給所有與其相連的Datareader。Datareader負(fù)責(zé)從訂閱者那里獲取數(shù)據(jù)，并解碼為對(duì)應(yīng)主題的適當(dāng)類型，再將樣本傳遞給應(yīng)用程序。

集中式發(fā)現(xiàn)InfoRepo

不參與數(shù)據(jù)傳遞，只用于DDS應(yīng)用發(fā)現(xiàn)彼此；

在一個(gè)DDS域上，可以運(yùn)行多個(gè)Inforepo，分別負(fù)責(zé)互不重疊的部分；

多個(gè)inforepo可以形成一個(gè)聯(lián)邦，聯(lián)邦中的不同repository為了互相識(shí)別，需要有識(shí)別碼；

點(diǎn)對(duì)點(diǎn)發(fā)現(xiàn)

• networtrk port和network endpoints都是什么？網(wǎng)絡(luò)端口和網(wǎng)絡(luò)節(jié)點(diǎn)。
• RTPS，可以和非OpenDDS交互。
• 怎么理解’Interoperability with other DDS implementations must utilize the peer-to-peer method, but can be useful in OpenDDS-only deployments.‘
  答：OpenDDS系統(tǒng)中的應(yīng)用程序如果希望和非OpenDDS系統(tǒng)，但遵循OpenDDS規(guī)范的應(yīng)用進(jìn)行交互，需要用RTPS，形成peer to peer發(fā)現(xiàn)。

QoS策略

DEADLINE

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

LIFESPAN

• 功能：允許應(yīng)用程序指定樣本合適失效，失效的樣本不會(huì)傳遞給subscriber；
• 適用：topic，DataWriter
• 生命周期：可在運(yùn)行時(shí)修改，只影響修改后發(fā)布的數(shù)據(jù)。

TIME_BASED_FILTER

• 功能：指定接收者以多大的時(shí)間間隔接收數(shù)據(jù)；
• 適用：Datawriter

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

USER_DATA

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

TOPIC_DATA

• 功能：；
• 適用：topic;
• 生命周期：對(duì)于DataWriter， Datareader， 內(nèi)置主題數(shù)據(jù)有效。

GROUP_DATA

• 功能：；
• 適用：topic;
• 生命周期：對(duì)于DataWriter， Datareader， 內(nèi)置主題數(shù)據(jù)有效。

LIVELINESS

• 功能：控制何時(shí)以及如何檢測(cè)參與者是否還存活，存活表示參與者仍然處于可訪問(wèn)和激活狀態(tài)；
• 適用：topic,datareader,datawriter,在主題上使用該策略，會(huì)是與該主題關(guān)聯(lián)的datawriter，datareader都有效;
• 選項(xiàng)：kind有三種選擇，表示自動(dòng)或者實(shí)體手動(dòng)檢測(cè)，檢測(cè)參與者存活。

RELIABILITY

• 功能：按策略設(shè)置控制數(shù)據(jù)寫(xiě)者對(duì)數(shù)據(jù)樣本的處理方式。
• 適用：主題，寫(xiě)者，讀者
• 選項(xiàng)：kind設(shè)為REALIABLE_REALIABILITY_QoS表示表示服務(wù)最終把數(shù)據(jù)樣本遞送給適當(dāng)?shù)腄atareader。BEST_EFFORT_QOS表示數(shù)據(jù)寫(xiě)者不保證數(shù)據(jù)有效性，允許丟棄樣本。

后面14個(gè)之后再更新。。感覺(jué)當(dāng)務(wù)之急是如何使用，不是背手冊(cè)。

QOS的表示方法一個(gè)結(jié)構(gòu)體

每個(gè)QoS策略都用一個(gè)結(jié)構(gòu)來(lái)表示；每個(gè)實(shí)體都支持一部分策略，并用一個(gè)結(jié)構(gòu)體把所支持的策略組合在一起。

QoS匹配模型

實(shí)體對(duì)象：除了前面說(shuō)的實(shí)體，還包括DomainParticipantFactory

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

為了保證通信，發(fā)布端和訂閱端的QoS應(yīng)當(dāng)兼容。

RxO值是否N/A

適用	同時(shí)適用于發(fā)布端、訂閱端	同前	只能用于一種
兼容	必須設(shè)為兼容	自動(dòng)兼容	無(wú)關(guān)

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

從Rxo和“能否改變"兩個(gè)維度評(píng)價(jià)QoS。

第七章 傳輸配置

傳輸?shù)母拍?/h3>

總結(jié)

以上是生活随笔為你收集整理的OpenDDS自学的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。