Разбираемся с D-BUS
Прикладные программы, ядро операционной системы и даже ваш мобильный телефон могут информировать вас о наступивших событиях, что позволит вам использовать ваш компьютер с максимальным удобством. В этой статье рассказывается о том, как работает D-BUS и как приложения могут использовать эту систему.
D-BUS представляет собой систему межпроцессного взаимодействия (IPC), предоставляющую простой и мощный механизм, с помощью которого приложения могут обмениваться друг с другом информацией и инициировать запросы служб. Система D-BUS была спроектирована с нуля в условиях необходимости удовлетворения запросов современных Linux-систем. Главной задачей D-BUS является замена таких систем удаленных вызовов объектов, как CORBA и DCOP, используемых в GNOME и KDE соответственно. В идеальном случае, система D-BUS может стать унифицированной и гибкой системой межпроцессного взаимодействия для обоих вышеупомянутых окружений рабочего стола, удовлетворяющей их нуждам и используемой для реализации новых возможностей.
Почему система D-BUS уникальна
Система D-BUS отлична от других систем межпроцессного взаимодействия по ряду причин. Во-первых, основной единицей межпроцессного взаимодействия в D-BUS является сообщение, а не поток данных. Таким образом, D-BUS разделяет данные взаимодействующих приложений на отдельные сообщения, состоящие из заголовков (метаданных) и полезной нагрузки (данных). Сообщений находятся в бинарном, типизированном, полностью выровненном и простом формате. Эта часть протокола унаследована из сетевых протоколов обмена данными. Этот подход резко отличается от подхода, используемого в других системах межпроцессного взаимодействия, где в подавляющем большинстве используются различные байтовые потоки, а не отдельные сообщения.
Во-вторых, в основе D-BUS лежит понятие шины. Простейшей формой взаимодействия процессов является передача данных от процесса к процессу. Тем не менее, D-BUS предоставляет системную службу, известную как служба системной шины сообщений, которая перенаправляет сообщения между процессами, работающими с конкретной шиной. Таким образом реализуется топология шины, позволяющая процессам передавать сообщения одному или нескольким приложениям одновременно. Приложения могут отправлять или ожидать приема различных событий на шине.
Последней уникальной возможностью является создание не одной, а сразу двух таких шин: шины системы и шины сессии. Шина системы является глобальной шиной, работающей на уровне системы. Все пользователи системы, имеющие соответствующие права, могут использовать эту шину, что вводит концепцию общесистемных событий. Шина сессии создается во время входа пользователя в систему и работает на уровне пользователя или сессии. Эта шина используется исключительно определенным пользователем в рамках определенной сессии как система межпроцессного взаимодействия и удаленного вызова объектов для пользовательских приложений.
Концепции D-BUS
Сообщения отправляются объектам. Адресация объектов производится при помощи путей, таких как /org/cups/printers/queue. Процессы, работающие с шинами, ассоциируются с объектами и реализуют интерфейсы этих объектов.
D-BUS поддерживает множество типов сообщений, таких как: сигналы, вызовы методов, возврат результатов вызовов методов и сообщения об ошибках. Под сигналами понимаются уведомления о наступлении определенных событий. Они являются простыми, асинхронными односторонними сообщениями. Сообщения с вызовами методов позволяют приложению отправить запрос на вызов метода удаленного объекта. Сообщения, возвращающие результат вызова методов, предоставляют значение, которое было возвращено в результате вызова метода. Сообщения об ошибках позволяют обрабатывать исключения в результате вызова методов.
В системе D-BUS используется полная типизация и возможно безопасное использование типов. И заголовок сообщения и полезные данные полностью типизированы. Поддерживаемые типы данных: байты (byte), булевые значения (Boolean), 32-битные целочисленные значения (32-bit integer), 32-битные беззнаковые целочисленные значения (32-bit unsigned integer), 64-битные целочисленные значения (64-bit integer), 64-битные беззнаковые целочисленные значения (64-bit unsigned integer), числа с плавающей точкой двойной точности (double-precision floating point) и строки(string). Специальный тип массива (array) позволяет группировать эти значения. Тип словаря (DICT) позволяет создавать пары ключ/значение.
Система D-BUS безопасна. Она реализует простой протокол, основанный на профилях SASL для аутентификации соединений приложений один-на-один. На уровне шин чтение и запись сообщений со стороны определенного интерфейса контролируется системой безопасности. Администратор может контролировать доступ любого интерфейса к шине. Служба D-BUS изначально проектировалась с учетом системы безопасности.
Почему следует использовать D-BUS
Все вышесказанное здорово звучит, но в чем же преимущества? Во-первых, концепция системной шины является нововведением. Одна шина, доступная всем компонентам системы, позволяет распространять сообщения начиная от событий ядра (смотрите раздел «Уровень событий ядра») и заканчивая высокоуровневыми приложениями в рамках системы. Linux со своими хорошо спроектированными интерфейсами и четко разделенными уровнями систем, не имел хорошей системы интеграции. Шина системы D-BUS улучшает интеграцию системных компонентов без нарушения хорошо зарекомендовавших себя правил разработки. Теперь такие события, как заполнение жесткого диска или опустошение очереди печати или даже разрядка батареи ноутбука могут сопровождаться всплывающей подсказкой в системном трее и событием, доступным заинтересованным в нем приложениям, позволяющим системе ответить и отреагировать на него соответствующим образом. Сигналы отправляются асинхронно без необходимости постоянной проверки доступности новых событий.
Уровень событий ядра
Под уровнем событий ядра понимается механизм обмена сообщениями между пространствами ядра и пользователя, реализуемый при помощи высокоскоростного netlink-сокета. Этот механизм связан с системой D-BUS и позволяет ядру генерировать сигналы D-BUS!
Уровень событий ядра связан с файловой системой sysfs, являющейся отображением внутренних объектов ядра (kobjects) и расположенной в /sysfs в современных дистрибутивах Linux. Каждая директория sysfs связана с объектом ядра (kobject), являющимся структурой ядра, предназначенной для внутреннего представления объектов; sysfs является иерархией объектов, экспортируемой из ядра в виде файловой системы.
Каждое событие уровня событий ядра моделируется таким образом, что в качестве инициатора приводится путь в файловой системе sysfs. Таким образом, события выглядят как инициированные объектами ядра. Пути из файловой системы sysfs легко приводятся к путям объектов D-BUS, связывая уровень событий ядра и систему D-BUS естественным образом. Уровень событий ядра был впервые представлен в ядре версии 2.6.10-rc1.
Во-вторых, шина сессий предоставляет механизмы межпроцессного взаимодействия и удаленного вызова процедур, предоставляя в перспективе унифицированную систему для GNOME и KDE. Целью D-BUS является создание системы с функциями CORBA, лучшей чем CORBA и системы с функциями DCOP, лучшей чем DCOP, удовлетворяя требованиям обоих проектов и в то же время, предоставляя дополнительные возможности.
К тому же, D-BUS обладает этими возможностями, оставаясь простой и эффективной системой.
Добавление поддержки D-BUS в ваши приложения
Основа системы D-BUS разработана на языке программирования C и ее API является обширным и довольно низкоуровневым. Существуют высокоуровневые API, используемые поверх этого API для различных языков программирования и компонентов, включая Glib, Python, Qt и Mono. Наряду с предоставлением API для различных языков программирования, высокоуровневые API предоставляют и поддержку функций, специфических для отдельных системных компонентов. Например, API для Glib представляют соединения D-BUS как объекты GObject и позволяют отправку сообщений для интеграции в цикл приема событий (Glib mainloop). Предпочтительным методом использования D-BUS в программе является использование высокоуровневых API для выбранного языка программирования и программного компонента для достижения удобства использования и повышения функциональности.
Давайте рассмотрим простейшие примеры использования D-BUS в ваших приложениях. Сначала рассмотрим API для языка C, затем перейдем к рассмотрению кода с использованием интерфейса Glib.
Использование API D-BUS для языка C
Этот код отправляет сигнал «Feathers» с адреса org.pirate.parrot.attr с полезной нагрузкой в виде двух полей, каждое из которых является строкой: «Shiny» и «Well Groomed». Любое приложение, работающее с системной шиной сообщений, с достаточными правами может выбрать эту службу и принять сигнал.
Интерфейс Glib
В этом примере мы присоединились к шине пользователя. Этот вызов связывает соединение с циклом событий Glib, позволяя совершать операции ввода/вывода вместе с работой с сообщениями D-BUS.
Функция Peel принимает дин параметр в виде целого числа. Если метод возвратит значение, отличное от нуля, он корректно завершился и в переменной ret содержится значение, возвращенное этой функцией. Типы данных, которые принимает определенный метод, описываются при реализации метода. Например, мы не передавали тип DBUS_TYPE_STRING вместо типа DBUS_TYPE_INT32.
Главным преимуществом использования высокоуровневых API является интеграция в цикл приема событий, позволяющая разработчикам обрабатывать различные сообщения D-BUS вместе с операциями ввода-вывода и событиями пользовательского интерфейса. Заголовочный файл описывает ряд функций для интеграции D-BUS в цикл приема событий Glib.
Заключение
D-BUS является мощной и простой системой межпроцессного взаимодействия, которая с успехом улучшит интеграцию и расширит функциональность Linux-систем. Пользователи рано или поздно столкнутся со все большим количеством приложений, использующих D-BUS. Имея на руках эту статью, есть все основания рассматривать D-BUS не как ужасную зависимость, а как блестящую особенность системы. На интернет-ресурсах можно найти ряд примеров программ, использующих D-BUS. Разработчики со временем будут вынуждены добавлять поддержку D-BUS в свои приложения. Также существует ряд сайтов с описанием возможностей и примерами использования D-BUS. Конечно же, лучшим справочным материалом является исходный код, и, к счастью, его сейчас очень много.
Перевод вводной статьи от разработчиков D-Bus
Руководство по D-BUS
https://dbus.freedesktop.org/doc/dbus-tutorial.html, Red Hat, Inc
Дэвид Уиллер, Джон Палмиери, Red Hat, Inc.
Колин Уолтерс, Red Hat, Inc.
Перевод Пластов И.В., plastov.igor@yandex.ru
Документ в процессе разработки
Это руководство не завершено. Оно, вероятно, содержит некоторую полезную информацию, но также имеет много пробелов. Прямо сейчас вам также необходимо обратиться к спецификации D-Bus, справочной документации Doxygen и посмотреть несколько примеров того, как другие приложения используют D-Bus.
Что такое D-Bus?
Библиотека libdbus, которая позволяет двум приложениям подключаться друг к другу и обмениваться сообщениями.
Исполняемый файл демона шины сообщений, построенный на libdbus, к которому могут подключаться несколько приложений. Демон может направлять сообщения от одного приложения к нулю или нескольким другим приложениям.
Библиотеки враперов или привязок основанных на частичном применении конкретных фреймворков. Например, libdbus-glib и libdbus-qt. Также существуют привязки к таким языкам, как Python. Эти библиотеки-враперы представляют собой API-интерфейс, который следует использовать большинству людей, поскольку это упрощают детали программирования D-Bus. libdbus предназначена для низкоуровневого бэкенда в привязках более высокого уровня. Большая часть API libdbus полезна только для реализации привязок.
Библиотека libdbus поддерживает только соединения точка-точка, подобно raw-сокету. Однако, вместо отправки по соединению потока байтов, вы отправляете сообщения. Сообщения имеют заголовок, определяющий его тип и тело, содержащее полезные данные. libdbus также абстрагирует конкретно используемый транспорт (сокеты или что-то еще) и обрабатывает такие детали, как аутентификация.
Демон шины сообщений образует ступицу колеса. Каждая спица колеса представляет собой соединение точка-точка с приложением, использующим libdbus. Приложение отправляет сообщение демону шины по своей спице, а демон шины пересылает сообщение другим подключенным приложениям, если это необходимо. Представляйте демон как маршрутизатор.
Общесистемный и индивидуальные демоны разделены. Обычный внутрисессионный IPC не использует шину сообщений общесистемного процесса, и наоборот.
Применения D-Bus
Связь между настольными приложениями в одном рабочем столе; для обеспечения интеграции сеанса рабочего стола в целом и решения проблем жизненного цикла процесса (когда компоненты рабочего стола запускаются и останавливаются).
Связь между сеансом рабочего стола и операционной системой, где операционная система обычно включает ядро и любые системные демоны или процессы.
Для случая использования в рамках сеанса рабочего стола рабочие столы GNOME и KDE имеют значительный предыдущий опыт работы с различными решениями IPC, такими как CORBA и DCOP. D-Bus основан на этом опыте и тщательно адаптирован для удовлетворения потребностей, в частности, таких настольных проектов. D-Bus может подходить или не подходить для других приложений; в FAQ есть некоторые сравнения с другими системами IPC.
Проблема, решаемая общесистемным случаем или случаем связи с ОС, хорошо объясняется следующим текстом из проекта Linux Hotplug:
Пробел в текущей поддержке Linux заключается в том, что в настоящее время не поддерживаются политики с каким-либо динамическим компонентом «взаимодействия с пользователем». Например, это часто требуется при первом подключении сетевого адаптера или принтера, а также для определения подходящих мест для монтирования дисков. Казалось бы, такие действия могут поддерживаться в любом случае, когда можно идентифицировать ответственного человека: однопользовательские рабочие станции или любая система, которая администрируется удаленно.
Это классическая проблема «удаленного системного администратора», когда в случае горячего подключения должно доставляться событие из его домена безопасности (в данном случае ядра операционной системы) в другой (рабочий стол для вошедшего в систему пользователя или удаленного системного администратора). Любой эффективный ответ должен идти другим путем: удаленный домен предпринимает действия, позволяющие ядру выяснить возможности устройства. (Действие часто может быть выполнено асинхронно, например, позволяя новому оборудованию бездействовать до завершения переговоров.) На момент написания этой статьи в Linux не было широко распространенных решений таких проблем. Однако новые разработки D-Bus могут начать решать эту проблему.
D-Bus может оказаться полезным для целей, отличных от тех, для которых он был разработан. Есть общие свойства, которые отличают его от других вариантов IPC:
Двоичный протокол, предназначенный для асинхронного использования (в духе протокола X Window System);
Постоянные и надежные соединения остаются открытыми все время;
Многие вопросы реализации и деплоя описаны, а не остаются неоднозначными / настраиваемыми / подключаемыми.
Семантика подобна существующей системе DCOP, что позволяет KDE легко ее адаптировать.
Функции безопасности для поддержки режима общесистемной шины сообщений.
Концепции
Некоторые базовые концепции применимы независимо от того, какую платформу приложения вы используете для написания приложения D-Bus. Однако конкретный код, который вы напишете, будет отличаться для приложений GLib, Qt и Python.
Вот диаграмма, которая может помочь вам наглядно представить следующие концепции.
Нативные объекты и пути к объектам
Вероятно, в вашем фреймворке, определено, что такое « объект»; обычно это базовый класс. Например: java.lang.Object, GObject, QObject, базовый объект Python или что-то еще. Назовем их нативным объектом.
Протокол D-Bus низкого уровня и соответствующий API libdbus не оперирует нативными объектами. Однако он предоставляет концепцию, называемую путем к объекту. Идея пути к объекту заключается в том, что привязки более высокого уровня могут давать имена экземплярам собственных объектов и позволяет удаленным приложениям обращаться к ним.
Путь к объекту выглядит как путь в файловой системе, например, объект может называться
, если это имеет смысл для вашего приложения.
). Благодаря этому разные модули кода в одном процессе не будут мешать друг другу.
Методы и сигналы
На методы, и сигналы ссылаются по их имени, например «Frobate» или «OnClicked».
Интерфейсы
Каждый объект поддерживает один или несколько интерфейсов. Понимайте интерфейс как именованную группу методов и сигналов, как в GLib, Qt или Java. Интерфейсы определяют тип экземпляра объекта.
D‑Bus идентифицирует интерфейсы с помощью простой строки с именами, например
. Большинство привязок будут непосредственно отображать эти имена интерфейсов на соответствующую конструкцию языка программирования, например, на интерфейсы Java или чистые виртуальные классы C++.
Прокси
В псевдокоде программирование без прокси может выглядеть так:
Программирование с использованием прокси может выглядеть так:
Шинные имена
Когда приложение подключается к демону шины, который немедленно присваивает ему имя, называемое уникальным именем подключения. Уникальное имя начинается с символа ‘:’ (двоеточия). Эти имена никогда не используются повторно во время существования шинного демона — то есть вы знаете, что данное имя всегда будет относиться к одному и тому же приложению. Примером уникального имени может быть “:34–907”. Цифры после двоеточия не имеют другого значения, кроме их уникальности.
Когда имя сопоставляется с подключением определенного приложения, считается, что это приложение владеет этим именем.
Приложения могут запрашивать дополнительные общепринятые (well-known) имена. Например, вы можете написать спецификацию для определения имени
. В вашем определении можно указать, что для владения этим именем приложение должно иметь объект с путём
Затем приложения для вызова методов могут отправлять сообщения на это шинное имя, объект и интерфейс.
Вы можете думать об уникальных именах как об IP-адресах, а об общепринятых именах как о доменных именах. Таким образом,
может отображаться например как
сопоставляется с чем-то вроде
Имена, помимо маршрутизации сообщений, имеют второе важное применение. Они используются для отслеживания жизненного цикла. Когда приложение завершает работу (или аварийно закрывается), ядро операционной системы закрывает его соединение с шиной сообщений. Затем шина сообщений отправляет сообщения уведомления, информирующие остальные приложения о том, что имена приложения потеряли своего владельца. Отслеживая эти уведомления, ваше приложение может надежно отслеживать время жизни других приложений.
Шинные имена также могут использоваться для координации «одноэкземплярных» приложений. Если, например, вы хотите быть уверенным, что работает только одно приложение
, закрывайте приложение текстового редактора, если такое шинное имя уже имеет владельца.
Адреса
Приложения, использующие D-Bus, являются либо серверами, либо клиентами. Сервер прослушивает входящие соединения; клиент подключается к серверу. Как только соединение установлено, образуется симметричный поток сообщений. Различие клиент-сервер имеет значение только при настройке соединения.
Если вы, используете демон шины, ваше приложение будет клиентом демона шины. То есть демон шины прослушивает соединения, а ваше приложение инициирует соединение с демоном шины.
D-Bus адрес указывает, где сервер будет слушать, и куда будет подключаться клиент. Например, адрес
указывает, что сервер будет прослушивать сокет домена UNIX с путём
и клиент будет подключаться к этому сокету. Адрес может также определять TCP/IP сокеты или любой другой транспорт, который будет определен в будущих итерациях спецификации D-Bus.
При использовании D-Bus с демоном шины сообщений libdbus автоматически обнаруживает адрес сеансового демона шины, считывая переменную среды. Он обнаруживает демон общесистемной шины, проверяя известный путь сокета домена UNIX (хотя вы можете переопределить этот адрес с помощью переменной среды).
Если вы используете D-Bus без демона шины, вам решать, какое приложение будет сервером, а какое — клиентом, а также указать механизм для согласования адреса сервера. Это нетипичный случай.
Большая концептуальная картина
Собирая все эти концепции воедино, для вызова конкретного метода для конкретного экземпляра объекта, необходимо назвать несколько вложенных компонентов:
Шинное имя указано в квадратных скобках, чтобы указать, что оно необязательно — вы указываете имя только для маршрутизации вызова метода в нужном приложение при использовании демона шины. Если у вас есть прямое соединение с другим приложением, то демон шины отсутствует и шинные имена не используются.
Интерфейс также не является обязательным, в первую очередь по историческим причинам; DCOP не требует указания интерфейса, вместо этого просто запрещает дублирование имен методов в одном экземпляре объекта. Таким образом, D-Bus позволит вам не указывать интерфейс, но если имя вашего метода неоднозначно, то не определено, какой метод будет вызван.
За кулисами сообщения
D-Bus работает, отправляя сообщения между процессами. Если вы используете привязку достаточно высокого уровня, возможно вам не понадобится работать с сообщениями напрямую.
Есть 4 типа сообщений:
Сообщения о вызове метода запрашивают вызов метода для объекта;
Сообщения о завершении метода возвращают результаты вызова метода;
Сообщения об ошибках возвращают исключение, возникшее при вызове метода;
Сигнальные сообщения — это уведомления о том, что данный сигнал был послан (что произошло событие). Вы также можете понимать это как «сообщениях о событиях».
Вызов метода очень просто сопоставляется с сообщениями: вы отправляете сообщение о вызове метода и получаете в ответ либо сообщение о завершении метода, либо сообщение об ошибке.
У каждого сообщения есть заголовок, содержащий поля, и тело, включающее аргументы. Вы можете думать о заголовке как о маршрутной информации для сообщения, а о теле — как о полезной нагрузке. Поля заголовка могут включать шинное имя отправителя, шинное имя назначения, имя метода или сигнала и так далее. Одно из полей заголовка — это сигнатура типа, описывающая значения, находящиеся в теле. Например, буква «i» означает «32-битное целое число», поэтому сигнатура «ii» означает, что полезная нагрузка содержит два 32-битных целых числа.
За кулисами вызова метода
Вызов метода в D-Bus состоит из двух сообщений; сообщение о вызове метода, отправленное из процесса A в процесс B, и сообщение ответа соответствующего метода, отправленное из процесса B в процесс A. И вызов, и сообщение ответа маршрутизируются через демон шины. Вызывающий включает в каждое сообщение о вызове другой серийный номер, и ответное сообщение включает этот номер, чтобы вызывающий процесс мог сопоставить ответы с вызовами.
Сообщение о вызове будет содержать любые аргументы метода. Ответное сообщение может указывать на ошибку или может содержать данные, возвращаемые методом.
Вызов метода в D-Bus происходит следующим образом:
Привязка языка может предоставлять прокси, так что вызов метода внутрипроцессного объекта вызывает метод удаленного объекта в другом процессе. Если это так, приложение вызывает метод на прокси-сервере, и прокси создает сообщение о вызове метода для отправки удаленному процессу.
Для более низкоуровневых API приложение может создать сообщение о вызове метода само, без использования прокси.
В любом случае сообщение о вызове метода содержит: имя шины, принадлежащее удаленному процессу, название метода, аргументы метода, путь к объекту внутри удаленного процесса и, опционально, имя интерфейса, определяющего метод.
Сообщение о вызове метода отправляется демону шины.
Демон шины просматривает шинное имя назначения. Если это имя принадлежит процессу, демон шины перенаправляет вызов метода этому процессу. В противном случае демон шины создает сообщение об ошибке и отправляет его обратно в качестве ответа на сообщение о вызове метода.
Принимающий процесс распаковывает сообщение о вызове метода. В простой ситуации низкоуровневого API он может немедленно запустить метод и отправить ответное сообщение метода демону шины. При использовании API привязки высокого уровня, привязка может проверять путь к объекту, интерфейс и имя метода и преобразовывать сообщение вызова метода в вызов метода для нативного объекта (GObject, java.lang.Object, QObject, и т. д.), а затем преобразовать возвращаемое значение из нативного метода в ответное сообщение метода.
Демон шины получает ответное сообщение метода и отправляет его процессу, который вызвал метод.
Процесс, вызвавший метод, просматривает ответ метода и использует любые возвращаемые значения, находящиеся в ответе. Ответ также может указывать на то, что произошла ошибка. При использовании привязки ответное сообщение метода может быть преобразовано в возвращаемое значение прокси-метода или в исключение.
Демон шины никогда не меняет порядок сообщений. То есть, если вы отправите два сообщения о вызове метода одному и тому же получателю, они будут получены в том порядке, в котором они были отправлены. Однако получатель не обязан отвечать на вызовы по порядку; например, он может обрабатывать каждый вызов метода в отдельном потоке и возвращать ответные сообщения в неопределенном порядке в зависимости от того, когда потоки завершаются. Вызовы методов имеют уникальный серийный номер, используемый вызывающим методом для сопоставления ответных сообщений с сообщениями вызова.
За кулисами излучения сигнала
Сигнал в D‑Bus состоит из одного сообщения, отправляемого одним процессом любому количеству других процессов. То есть сигнал — это однонаправленная трансляция. Сигнал может содержать аргументы (полезные данные), но поскольку он является широковещательным, он никогда не имеет «возвращаемого значения». Сравните это с вызовом метода (см. #), где сообщение о вызове метода имеет соответствующее ответное сообщение метода.
Эмитент (он же отправитель) сигнала не знает получателей сигнала. Получатели регистрируются с помощью демона шины для получения сигналов на основе «правил соответствия» — эти правила обычно включают отправителя и имя сигнала. Демон шины отправляет каждый сигнал только тем получателям, которые проявили интерес к этому сигналу.
Сигнал в D‑Bus передается следующим образом:
Сигнальное сообщение создается и отправляется демону шины. При использовании низкоуровневого API это можно сделать вручную, с некоторыми привязками это может быть сделано за вас с помощью привязки, когда нативный объект испускает нативный сигнал или событие.
Сигнальное сообщение содержит имя интерфейса, определяющего сигнал, название сигнала, шинное имя процесса, отправляющего сигнал; и любые аргументы.
Любой процесс на шине сообщений может зарегистрировать «правила сопоставления», указывающие, какие сигналы ему интересны. На шине есть список зарегистрированных правил сопоставления.
Демон шины исследует сигнал и определяет, какие процессы в нем заинтересованы. Он отправляет этим процессам сигнальное сообщение.
Каждый процесс, получивший сигнал, решает, что с ним делать; при использовании привязки, привязка может излучать нативный сигнал для прокси-объекта. При использовании низкоуровневого API процесс может просто взглянуть на отправителя сигнала и имя и решить, что делать на основании этого.
Интроспекция
Объекты D-Bus могут поддерживать интерфейс
У этого интерфейса есть один метод Introspect, который не принимает аргументов и возвращает строку XML. Строка XML описывает интерфейсы, методы и сигналы объекта. См. Спецификацию D-Bus для получения более подробной информации об этом формате интроспекции.
GLib API
Рекомендуемый GLib API для D-Bus — GDBus, который распространяется с GLib начиная с версии 2.26. Здесь это не задокументировано, для получения подробной информации о том, как использовать GDBus см. Документацию GLib по ссылке:
Также существует более старый API, dbus-glib. Он устарел и не должен использоваться в новом коде. По возможности также рекомендуется переносить существующий код из dbus-glib в GDBus.
Python API
Python API, dbus-python, теперь документирован отдельно в руководстве dbus-python
(также доступен в doc/tutorial.txt и doc/tutorial.html, если он собран с помощью python-documenttils, в исходном дистрибутиве dbus-python).
Qt API
Привязка Qt для libdbus, QtDBus, распространяется с Qt начиная с версии 4.2. Здесь это не задокументировано. Для получения подробной информации о том, как использовать QtDBus см. документацию Qt
