Qt高級——D-Bus快速入門

Qt高級——D-Bus快速入門

1、D-Bus簡介

一、D-Bus簡介

D-Bus是Desktop Bus的縮寫，是針對桌面環境優化的IPC(InterProcess Communication)機制，用於進程間的通訊或進程與內核的通訊。
D-Bus是爲Linux系統開發的進程間通訊（IPC）和遠程過程調用（RPC）機制，使用統一的通訊協議來代替現有的各類IPC解決方案。D-Bus容許系統級進程（如：打印機和硬件驅動服務）和普通用戶進程進行通訊。
D-Bus使用一個快速的二進制消息傳遞協議，D-Bus協議的低延遲和低消耗特色適用於同一臺機器的通訊。D-Bus的規範目前由freedesktop.org項目定義，可供全部團體使用。
D-Bus不和低層的IPC直接競爭，好比sockets，shared memory或message queues。低層IPC有本身的特色，和D-Bus並不衝突。
與其餘重量級的進程間通訊技術不一樣，D-Bus是非事務的。D-Bus使用了狀態以及鏈接的概念，比UDP等底層消息傳輸協議更「聰明」。但另外一方面，D-Bus傳送的是離散消息，與TCP協議將數據看作「流」有所不一樣。D-Bus支持點對點的消息傳遞以及廣播/訂閱式的通訊。

二、不一樣IPC通訊方式比較

不一樣IPC通訊機制的特色以下：
A、CORBA是用於面向對象編程中複雜IPC的一個強大的解決方案。
B、Bonobo是一個只用於GNOME的解決方案，基於CORBA並依賴於GObject。
C、DCOP是一個較輕量級的IPC框架，功能較少，但能夠很好地集成到KDE桌面環境中。
D、SOAP和XML-RPC設計用於Web服務，於是使用HTTP做爲其傳輸協議。
E、D-BUS設計用於桌面應用程序和OS通訊。

三、D-Bus特性

A、D-BUS的協議是低延遲並且低開銷的，設計小巧且高效，以便最小化傳送時間。從設計上避免往返交互並容許異步操做。
B、協議是二進制的，而不是文本，排除序列化過程。
C、考慮了字節序問題。
D、易用性：按照消息而不是字節流來工做，而且自動地處理了許多困難的IPC問題，而且D-Bus庫以能夠封裝的方式來設計，開發者可使用框架裏存在的對象/類型系統，而不用學習一種新的專用於IPC的對象/類型系統。
E、請求時啓動服務以及安全策略。
F、支持多語言（C/C++/Java/C#/Python/Ruby），多平臺(Linux/windows/maemo)。
G、採用C語言，而不是C++。
H、因爲基本上不用於internet上的IPC，所以對本地IPC進行了特別優化。
I、提供服務註冊，理論上能夠進行無限擴展。

2、D-Bus架構

一、D-Bus架構簡介

D-Bus是按必定的層次結構實現的，整體上D-Bus分爲三層：
A、接口層——接口層由libdbus庫提供，進程經過libdbus庫使用D-Bus的能力。經過底層庫的接口能夠實現兩個進程之間進行鏈接併發送消息。
B、總線層——由消息總線守護進程(message bus daemon )提供，消息總線守護進程是基於libdbus底層庫的，能夠路由消息。消息總線守護進程負責進程間的消息路由和傳遞，其中包括Linux內核和Linux桌面環境的消息傳遞。
C、封裝層——封裝層是一系列基於特定應用程序框架的Wrapper庫，將D-Bus底層接口封裝成方便用戶使用的通用API。

二、D-Bus接口層

libdbus只支持點對點的通訊，即只支持一進程與另外的一個進程進行通訊。通訊是基於消息的，消息包含頭部和消息體。
libdbus提供C語言的底層API，API是爲了將D-Bus綁定到特定的對象或是語言而設計的，官方文檔中建議不要在應用上直接使用D-Bus的底層接口，推薦使用D-Bus的綁定，如QtDBus、GDBus、dbus-c++等實現。

三、D-Bus總線層

D-Bus總線層由消息總線守護進程(message bus daemon )提供。消息總線守護進程是一個後臺進程，是/usr/bin/dbus-daemon的一個運行實例,  負責消息的轉發，dbus-daemon運行時會調用libdus的庫。應用程序調用特定的應用程序框架的Wrapper庫與dbus-daemon進行通訊。應用程序經過D-Bus與其它進程通訊必須先創建到消息總線守護進程實例的鏈接。
最多見的基於dbus的程序也符合C/S結構。好比開發兩個程序A和B，其中A是客戶端，B是服務端。假設A要調用B的一個函數func，那麼實際的消息流動方向是：A告訴dbus-daemon請求要調用B的func函數，而後dbus-daemon去調用B的func函數，若是func有返回值的話，B會把返回值告訴dbus-daemon，而後dbus- daemon再把返回值告訴A。若是B進程尚未啓動，則dbus-daemon會自動的先把B進程啓動起來。
一般狀況下，Linux會有兩個dbus-daemon進程，一個屬於system，一個屬於session，在用戶登陸的時候由dbus-launch啓動。
大多數普通程序，都是使用session的dbus-daemon，默認狀況下，A就是將消息發給屬於session的dbus-daemon。
dbus-daemon是有地址的，環境變量DBUS_SESSION_BUS_ADDRESS用於表示當前登陸用戶的session的dbus-daemon進程的地址，可使用echo $DBUS_SESSION_BUS_ADDRESS查看。

當用戶登陸進桌面環境的時候，系統啓動腳本會調用到dbus-launch來啓動一個dbus-daemon進程，同時會把啓動的dbus-daemon地址賦予環境變量DBUS_SESSION_BUS_ADDRESS。
通常狀況下，不須要考慮DBUS_SESSION_BUS_ADDRESS，但某些時候，單獨啓動一個dbus-daemon有助於程序的調試。
利用dbus-daemon自啓動機制運行的服務進程，都是後臺進程，標準輸出設備已經被重定向，若是B進程有一些調試用的打印信息輸出，則很難直接查看。此時，能夠單獨啓動一個dbus-daemon，讓A和B都使用本身啓動的dbus-daemon，此時，dbus-daemon能把B的打印信息顯示出來。
先在終端下啓動一個dbus-daemon，命令以下形式以下：
     DBUS_VERBOSE=1 dbus-daemon --session --print-address
如此啓動的dbus-daemon會前臺執行，而且打印出地址。

而後，在執行A程序的時候，設置環境變量DBUS_SESSION_BUS_ADDRESS爲剛纔獲得的地址值。
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-7MlJMxxGnW,guid=437c0e6060516670cfccacc15afc43c6 ./A
此時運行程序A和B，使用本身啓動的dbus-daemon來轉發消息，而且會把B的打印信息顯示出來。
消息總線守護進程是一個特殊的進程，用於管理系統內的總線，能夠將一個進程的消息路由給另一個進程。若是有不少應用程序鏈接到消息總線守護進程的總線上，總線能把消息路由到對應的一個或多個進程中去。所以在總線層上，實現了點對點通訊的支持，也實現了廣播/訂閱通訊方式。
在最底層，D-Bus只支持點對點的通訊，通常使用本地套接字(AF_UNIX)在應用和消息總線守護進程之間通訊。D-Bus的點對點是通過bus daemon抽象過的，由bus daemon來完成尋址和發送消息，所以每一個應用沒必要關心要把消息發給哪一個進程。D-Bus發送消息一般包含以下步驟：
A、應用程序建立和發送消息給消息總線守護進程。
B、消息總線守護進程對收到的消息進行分發處理。
C、目標程序接收到消息，而後根據消息的種類，作不一樣的響應：確認、應答、忽略。
總線是D-Bus的進程間通訊機制，一個系統中一般存在多條總線，總線由D-Bus總線守護進程管理。
最重要的總線爲系統總線（System Bus），Linux內核引導時，系統總線就已被裝入內存。只有Linux內核、Linux桌面環境和權限較高的程序才能向系統總線寫入消息，以此保障系統安全性，防止有惡意進程假冒Linux發送消息。
會話總線（Session Buses）由普通進程建立，可同時存在多條。會話總線屬於某個進程私有，用於進程間傳遞消息。

四、D-Bus封裝層

D-Bus封裝層是將libdbus底層API綁定到特定的對象系統或是語言中，將不便使用的libdbus底層API封裝成能夠在應用層使用的高級API，如libdbus-glib、libdbus-qt等。
D-Bus在不少不一樣的編程語言上都有其接口實現。不一樣語言的接口封裝了D-Bus低級API，提供了更符合編程語言的語法結構。
實現D-Bus接口的語言正在逐漸增長。在C語言中，有最底層的API，但其實現及使用上很是複雜。C語言中另外一個實用化的實現基於GLib。在Java、Perl、Python等都有D-Bus接口實現。

3、D-Bus術語

一、D-Bus術語簡介

總線是消息總線守護進程(message bus daemon)的運行實例，每一個總線都有一個地址，應用進程就是經過總線地址和相應的總線鏈接的。總線上的每個鏈接都有一個鏈接名，鏈接名也稱bus name。每一個鏈接上有至少一個對象，一般有多個對象，對象使用對象路徑惟一標識。對象要實現一個或多個接口，每一個接口包含一組方法和信號。

二、總線（Bus）

在D-Bus中，總線(bus)是核心的概念：不一樣的程序能夠經過總線進行某些操做，好比方法調用、發送信號和監聽特定的信號。總線一般有兩種，系統總線(system bus)和用戶總線(session bus)，系統總線一般只有一條，用戶總線在用戶登陸時建立。
系統總線是一個持久的總線，在系統啓動時就建立，供系統內核和後臺進程使用，具備較高的安全性。系統總線最經常使用是發送系統消息，好比：插入一個新的存儲設備、有新的網絡鏈接等。
會話總線是在某個用戶登陸後啓動，屬於某個用戶私有，是某用戶的應用程序用來通話的通道。在不少嵌入式系統中，只有一個用戶ID登陸運行，所以只有一個會話總線。
一條消息總線就是一個消息路由器，是消息總線守護進程(message bus daemon)的一個實例。

三、地址(Address)

使用d-bus的應用程序既能夠是server端也能夠是client端，server端監聽到來的鏈接，client端鏈接到server端，一旦鏈接創建，消息就能夠流轉。若是使用dbus daemon，全部的應用程序都是client端，dbus daemon監聽全部的鏈接，應用程序初始化鏈接到dbus daemon。
每一條總線都有一個地址，進程經過總線的地址鏈接到總線上。一個D-Bus的地址是指server端用於監聽，client端將要鏈接的地方，例如unix:path=/tmp/abcedf標識server端將在路徑/tmp/abcedf的UNIX domain socket監聽，client端將要鏈接到這個地址。地址能夠是指定的TCP/IP socket或者其餘在或者將在D-Bus協議中定義的傳輸方式。
若是使用bus daemon，libdbus將經過讀取環境變量DBUS_SESSION_BUS_ADDRESS自動獲取session bus damon的地址，經過檢查一個指定的UNIX domain socket路徑獲取system bus的地址。
若是使用D-bus，但不是daemon，須要定義哪一個應用是server端，哪一個是client端，並定義一套機制用於承認server端的地址。

四、鏈接名(Bus Name)

總線上的每一個鏈接都有一個或多個名字。當鏈接創建之後，D-Bus 服務會分配一個不可改變的鏈接名，稱爲惟一鏈接名(unique connection name)，惟一鏈接名即便在進程結束後也不會再被其餘進程所使用。惟一鏈接名以冒號開頭，如「:34-907」。但惟一鏈接名老是臨時分配，沒法肯定，也難以記憶，所以應用能夠要求有另一個名字公共名(well-known name)來對應惟一鏈接名。例如可使用「com.mycompany」來映射「:34-907」。應用程序可能會要求擁有額外的公共名(well-known name)。例如，能夠寫一個規範來定義一個名字叫作 com.mycompany.TextEditor。協議能夠指定本身擁有名字爲com.mycompany.TextEditor的鏈接，一個路徑爲/com/mycompany/TextFileManager的對象，對象擁有接口org.freedesktop.FileHandler。應用程序就能夠發送消息到總線上的鏈接名字，對象和接口以執行方法調用。
鏈接名能夠用於跟蹤應用程序的生命週期。當應用退出（或者崩潰）時，與總線的鏈接將被OS內核關掉，總線將會發送通知，告訴剩餘的應用程序。

五、對象和對象路徑(Object and Object Path)

D-Bus的對象和麪向對象語言中的對象含義是不一樣的，D-Bus的對象表示的是D-Bus通道中信息流向的端點。對象由客戶進程建立，並在鏈接進程中保持不變。
全部使用D-BUS的應用程序都包含一些對象, 當經由一個D-BUS鏈接收到一條消息時，消息是被髮往一個對象而不是整個應用程序。應用程序框架中定義了這樣的對象，如GObject，QObject等，在D-Bus中稱爲原生對象（native object）。
對於底層的D-Bus協議，即libdbus API，並不理會原生對象，使用對象路徑(object path)的概念。經過對象路徑，高層API接口能夠綁定到對象，容許遠程應用指向對象。對象路徑如同文件系統路徑，例如一個對象可能叫作「/org/kde/kspread/sheets/3/cells/4/5」。
對象路徑在全局（session或者system）是惟一的，用於消息的路由。

六、接口（Interface）

每個對象支持一個或者多個接口，接口是一組方法和信號的集和，接口定義一個對象實體的類型。D-Bus對接口的命名方式，相似org.freedesktop.Introspectable。開發人員一般使用編程語言名字做爲接口名字。

七、方法(Methods)

每個對象有兩類成員：方法和信號。方法是一段函數代碼，帶有輸入和輸出；信號是廣播給全部興趣的其餘實體，信號能夠帶有數據payload。
客戶向某對象發送一個請求，即對象被請求執行一個明確的、有名稱的動做。若是客戶請求執行一個目標對象未提供的方法，將會產生一個錯誤。方法的定義能夠支持輸入參數。對於每一個請求，都有一個包含請求結果以及結果數據(輸出參數)的響應返回給請求者。當請求沒法完成時，響應中將包含異常信息，其中至少有異常名稱以及錯誤信息。
大多數語言都將這些封裝在自身的語言機制中，好比將參數包裝進消息包，將異常信息轉換成語言自身的異常等等。在這些實現中，向遠程對象傳遞一個字符串參數就好像是在本地執行一個字符串參數的函數同樣簡單。此時再也不須要數據類型轉換、數據複製等繁瑣工做，語言自己封裝了一切底層實現。

八、信號(Signals)

信號依然聽從面向對象概念，信號是從對象發出但沒有特定目的地址的單向數據廣播。客戶進程能夠預先註冊其感興趣的信號，如特定名稱的信號或從某個對象發出的信號等。當對象發出信號後，全部訂閱了該信號的客戶進程將收到此信號的複本。接收端可能有多種狀況出現，或者有一個客戶進程，或者有多個客戶進程，或者根本沒有客戶進程對這個信號感興趣。對於信號來講沒有響應消息，發出信號的對象不會知道是否是有客戶進程在接收，有多少客戶進程接收，以及從客戶進程收到任何反饋。
信號能夠有參數。但信號是單向通訊，所以不可能像方法同樣具備輸入輸出參數。D-Bus容許客戶進程經過參數比對過濾其須要的信號。
信號通常用來廣播一些客戶可能會感興趣的事件，好比某個其它的客戶進程與總線的鏈接斷開等。這些信號來自總線對象，所以從信號中客戶進程能夠分辨斷線是因爲正常退出、被殺掉或者程序崩潰。

九、代理(Proxies)

代理對象用來表示其餘的remote object。當觸發了proxy對象的method時，將會在D-Bus上發送一個method_call的消息，並等待答覆，根據答覆返回。
總線上的對象通常經過代理來訪問。總線上的對象位於客戶進程之外，而客戶能夠調用本地接口與對象通訊，此時，本地接口充當了代理的角色。當觸發了代理對象的方法時，將會在D-Bus上發送一個method_call的消息，並等待答覆返回，就象使用一個本地對象同樣。
一些語言的代理支持「斷線重連」。好比所鏈接的對象在某段時間裏暫時斷開了與總線的鏈接，代理會自動重連到相同的鏈接名並從新找到對象，程序甚至不會知道目標對象有段時間不可用。並非全部的語言都支持這一特性，在GLib中的兩種代理中的一種支持。
好比不用代理時的代碼以下：

Message message = new Message("/remote/object/path", "MethodName", arg1, arg2); 
Connection connection = getBusConnection();           
connection.send(message);           
Message reply = connection.waitForReply(message);           
if (reply.isError()) {                         
}
 else {              
Object returnValue = reply.getReturnValue();           
}

採用代理時對應的代碼則是：

Proxy proxy = new Proxy(getBusConnection(), "/remote/object/path");           
Object returnValue = proxy.MethodName(arg1, arg2);

十、服務

服務是 D-BUS 的最高層次抽象，服務的實現當前還在不斷髮展變化。應用程序能夠經過一個總線來註冊一個服務，若是成功，則應用程序就已經得到了服務。其餘應用程序能夠檢查在總線上是否已經存在一個特定的服務，若是沒有能夠要求總線啓動它。
服務是 D-BUS 的最高層次抽象，服務的實現當前還在不斷髮展變化。應用程序能夠經過一個總線來註冊一個服務，若是成功，則應用程序就已經得到了服務。其餘應用程序能夠檢查在總線上是否已經存在一個特定的服務，若是沒有能夠要求總線啓動它。
當經過總線進行通訊時，應用程序會獲取服務名稱。服務名稱是應用程序如何選擇同一總線上的其餘應用程序的依據。服務名稱由總線守護進程進行代理，用於將消息從一個應用程序路由到另外一個應用程序。服務名稱的相似概念是IP地址和主機名：計算機一般具備一個IP地址，而且根據其向網絡提供的服務，能夠具備與之相關聯的一個或多個主機名。
另外一方面，若是不使用總線，服務名稱也不會使用。若是再將它與計算機網絡進行比較，這將等同於點到點網絡：由於對等方是已知的，因此不須要使用主機名來查找它或它的IP地址。
總線服務名稱的格式實際上與主機名很是類似：它是字母和數字的點分隔序列。常見的作法是根據服務定義的組織的域名來命名本身的服務名稱。例如，D-Bus服務由freedesktop.org定義，可使用org.freedesktop.DBus服務名稱在總線上找到它。

4、消息和消息總線

一、消息簡介

D-Bus通訊機制是經過進程間發送消息實現的，最基本的D-Bus協議是一對一的通訊協議。與socket通訊不一樣，D-Bus是面向消息的協議。但若是使用高層的綁定接口，不會直接接觸到D-Bus的消息。
D-Bus 有四種類型的消息：
A、method_call方法調用
B、method_return方法返回
C、error錯誤
D、signal信號
代理中的遠程對象調用涉及到了消息總線以及method_call和method_return兩類消息。
消息有消息頭(header)和消息體(body)。消息頭包含消息體的路由信息，消息體是淨荷，一般包含的是參數。消息頭一般包含發送進程的鏈接名(Bus Name)、方法或者信號名等等，其中有一字段是用於描述消息體中的參數的類型的，例如「i」標識32位整數，「ii」表示2個32位整數。

二、調用method的流程

進程A要調用進程B的一個method，進程A發送method_call消息到進程B，進程B回覆method_return消息。在發送消息時，發送方會在消息中添加不一樣的序列號，一樣，回覆消息中也會含有序列號，以便對應。
調用method的流程以下：
A、在發送method_call消息時，若是使用了代理，進程A要調用進程B的某方法，不用構造method_call消息，只需調用代理的本地方法，代理會自動生成method_call消息發送到消息總線上。
B、若是使用底層API，進程A須要構造一個method_call消息。method_call消息包含對應進程B的鏈接名、方法名、方法所需參數、進程B中的對象路徑和進程B中聲明此方法的接口。
C、將method_call消息發送到消息總線上。
D、信息總線檢查消息頭中的目的鏈接名，當找到一個進程與此鏈接名對應時發送消息到該進程。當找不到一個進程與此鏈接名對應時，返回給進程A一個error消息。
E、進程B解析消息，若是是採用底層API方式，則直接調用方法，而後發宋應答消息到消息總線。若是是D-BUs高級API接口，會先檢測對象路徑、接口、方法名稱，而後把消息轉換成對應的本地對象（如GObject，QT中的QObject等）的方法，調用本地對象方法後再將應答結果轉換成應答消息發給消息總線。
F、消息總線接收到method_return消息，將把method_return消息直接發給發出調用消息的進程。
消息總線不會對總線上的消息進行重排序。若是發送了兩條消息到同一個進程，將按照發送順序接收到。接收進程不須要按照順序發出應答消息，例如在多線程中處理這些消息，應答消息的發出是沒有順序的。消息都有一個序列號能夠與應答消息進行配對。

三、發送signal的流程

發送信號是單向廣播的，信號的發送者不知道對信號做響應的有哪些進程，因此信號發送是沒有返回值的。信號接收者經過向消息總線註冊匹配規則來表示對某信號感興趣，而匹配規則一般包含信號的發出者和信號名。
信號發送的流程以下：
A、當使用dbus底層接口時，信號須要應用進程本身建立和發送到消息總線；使用dbus高層API接口時，可使用相關對象進行發送。信號消息包含有聲明信號的接口名、信號名、所在進程對應的鏈接名和相關參數。
B、鏈接到消息總線上的進程若是對某個信號感興趣，則註冊相應的匹配規則。消息總線保持有匹配規則表。
C、消息總線根據匹配規則表，將信號發送到對信號感興趣的進程。
D、每一個進程收到信號後，若是使用dbus高級API接口，能夠選擇觸發代理對象上的信號。若是使用dbus底層接口，須要檢查發送者名稱和信號名稱，而後決定怎麼作。

四、DBus工具

D-Bus提供了兩個小工具：dbus-send 和dbus-monitor。能夠用dbus-send發送消息，用dbus-monitor監視通道上流動的消息。
dbus-send
用於發送一個消息到消息通道上，使用格式以下：

dbus-send [--system | --session] --type=TYPE --print-reply --dest=鏈接名對象路徑接口名.方法名參數類型:參數值參數類型:參數值
dbus-send --session --type=method_call --print-reply --dest=鏈接名對象路徑接口名.方法名 參數類型:參數值 參數類型:參數值

dbus-send支持的參數類型包括：string, int32, uint32, double, byte, boolean。
dbus-monitor
用於打印消息通道上的消息，使用格式以下：

dbus-monitor [--system | --session | --address ADDRESS] [--profile | --monitor] [watch expressions]
dbus-monitor "type='signal', sender='org.gnome.TypingMonitor', interface='org.gnome.TypingMonitor'"

五、消息總線上的方法和信號

消息總線是一個特殊的應用，主要關於消息總線上的方法和信號。
A、Introspection
消息總線上有一個接口org.freedesktop.DBus.Introspectable，接口中聲明瞭一個方法Introspect，不帶參數，將返回一個XML string，XML字符串描述接口、方法、信號。
B、消息總線上的方法和信號
能夠經過向名稱爲「org.freedesktop.DBus」的鏈接上的對象「/」發送消息來調用消息總線提供的方法。消息總線對象支持標準接口"org.freedesktop.DBus.Introspectable"，能夠調用org.freedesktop.DBus.Introspectable.Introspect方法查看消息總線對象支持的接口。
dbus-send --session --type=method_call --print-reply --dest=org.freedesktop.DBus / org.freedesktop.DBus.Introspectable.Introspect
用戶總線對象支持標準接口「org.freedesktop.DBus.Introspectable」和接口 「org.freedesktop.DBus」。接口「org.freedesktop.DBus」有18個方法和3個信號。

<interface name="org.freedesktop.DBus">
    <method name="Hello">
      <arg direction="out" type="s"/>
    </method>
    <method name="RequestName">
      <arg direction="in" type="s"/>
      <arg direction="in" type="u"/>
      <arg direction="out" type="u"/>
    </method>
    <method name="ReleaseName">
      <arg direction="in" type="s"/>
      <arg direction="out" type="u"/>
    </method>
    <method name="StartServiceByName">
      <arg direction="in" type="s"/>
      <arg direction="in" type="u"/>
      <arg direction="out" type="u"/>
    </method>
    <method name="UpdateActivationEnvironment">
      <arg direction="in" type="a{ss}"/>
    </method>
    <method name="NameHasOwner">
      <arg direction="in" type="s"/>
      <arg direction="out" type="b"/>
    </method>
    <method name="ListNames">
      <arg direction="out" type="as"/>
    </method>
    <method name="ListActivatableNames">
      <arg direction="out" type="as"/>
    </method>
    <method name="AddMatch">
      <arg direction="in" type="s"/>
    </method>
    <method name="RemoveMatch">
      <arg direction="in" type="s"/>
    </method>
    <method name="GetNameOwner">
      <arg direction="in" type="s"/>
      <arg direction="out" type="s"/>
    </method>
    <method name="ListQueuedOwners">
      <arg direction="in" type="s"/>
      <arg direction="out" type="as"/>
    </method>
    <method name="GetConnectionUnixUser">
      <arg direction="in" type="s"/>
      <arg direction="out" type="u"/>
    </method>
    <method name="GetConnectionUnixProcessID">
      <arg direction="in" type="s"/>
      <arg direction="out" type="u"/>
    </method>
    <method name="GetAdtAuditSessionData">
      <arg direction="in" type="s"/>
      <arg direction="out" type="ay"/>
    </method>
    <method name="GetConnectionSELinuxSecurityContext">
      <arg direction="in" type="s"/>
      <arg direction="out" type="ay"/>
    </method>
    <method name="ReloadConfig">
    </method>
    <method name="GetId">
      <arg direction="out" type="s"/>
    </method>
    <signal name="NameOwnerChanged">
      <arg type="s"/>
      <arg type="s"/>
      <arg type="s"/>
    </signal>
    <signal name="NameLost">
      <arg type="s"/>
    </signal>
    <signal name="NameAcquired">
      <arg type="s"/>
    </signal>
  </interface>
  <interface name="org.freedesktop.DBus.Introspectable">
    <method name="Introspect">
      <arg direction="out" type="s"/>
    </method>
  </interface>