Dバス

D-Bus（「Desktop Bus」の略^[4]）は、同じマシン上で同時に実行される複数のプロセス間の通信を可能にするメッセージ指向のミドルウェアメカニズムです。 ^{[5] [6] D-Busは、} GNOME開発者のHavoc PenningtonがGNOMEやKDEなどのLinuxデスクトップ環境が提供するサービスを標準化するために始めたfreedesktop.orgプロジェクトの一環として開発されました。^{[7] [8] [リンク切れ‍ ]}

freedesktop.org プロジェクトでは、仕様のリファレンス実装として、libdbus と呼ばれる無料のオープンソース ソフトウェア ライブラリも開発しました。このライブラリは D-Bus 自体ではなく、GDBus (GNOME)、 ^[9] QtDBus ( Qt /KDE)、^[10] dbus-java ^{[11]および sd-bus (} systemdの一部) ^[12]など、D-Bus 仕様の他の実装も存在します。

D-Busは、当初GNOMEおよびKDE Linuxデスクトップ環境（それぞれCORBAおよびDCOP）で使用されるソフトウェアコンポーネント通信システムを置き換えるために設計されたプロセス間通信（IPC）メカニズムです。 ^{[13] [14]}これらのデスクトップ環境のコンポーネントは通常、多くのプロセスに分散されており、各プロセスは少数（通常は1つ）のサービスのみを提供します。これらのサービスは、通常のクライアントアプリケーションまたはデスクトップ環境の他のコンポーネントによってタスクを実行するために使用されます。 ^[15]

D-Busは、プロセスグループ間のすべての通信を単一の共有仮想チャネルに集約するソフトウェアバス 抽象化を提供します。 ^[6]バスに接続されたプロセスは、バスが内部的にどのように実装されているかを認識しませんが、D-Bus仕様では、バスに接続されたすべてのプロセスがバスを介して相互に通信できることが保証されています。D-Busでは、1対1のIPCに比べて少なくとも2.5倍のパフォーマンス損失が発生します。^[16]

Linuxデスクトップ環境では、複数のバスをインスタンス化することでD-Busの機能を活用している。^{[17] [6] [18]}

• システムのすべてのユーザーとプロセスが利用できる単一のシステム バス。システム サービス (つまり、オペレーティング システムとシステムデーモンによって提供されるサービス)へのアクセスを提供します。
• 各ユーザーログインセッション用のセッションバス。同じデスクトップセッション内のユーザーアプリケーションにデスクトップサービスを提供し、デスクトップセッション全体の統合を可能にします。

プロセスは、アクセスが許可されていれば、任意の数のバスに接続できます。実際には、これは、どのユーザープロセスもシステムバスと現在のセッションバスに接続できますが、他のユーザーのセッションバスや、同じユーザーが所有する別のセッションバスには接続できないことを意味します。後者の制限は、すべてのユーザーセッションが単一のユーザーバスに統合された場合、将来変更される可能性があります。^[19]

D-Busは、情報共有、モジュール性、権限分離など、アプリケーションに既存の機能を追加または簡素化します。たとえば、BluetoothまたはSkype経由で受信した着信音声通話の情報は、現在実行中の音楽プレーヤーによって伝播および解釈され、通話が終了するまで音量をミュートしたり、再生を一時停止したりして反応することができます。^[20]

D-Bus は、ユーザー アプリケーションのさまざまなコンポーネントを統合するためのフレームワークとしても使用できます。たとえば、オフィス スイートはセッション バスを介して通信し、ワード プロセッサとスプレッドシート間でデータを共有できます。

D-Busのコンテキストでは、バスへのすべての接続はバス名と呼ばれるもので識別されます。^[5]バス名は、ドットで区切られた2つ以上の文字、数字、ダッシュ、アンダースコアの文字列、つまり逆ドメイン名で構成されます。有効なバス名の例はですorg.freedesktop.NetworkManager。^[6]

プロセスがバスへの接続を確立すると、バスはその接続に「ユニーク接続名」と呼ばれる特別なバス名を割り当てます。^{[18] [6]}このタイプのバス名は不変で、接続が存在する限り変更されないことが保証されています。さらに重要なことは、バスの存続期間中に再利用できないことです。^{[5] [18] [6]}つまり、同じプロセスがバスへの接続を閉じて新しい接続を作成したとしても、そのバスへの他の接続にはこのようなユニーク接続名が割り当てられることはありません。ユニーク接続名は、通常は禁止されているコロン文字で始まるため、簡単に認識できます。^{[18] [6]}ユニーク接続名の例は次のとおりです:1.1553（コロンの後の文字には特に意味はありません^[18]）。

プロセスは、その接続に追加のバス名を要求することができます。^[18]ただし、要求された名前がバスへの別の接続で使用されていない場合に限ります。D-Bus の用語では、バス名が接続に割り当てられると、その接続がバス名を所有することになります。 ^{[5] [18]}その意味では、バス名は 2 つの接続で同時に所有することはできませんが、一意の接続名とは異なり、これらの名前は使用可能な場合は再利用できます。つまり、プロセスは、意図的であるかどうかにかかわらず、別のプロセスによって解放されたバス名を再利用できます。^{[5] [6]}

これらの追加のバス名（一般によく知られている名前と呼ばれる）の背後にある考え方は、事前に決められたバス名を使用してサービスを参照する方法を提供することです。^{[18] [6]たとえば、システムバスの現在の時刻と日付を報告するサービスは、それがどのプロセスであるかに関係なく、} org.freedesktop.timedate1バス名を所有する接続を持つプロセスにあります。

バス名は、単一インスタンスアプリケーションを実装する簡単な方法として使用できます（2番目のインスタンスはバス名がすでに使用されていることを検出します）。^[18]また、プロセスの終了によりバス名が解放されるとバスが通知を送信するため、サービスプロセスのライフサイクルを追跡するためにも使用できます。^[18]

D-Bus は、複数のコンポーネント指向通信システムの代替として当初から構想されていたため、クライアントとサービス間の通信のセマンティクスを表現するオブジェクト モデルを先行システムと共有しています。D-Bus オブジェクト モデルで使用される用語は、一部のオブジェクト指向 プログラミング言語で使用される用語を模倣しています。これは、D-Bus が何らかの形で OOP 言語に限定されていることを意味するものではありません。実際、最もよく使用される実装 ( libdbus ) は、手続き型プログラミング言語であるCで記述されています。

D-Bus では、プロセスはオブジェクトを公開することでサービスを提供します。これらのオブジェクトには、呼び出すことができるメソッドと、オブジェクトが発行できるシグナルがあります。 ^[18]メソッドとシグナルは、まとめてオブジェクトのメンバーと呼ばれます。 ^[5]バスに接続されたクライアントは、メソッドを使用したり、要求を行ったり、オブジェクトにアクションを実行するよう命令したりすることで、オブジェクトと対話できます。^[18]たとえば、時間サービスを表すオブジェクトは、現在の日付と時刻を返すメソッドを使用してクライアントから照会できます。クライアントは、通常、基盤となるサービスに関連する特定のイベントによってオブジェクトの状態が変わったときに、オブジェクトが発行するシグナルをリッスンすることもできます。例としては、USB やネットワーク ドライバーなどのハードウェア デバイスを管理するサービスが「新しいハードウェア デバイスが追加されました」というイベントをシグナルする場合が挙げられます。クライアントは、特定のオブジェクトから特定のシグナルを受信することに関心があることをバスに指示する必要があります。D-Bus バスは、シグナルを、そのシグナルに関心があることが登録されているプロセスにのみ渡すためです。^[6]

D-Bus バスに接続されたプロセスは、必要な数の D-Bus オブジェクトをエクスポートするように要求できます。各オブジェクトは、オブジェクト パスによって識別されます。オブジェクト パスは、スラッシュ文字で区切られ、先頭に付けられた数字、文字、およびアンダースコアの文字列で、Unix ファイルシステム パスに似ていることからこの名前が付けられています。^{[5] [18]}オブジェクト パスは要求プロセスによって選択され、そのバス接続のコンテキストで一意である必要があります。有効なオブジェクト パスの例は です/org/kde/kspread/sheets/3/cells/4/5。^[18]ただし、オブジェクト パス内で階層を形成することは強制されませんが、推奨もされません。^[6]サービスのオブジェクトの特定の命名規則は、そのサービスの開発者に完全に委ねられていますが、多くの開発者は、プロジェクトの予約済みドメイン名をプレフィックスとして使用してオブジェクトを名前空間化することを選択します (例: /org/kde )。^[18]

すべてのオブジェクトは、それがエクスポートされた特定のバス接続と密接に関連しており、D-Busの観点からは、そのような接続のコンテキスト内でのみ存在します。したがって、特定のサービスを使用するには、クライアントは、目的のサービスを提供するオブジェクト パスだけでなく、サービス プロセスがバスに接続されているバス名も指定する必要があります。^[5]これにより、バスに接続されている複数のプロセスが、同一のオブジェクト パスを持つ異なるオブジェクトを明確にエクスポートできるようになります。

インターフェースは、オブジェクトで使用できるメンバー（メソッドとシグナル）を指定します。^[18]これは、メソッド（渡すパラメータと返すパラメータを含む）とシグナル（パラメータを含む）の宣言のセットであり、Java言語のインターフェース表記に似たドット区切りの名前で識別されます。^{[18] [6]}有効なインターフェース名の例は ですorg.freedesktop.Introspectable。^[6]類似しているにもかかわらず、インターフェース名とバス名は間違えないようにしてください。 D-Busオブジェクトは複数のインターフェースを実装できますが、少なくとも1つは実装して、それによって定義されたすべてのメソッドとシグナルをサポートする必要があります。 オブジェクトによって実装されるすべてのインターフェースの組み合わせは、オブジェクト型と呼ばれます。^{[5] [18]}

オブジェクトを使用する場合、クライアントプロセスがメンバーの名前に加えてメンバーのインターフェース名を提供するのは良い習慣ですが、これは、オブジェクトによって実装された異なるインターフェースから利用できるメンバー名が重複しているために曖昧さが生じる場合にのみ必須です^{[5] [18]}。それ以外の場合、選択されたメンバーは未定義またはエラーになります。一方、発行されたシグナルは、常にそれがどのインターフェースに属しているかを示す必要があります。

D-Bus仕様では、オブジェクトが自身のインターフェースに加えて実装したい標準インターフェースもいくつか定義されています。^{[17]技術的にはオプションですが、D-Busサービス開発者のほとんどは、イントロスペクションなどの重要な追加機能をD-Busクライアントに提供するため、}エクスポートしたオブジェクトでそれらをサポートすることを選択しています。^[6]これらの標準インターフェースは次のとおりです。^{[17] [6]}

• org.freedesktop.DBus.Peer : D-Bus接続が生きているかどうかをテストする方法を提供します。^[6]
• org.freedesktop.DBus.Introspectable : クライアントプロセスが実行時にオブジェクトが実装するインターフェース、メソッド、シグナルの説明（ XML形式）を取得できるイントロスペクションメカニズムを提供します。 ^{[18] [17]}
• org.freedesktop.DBus.Properties : D-Busオブジェクトが基礎となるネイティブオブジェクトのプロパティや属性を公開したり、存在しない場合はシミュレートしたりできるようにします。^[17]
• org.freedesktop.DBus.ObjectManager : D-Busサービスがオブジェクトを階層的に配置する場合、このインターフェースは、単一のメソッド呼び出しを使用して、パスの下にあるすべてのサブオブジェクトとそのインターフェースおよびプロパティについてオブジェクトを照会する方法を提供します。^[17]

D-Bus 仕様では、org.freedesktop.DBusバス名にある/org/freedesktop/DBusオブジェクトを使用して実行される、いくつかの管理バス操作 (「バス サービス」と呼ばれる) が定義されています。 ^[17]各バスは、この特別なバス名を自分自身のために予約し、このバス名とオブジェクト パスの組み合わせに対して行われた要求を管理します。バスによって提供される管理操作は、オブジェクトのインターフェイスorg.freedesktop.DBusによって定義されます。これらの操作は、たとえば、バスの状態に関する情報を提供するため、^{[5]や、追加の}よく知られているバス名の要求と解放を管理するために使用されます。^{[17] [6]}

D-Bus は、汎用的で高水準のプロセス間通信システムとして考案されました。この目的を達成するために、D-Bus 通信は「生のバイト」ではなくプロセス間のメッセージ交換に基づいています。 ^{[5] [18]} D-Bus メッセージは、プロセスがバスを介して接続された別のプロセスに送信できる高水準の個別項目です。メッセージは明確に定義された構造 (ペイロードで運ばれるデータのタイプも定義されています) を持ち、バスはメッセージを検証し、不適切な形式のメッセージを拒否することができます。この点で、D-Bus は独自のタイプ定義システムと独自のマーシャリングを備えており、従来の IPC メカニズムよりもRPCメカニズムに近いと言えます。^[5]

バスはクライアントとサービスプロセス間のメッセージ交換の2つのモードをサポートしています^[5]。

• 1対1のリクエスト-レスポンス: これは、クライアントがオブジェクトのメソッドを呼び出す方法です。クライアントは、オブジェクトをエクスポートするサービスプロセスにメッセージを送信し、サービスはクライアントプロセスにメッセージで応答します。^[18]クライアントが送信するメッセージには、オブジェクトのパス、呼び出されたメソッドの名前（およびオプションでそのインターフェイスの名前）、およびオブジェクトの選択されたインターフェイスで定義されている入力パラメータの値（ある場合）が含まれている必要があります。応答メッセージには、オブジェクトのメソッド呼び出しによって返された出力パラメータの値、またはエラーがあった場合は例外情報を含む、リクエストの結果が含まれます。 ^{[5] [18]}
• パブリッシュ/サブスクライブ: これは、オブジェクトがシグナルの発生を関係者に通知する方法です。オブジェクトのサービスプロセスは、バスがオブジェクトのシグナルをサブスクライブしている接続されたクライアントにのみ渡すメッセージをブロードキャストします。^[18]メッセージには、オブジェクトパス、シグナルの名前、シグナルが属するインターフェイス、およびシグナルのパラメータの値（存在する場合）が含まれます。通信は一方向です。送信者は受信者のIDも数も知らないため、クライアントプロセスから元のメッセージに対する応答メッセージはありません。^{[5] [18]}

すべての D-Bus メッセージは、ヘッダーと本体から構成されます。^[18]ヘッダーは、メッセージの種類、送信者、およびメッセージを受信者に配信するために必要な情報 (宛先バス名、オブジェクト パス、メソッド名またはシグナル名、インターフェイス名など) を識別するいくつかのフィールドで構成されています。^{[18] [17]}本体には、受信側プロセスが解釈するデータ ペイロード (入力引数または出力引数など) が含まれます。すべてのデータは、ワイヤ形式と呼ばれるよく知られたバイナリ形式でエンコードされます。ワイヤ形式は、整数や浮動小数点数、文字列、複合型などのさまざまな型のシリアル化をサポートしており、 ^[17]マーシャリングとも呼ばれます 。

D-Bus 仕様は、ワイヤ プロトコル ( D-Bus 接続内のプロセス間で交換される D-Bus メッセージの構築方法) を定義します。ただし、これらのメッセージを配信するための基礎となる転送方法は定義していません。

既存のD-Bus実装のほとんどは、リファレンス実装のアーキテクチャに従っています。このアーキテクチャは、2つの主要なコンポーネントで構成されています。^[5]

• 2つのプロセス間でメッセージを交換するためにD-Busワイヤプロトコルを実装したポイントツーポイント通信ライブラリ。リファレンス実装では、このライブラリはlibdbusです。他の実装では、libdbusは別の高レベルライブラリ、言語バインディングによってラップされるか、同じ目的を果たす別のスタンドアロン実装に完全に置き換えられます。^[21]このライブラリは、2つのプロセス間の1対1通信のみをサポートします。^[18]

• 

  バスの役割を果たす特別なデーモンプロセスで、残りのプロセスは任意のD-Busポイントツーポイント通信ライブラリを使用してこのプロセスに接続します。このプロセスは、バスに接続された任意のプロセスから別のプロセスにメッセージをルーティングする役割を担っているため、メッセージバスデーモン^[20]とも呼ばれます。リファレンス実装では、この役割はdbus-daemonによって実行され、それ自体はlibdbus上に構築されています。メッセージバスデーモンの別の実装はdbus-brokerで、これはsd-bus上に構築されています。

libdbusライブラリ（または同等のもの）は、内部的にネイティブの低レベルIPCメカニズムを使用して、D-Bus接続の両端の2つのプロセス間で必要なD-Busメッセージを転送します。D-Bus仕様では、どの特定のIPCトランスポートメカニズムを使用できるかは規定されていません。これは、サポートするトランスポート方法を決定するのは通信ライブラリだからです。たとえば、LinuxなどのUnix系オペレーティングシステムでは、libdbusは通常、基盤となるトランスポート方法としてUnixドメインソケットを使用しますが、 TCPソケットもサポートしています。^{[5] [18]}

両プロセスの通信ライブラリは、選択されたトランスポート方法と、通信に使用される特定のチャネルについて合意する必要があります。この情報は、D-Bus がアドレスと呼ぶもので定義されます。^{[6] [18]} Unix ドメイン ソケットはファイル システムオブジェクトであるため、ファイル名で識別できますunix:path=/tmp/.hiddensocket。したがって、有効なアドレスは になります。 ^{[5] [17]}両プロセスは、それらの間の D-Bus 接続を確立するために、それぞれの通信ライブラリに同じアドレスを渡す必要があります。アドレスは、コンマで区切られたkey=valueペアの形式で通信ライブラリに追加のデータを提供することもできます。^{[6] [17]}この方法により、たとえば、それをサポートする特定の種類の接続に認証情報を提供できます。

dbus-daemon のようなメッセージ バス デーモンを使用して D-Bus バスを実装する場合、バスに接続するすべてのプロセスはバスアドレスを知っている必要があります。バス アドレスは、プロセスが中央のメッセージ バス プロセスへの D-Bus 接続を確立できるアドレスです。^{[5] [18]}このシナリオでは、メッセージ バス デーモンがバス アドレスを選択し、残りのプロセスはその値を対応するlibdbusまたは同等のライブラリに渡す必要があります。dbus -daemon は、提供するバス インスタンスごとに異なるバス アドレスを定義します。これらのアドレスは、デーモンの構成ファイルで定義されます。

2 つのプロセスは D-Bus 接続を使用してそれらの間で直接メッセージを交換できますが^[22]、これは D-Bus の通常の使用方法ではありません。通常の方法は、各プロセスがポイントツーポイントの D-Bus 接続を確立する通信の中心点として、常にメッセージ バス デーモン (つまりdbus-daemon ) を使用することです。プロセス (クライアントまたはサービス) が D-Bus メッセージを送信すると、メッセージ バス プロセスが最初にメッセージを受信し、適切な受信者に配信します。メッセージ バス デーモンは、各メッセージを D-Bus 接続を介して受信者プロセスに繰り返し送信することで、各メッセージを宛先に届けるハブまたはルーターと見なすことができます^[18] 。受信プロセスは、メッセージのヘッダー フィールドの宛先バス名によって決定されます^[17]。または、シグナル伝播メッセージの場合には、メッセージ バス デーモンによって維持されるシグナルへのサブスクリプション情報によって決定されます。^[6]メッセージバスデーモンは、存在しないバス名にメッセージを送信したプロセスへのエラーメッセージなど、特定の条件への応答として独自のメッセージを生成することもできます。^[18]

dbus-daemon は、 D-Bus 自体が既に提供している機能セットに追加機能を追加して改善します。たとえば、サービス アクティベーションでは、必要なときにサービスを自動的に開始できます。つまり、そのサービスのバス名への最初の要求がメッセージ バス デーモンに到着したときです。^[5]この方法では、サービス プロセスは、システム初期化またはユーザー初期化の段階で起動する必要はなく、使用されていないときにメモリやその他のリソースを消費する必要もありません。この機能は、もともとsetuidヘルパーを使用して実装されていましたが、^{[23]現在では}systemdのサービス アクティベーション フレームワークによっても提供できます。 ^[要出典]サービス アクティベーションは、サービスのプロセス ライフサイクルの管理を容易にする重要な機能です (たとえば、デスクトップ コンポーネントを起動または停止するタイミング)。^[18]

D-Busは2002年にHavoc Pennington、Alex Larsson ( Red Hat )、Anders Carlssonによって開始されました。 ^[8] APIが安定していると考えられているバージョン1.0は2006年11月にリリースされました。^{[24] [25]}

KDEのバージョン 2 および 3 で使用されていたDCOPシステムの影響を強く受けた D-Bus は、 KDE 4リリースで DCOP に取って代わりました。^{[25] [26]} D-Bus の実装はほとんどのPOSIXオペレーティングシステムをサポートしており、Windowsへの移植版も存在します。Qt 4で使用され、その後GNOMEでも使用されています。GNOME では、初期のBonoboメカニズムのほとんどの部分を徐々に置き換えてきました。Xfceでも使用されています。

初期の採用者の1つは、（現在では廃止されている）ハードウェア抽象化レイヤーでした。HALは、コンピュータに追加または削除されたハードウェアに関する情報をエクスポートするためにD-Busを使用しました。^[8]

D-Bus の使用は、当初のデスクトップ環境の範囲を超えて、ますます多くのシステム サービスをカバーするように着実に拡大しています。たとえば、NetworkManagerネットワーク デーモン、BlueZ Bluetooth スタック、PulseAudioサウンド サーバーは、D-Bus を使用してサービスの一部またはすべてを提供しています。systemdは、 systemctlと systemd間の通信に D-Bus ワイヤ プロトコルを使用し、またlogindなどの従来のシステム デーモンを D-Bus サービスに昇格させています。^[27] D-Bus のもう 1 つのヘビー ユーザーはPolkitで、そのポリシー権限デーモンはシステム バスに接続されたサービスとして実装されています。^[28]

D-Bus の実装はいくつかあるが、最も広く使われているのは、仕様を設計した同じ freedesktop.org プロジェクトによって開発されたリファレンス実装libdbusである。しかし、libdbus は低レベルの実装であり、アプリケーション開発者が直接使用することを意図したものではなく、D-Bus の他の再実装 (デスクトップ環境の標準ライブラリやプログラミング言語バインディングに含まれるものなど) のリファレンス ガイドとして意図されたものである。freedesktop.org プロジェクト自体は、アプリケーション作成者に「代わりに、より高レベルのバインディングまたは実装のいずれかを使用する」ことを推奨している。^[29]最も使用されている D-Bus 実装として libdbus が優勢であったため、「D-Bus」と「libdbus」という用語がしばしば互換的に使用され、混乱を招いた。^[要出典]

GDBus ^[9]は、 GLibに含まれるGIOストリームに基づくD-Busの実装であり、 GTK+とGNOMEでの使用を目的としています。GDBusはlibdbusのラッパーではなく、D-Bus仕様とプロトコルの完全かつ独立した再実装です。^[30] MATEデスクトップ^[31]とXfce（バージョン4.14）もGTK+ 3に基づいており、GDBusを使用しています。^{[引用が必要]}

2013年に、systemdプロジェクトはlibdbusを書き直してコードを簡素化しましたが、^[32]これにより、D-Bus全体のパフォーマンスが大幅に向上しました。予備的なベンチマークでは、BMWはsystemdのD-Busライブラリによってパフォーマンスが360%向上したことを発見しました。^{[33] 2015年にリリースされた}systemdのバージョン221では、sd-bus APIが安定していると宣言されました。^[34]

kdbusは、 D-Busをカーネルを介したピアツーピアのプロセス間通信メカニズムとして再実装することを目的としたプロジェクトでした。パフォーマンスの向上に加えて、kdbusには、名前空間や監査などの他のLinuxカーネル機能から生じる利点があります。 ^{[33] [37]}カーネルの仲介によるセキュリティ、競合状態の解消、およびD-Busをブート時およびシャットダウン時に使用できるようにする（systemdが必要とする場合）^[38]。kdbusのLinuxカーネルへの組み込みは議論を巻き起こし、^{[39]より一般的な}プロセス間通信であるBUS1に取って代わられました。^[40]

D-Bus用のプログラミング言語バインディングはいくつか開発されており、^[41] Java、C#、Ruby、Rust、Perl用のものなどがある。^[要出典]

• Freedesktop.org の D-Bus ホームページ
• D-Bus仕様
• Freedesktop.org wiki の D-Bus の紹介
• D-Bus チュートリアル
• DBus の概要