1.1 DDSとは何か #
データ配信サービス（DDS）は、分散ソフトウェアアプリケーション通信に使用されるデータ中心の通信プロトコル。データプロバイダーとデータ消費者間の通信を可能にする通信アプリケーションプログラミングインターフェース（API）と通信セマンティクスを記述する。
データ中心型パブリッシュ・サブスクライブ（DCPS）モデルであるため、その実装では3つの主要なアプリケーションエンティティが定義されている
- 情報生成オブジェクトとその特性を定義するパブリケーションエンティティ
- 情報消費オブジェクトとその特性を定義するサブスクリプションエンティティ
- トピックとして送信される情報の種類を定義し、パブリッシャーとサブスクライバーをそのサービス品質（QoS）特性とともに作成し、上記エンティティの正しい動作を保証する構成エンティティ
DDSはQoSを使用しDDSエンティティの動作特性を定義している。QoSは個々のQoSポリシー（QoSPolicyから派生した型のオブジェクト）で構成されている。これらは、Policyで説明されている。
1.1.1 DCPSの概念モデル #
DCPSモデルでは、通信アプリケーションシステムの開発のために4つの基本要素が定義されている。 1. パブリッシャー: 実装するDataWriterの作成と構成を担当するDCPSエンティティ。 DataWriterは実際のメッセージ公開を担当する。 各DataWriterには、メッセージが公開されるトピックが割り当てられる。 2. サブスクライバー: サブスクライバーしているトピックの下で公開されたデータを受信する責任を持つDCPSエンティティ。 新しいデータの可用性をアプリケーションに通知する責任を持つDataReaderオブジェクトを1つ以上提供する。 3. トピック: パブリッシャーとサブスクライバーを結びつけるエンティティ。 DDSドメイン内で一意。 TopicDescriptionを通じて、パブリッシャーとサブスクライバーのデータ型の統一性を可能にします。 4. ドメイン: 異なるトピックの下でデータを交換する、1つ以上のアプリケーションに属するすべてのパブリッシャーとサブスクライバーをリンクするために使用される概念。 ドメインに参加する個々のアケーションは、DomainParticipantと呼ばれる。 DDSドメインはドメインIDによって識別される。 DomainParticipantはドメインIDを定義して、所属するDDSドメインを指定する。 異なるIDを持つ2つのDomainParticipantは、ネットワーク上でお互いの存在を認識しない。したがって、複数の通信チャネルを作成できる。 これは、それぞれのDomainParticipantが互いに通信する複数のDDSアプリケーションを使用しているが、これらのアプリケーションが干渉してはならない際に適用される。 DomainParticipantは他のDCPSエンティティのコンテナとして機能し、パブリッシャー、サブスクライバー、およびトピックエンティティのファクトリとして機能し、ドメイン内で管理サービスを提供する。
これらの要素は以下の図に示される。
1.2 RTPSとは何か #
リアルタイムパブリッシュサブスクライブ（RTPS）プロトコルは、DDSアプリケーションをサポートするために開発され、UDPのようなベストエフォート型トランスポート上のパブ-サブ通信ミドルウェアである。
さらに、Fast DDSはTCPと共有メモリ（SHM）トランスポートのサポートを提供している。
ユニキャストとマルチキャストの両方の通信をサポートするように設計されている。
RTPSの最上位には、DDSから継承された別の通信プレーンを定義するドメインがある。
複数のドメインが同時に独立して共存できる。
ドメインには任意の数のRTPSParticipantが含まれ、これはデータの送受信が可能な要素である。
これを行うために、RTPSParticipantはそのエンドポイントを使用する：
- RTPSWriter：データを送信できるエンドポイント。
- RTPSReader：データを受信できるエンドポイント。
RTPSParticipantは任意の数のライターおよびリーダーエンドポイントを持つことができる。
通信はトピックを中心に展開され、トピックは交換されるデータを定義及びラベル付けする。
トピックは特定の参加者(a specific participant)に属するものではない。参加者は、RTPSWriterを通じてトピックの下で公開されるデータに変更を加え、RTPSReaderを通じてサブスクリプションしているトピックに関連するデータを受信する。
通信単位はChangeと呼ばれ、トピックの下で書き込まれるデータの更新を表す。
RTPSReaders/RTPSWritersはこれらの変更をHistoryへ登録する。Historyは最近の変更をキャッシュとして機能するデータ構造である。
eProsima FastDDS のデフォルト設定では、RTPSWriterエンドポイントを通じて変更を公開すると、背後で以下の手順が発生する:
- 変更がRTPSWriterの履歴キャッシュへ追加
- RTPSWriterは、知っているすべてのRTPSReaderへ変更を送信する
- データを受信した後、RTPSReaderは新しい変更で履歴キャッシュを更新する
ただし、FastDDSは、RTPSWriters/RTPSReadersの動作を変更できる多数の設定をサポートしている。
RTPSエンティティのデフォルト設定の変更は、RTPSWriterとRTPSReader間のデータ交換フローの変更を意味する。さらに、サービス品質(QoS)ポリシーを選択することで、これらの履歴キャッシュの管理方法に様々な影響を与えることができるが、通信ループは同じままである。FastDDSにおけるRTPSプロトコルの実装について知りたい場合は、次のセクションを読んでほしい。