DDSのインタフェース定義言語と通信プロトコルRTPS

DDSの通信プロトコルRTPS実装の一つFreeRTPSを試す (2)で@OTLさんから質問をいただきました。

このサンプル見るとfreertpsではシリアライズをしてないように（ROSのシリアライズを呼んでいる）みえますが、DDSっていうのは型がある通信（シリアライズを含む）だと思っているんですが、そのへんどうなんでしょうか？ DDSがよくわかってません

http://ros.youtalk.jp/2017/06/28/freertps2.html#comment-3390690590

私もこの問題の答えを知らないため、DDSをより深く知る意味でも、まずはDDSの仕様を見ていきましょう。

DDSのインタフェース定義言語（IDL）

ROSでいうメッセージやサービスのインタフェース定義言語（IDL）と同様に、DDSにもIDLがあります。

ROS 2でもROS 1と同様（デフォルト値などの改良はある）のメッセージやサービスのIDLを用いており、それをDDSのIDLに対応付けすることで、表面上、ROSインタフェースを維持したままDDSでの通信を実現しています。

http://design.ros2.org/articles/mapping_dds_types.html

それでは、DDSのIDLはどのように定義されているのでしょうか？

http://www.omg.org/spec/IDL35/3.5/

この仕様書のPDFをざっくりと斜め読みしたところ、興味深いことがわかりました。DDSのIDLはCORBAのそれと同じであることがわかりました。

This document specifies the OMG Interface Definition Language (IDL). The IDL was formerly specified as a collection of chapters within the CORBA 3 specification. This document separates the IDL from the CORBA so that specifications that use the IDL can reference it more easily. Having a separate IDL specification document will also allow it to evolve separately from the CORBA specification.

DDSとCORBAはともに同じOMG (Object Management Group)が承認したものですので、通信の仕組みは

• サーバ・クライアント型のCORBA
• Publisher/Subscriber型のDDS

で異なりますが、流れるデータの定義に関しては共通である方がメリットが多いからだと思います。

DDSの配信プロトコルRTPS (Real-Time Publish-Subscribe Wire Protocol)

少しわかりづらいのですが、DDSはPublisher/Subscriber型通信の仕様の名称であり、配信プロトコル自体はRTPS (Real-Time Publish-Subscribe Wire Protocol)という名称で別途定義されています。

つまり、OSI参照モデルでいう

• アプリケーション層：DDS（HTTP, IMAPなどと同様）
• トランスポート層：RTPS（TCP, UDPなどと同様）

の関係といえるでしょうか。

http://www.omg.org/spec/DDSI/2.1/

こちらも仕様書のPDFをざっくり斜め読みしました。 RTPSの主な特徴は以下の通りです。 これが全部事実だとすると、恐ろしく野心的で汎用的なプロトコルですね。

• RTPSの性能とQoS特性は標準的なネットワーク場で、リアルタイムアプリケーションのためのベストエフォートと高信頼のPub/Sub通信を実現する。

Performance and quality-of-service properties to enable best-effort and reliable publish-subscribe communications for real-time applications over standard IP networks.

• フォールトトレランス（故障が起きても全体動作に支障がない）性により、単一障害点のないネットワークを構築する。

Fault tolerance to allow the creation of networks without single points of failure.

• 後方互換性と相互接続性を失うことなく、配信プロトコルを拡張することができる。

Extensibility to allow the protocol to be extended and enhanced with new services without breaking backwards compatibility and interoperability.

• プラグアンドプレイの接続性により、新しいアプリケーションは自動的に発見され、構成変更なくネットワークにいつでも参加、自体することができる。

Plug-and-play connectivity so that new applications and services are automatically discovered and applications can join and leave the network at any time without the need for reconfiguration.

• 構成変更の柔軟性により、高信頼データの配信や正確な時系列データの配信の要求を満たすことができる。

Configurability to allow balancing the requirements for reliability and timeliness for each data delivery.

• プロトコルにモジュール性があり、RTPSのサブセットを実装した単純な機器もネットワークに参加させることができる。

Modularity to allow simple devices to implement a subset of the protocol and still participate in the network.

• 数千のSubscriberを持つような（訳注：別文章より転載）システムにも適用できるスケーラビリティを持つ。

Scalability to enable systems to potentially scale to very large networks.

• IDLを使った型安全により、プログラミングエラーを防ぐ。

Type-safety to prevent application programming errors from compromising the operation of remote nodes.

実際のプロトコルはUDP/IPの上に実装され、バイナリのフォーマットになって配信されます。

DDSの通信データに関してだいたい把握できたところで、次回は今日の話に沿ってFreeRTPSの実装を見ていきます。