Qt D-Bus の概要

D-Busはプロセス間通信(IPC)とリモートプロシージャーコーリング(RPC)のメカニズムで、もともとLinux用に開発されたもので、既存の競合するIPCソリューションを1つの統一されたプロトコルで置き換えることを目的としている。また、システムレベル・プロセス（プリンターやハードウェア・ドライバー・サービスなど）と通常のユーザー・プロセス間の通信を可能にするために設計された。

高速なバイナリー・メッセージ・パッシング・プロトコルを使用し、低レイテンシーと低オーバーヘッドのため、同一マシン間の通信に適している。その仕様は現在、freedesktop.org プロジェクトによって定義されており、すべての関係者が利用できる。

通信は一般的に、「バス」と呼ばれる中央のサーバーアプリケーションを介して行われるが（これが名前の由来）、アプリケーション間の直接通信も可能である。バス上で通信を行う場合、アプリケーションは利用可能な他のアプリケーションやサービスを照会したり、オンデマンドで起動したりすることができます。

バス

D-Busバスは、多対多の通信が必要な場合に使用されます。これを実現するために、アプリケーションがバスに接続する前に中央サーバーが起動されます。このサーバーは、接続されたアプリケーションを追跡し、送信元から宛先までメッセージを適切にルーティングする責任を負う。

さらに、D-Busはシステム・バスとセッション・バスと呼ばれる2つのよく知られたバスを定義している。これらのバスは、明確に定義されたセマンティクスを持っているという意味で特別である。

例えば、コンピュータに接続されているハードウェアデバイスのリストを照会したいアプリケーションは、おそらくシステムバスで利用可能なサービスと通信するでしょう。

システムバスでは、各アプリケーションがどのようなサービスを提供することが許可されているかについての制限を見つけることもできます。したがって、あるサービスが存在する場合、それは信頼できるアプリケーションによって提供されていることを、合理的に確信することができます。

概念

メッセージ

低レベルでは、アプリケーションは互いにメッセージを送信することで、D-Bus上で通信を行います。メッセージは、リモート・プロシージャ・コールと、それに関連するリプライやエラーをリレーするために使用されます。バス上で使用される場合、メッセージには宛先があります。つまり、メッセージは関係者のみにルーティングされ、"swarming "やブロードキャストによる輻輳を回避します。

しかし、"シグナル・メッセージ"（Qtのシグナルとスロットのメカニズムに基づいたコンセプト）と呼ばれる特別な種類のメッセージには、あらかじめ定義された宛先がありません。その目的は1対多のコンテキストで使用することなので、シグナルメッセージは "opt-in "メカニズムで動作するように設計されています。

Qt D-Bus モジュールは、メッセージの低レベルの概念を、Qt 開発者に馴染みのある、よりシンプルなオブジェクト指向のアプローチに完全にカプセル化します。ほとんどの場合、開発者はメッセージの送受信について心配する必要はありません。

サービス名

バス上で通信を行う場合、アプリケーションは "サービス名 "と呼ばれるものを取得します。サービス名はD-Busバス・デーモンによって仲介され、あるアプリケーションから別のアプリケーションへメッセージをルーティングするために使用されます。サービス名に類似した概念として、IPアドレスとホスト名があります。コンピュータは通常1つのIPアドレスを持ち、ネットワークに提供するサービスに応じて1つ以上のホスト名を持つことがあります。

一方、バスを使用しない場合、サービス名も使用されない。ピアは既知であるため、そのピアやIPアドレスを見つけるためにホスト名を使用する必要はありません。

D-Busのサービス名の形式は、実はホスト名と非常に似ています。ドットで区切られた文字と数字の羅列です。一般的には、そのサービスを定義した組織のドメイン名に従ってサービス名を付けることさえあります。

例えば、D-Busサービスはfreedesktop.org によって定義され、バス上ではサービス名で見つけることができます：

org.freedesktop.DBus

オブジェクト・パス

ネットワークホストと同様に、アプリケーションはオブジェクトをエクスポートすることで、他のアプリケーションに特定のサービスを提供します。これらのオブジェクトは、QObject から派生したクラスが持つ親子関係のように、階層的に構成されています。しかし、1つ違うのは、すべてのオブジェクトが最終的な親として持つ「ルートオブジェクト」という概念があることです。

Webサービスとのアナロジーを続けると、オブジェクト・パスはURLのパス部分に相当する：

D-Busのオブジェクト・パスは、ファイルシステムのパス名に似ています。スラッシュで区切られたラベルで、それぞれ文字、数字、アンダースコア文字（"_"）で構成されています。スラッシュで始まり、スラッシュで終わってはいけません。

インターフェース

インターフェイスは、C++の抽象クラスやJavaのinterface キーワードに似ており、呼び出し側と呼び出し側の間に確立される「契約」を宣言します。つまり、利用可能なメソッド、シグナル、プロパティの名前と、通信が確立されたときにどちらか一方に期待される動作を宣言します。

Qtは、プラグイン・システムで非常によく似たメカニズムを使っている：C++の基本クラスは、Q_DECLARE_INTERFACE （）マクロによって一意の識別子と関連付けられます。

D-Busのインターフェース名は、実際、Qtプラグイン・システムで提案されているものと似た方法で命名されます：識別子は通常、そのインターフェースを定義したエンティティのドメイン名から構成されます。

チートシート

命名形式とその目的を覚えやすくするために、以下の表を使用することができます：

デバッグ

D-Busを使用するアプリケーションを開発する際、各アプリケーションがバス上で送受信するメッセージに関する情報を確認できると便利な場合があります。

この機能は、各アプリケーションを実行する前にQDBUS_DEBUG 環境変数を設定することで、アプリケーションごとに有効にすることができます。例えば、D-Bus リモコン・カーの例では、コントローラとカーを次のように実行することで、カーだけ のデバッグを有効にすることができます：

examples/dbus/remotecontrolledcar/controller/controller &
QDBUS_DEBUG=1 examples/dbus/remotecontrolledcar/car/car &

メッセージの情報は、アプリケーションが起動したコンソールに書き込まれます。