Qt D-Bus 概要

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

D-Busは高速なバイナリメッセージパッシングプロトコルを採用しており、その低遅延と低オーバーヘッドにより、同一マシン内での通信に適しています。その仕様は現在、freedesktop.org プロジェクトによって定義されており、すべての関係者が利用可能です。

通信は、一般的に「バス」（名称の由来）と呼ばれる中央サーバーアプリケーションを介して行われますが、アプリケーション間の直接通信も可能です。バス上で通信する場合、アプリケーションは利用可能な他のアプリケーションやサービスを照会できるほか、必要に応じてそれらを起動することもできます。

バス

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

さらに、D-Bus では「システムバス」と「セッションバス」と呼ばれる 2 つのよく知られたバスが定義されています。これらのバスは、明確に定義された意味論を持っているという点で特殊です。つまり、一部のサービスは、これら 2 つのバスのいずれか、あるいは両方に存在するように定義されています。

例えば、コンピュータに接続されているハードウェアデバイスの一覧を照会したいアプリケーションは、おそらくシステムバス上で利用可能なサービスと通信することになるでしょう。一方、ユーザーのウェブブラウザを開く機能を提供するサービスは、おそらくセッションバス上で見つかるでしょう。

また、システムバス上では、各アプリケーションが提供できるサービスに制限が設けられていることが予想されます。したがって、特定のサービスが存在する場合、それが信頼できるアプリケーションによって提供されていると、かなり確実に判断できます。

概念

メッセージ

低レベルでは、アプリケーションは互いにメッセージを送信することで D-Bus を通じて通信を行います。メッセージは、リモートプロシージャコール（RPC）だけでなく、それに関連する応答やエラーを中継するために使用されます。バス上で使用される場合、メッセージには宛先があり、つまり関心のある当事者にのみルーティングされるため、「スウォーミング」やブロードキャストによる輻輳を回避できます。

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

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() マクロによって一意の識別子に関連付けられます。

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

チートシート

命名形式とその目的を覚えやすくするために、以下の表を参照してください：

デバッグ

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

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

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

メッセージに関する情報は、そのアプリケーションが起動されたコンソールに出力されます。