Qt D-Bus

Введение

D-Bus — это механизм межпроцессного взаимодействия (IPC) и вызова удаленных процедур (RPC), первоначально разработанный для Linux, чтобы заменить существующие и конкурирующие решения IPC единым протоколом. Он также был разработан для обеспечения взаимодействия между процессами системного уровня (такими как службы принтера и драйверов оборудования) и обычными пользовательскими процессами.

Он использует быстрый двоичный протокол обмена сообщениями, подходящий для внутримашинного взаимодействия благодаря низкой задержке и низкой нагрузке. Его спецификация в настоящее время определяется проектом freedesktop.org, и доступна всем заинтересованным сторонам.

Взаимодействие в целом происходит через центральное серверное приложение, называемое «шиной» (отсюда и название), но также возможно прямое взаимодействие между приложениями. При взаимодействии через шину приложения могут запрашивать, какие другие приложения и службы доступны, а также активировать их по запросу.

Шины

Шины D-Bus используются, когда желательно взаимодействие «многие ко многим». Для этого перед подключением каких-либо приложений к шине запускается центральный сервер: этот сервер отвечает за отслеживание подключенных приложений и правильное маршрутизирование сообщений от источника к получателю.

Кроме того, D-Bus определяет две хорошо известные шины: системную шину и сессионную шину. Эти шины особенные тем, что у них есть определенные семантика: некоторые службы определены для поиска в одной или обеих этих шинах.

Например, приложение, желающее запросить список устройств оборудования, подключенных к компьютеру, скорее всего, будет взаимодействовать со службой, доступной на системной шине, в то время как служба, предоставляющая возможность открытия веб-браузера пользователя, скорее всего, будет найдена на сессионной шине.

На системной шине также можно ожидать ограничений на то, какие службы каждое приложение разрешено предоставлять. Поэтому можно с уверенностью сказать, что если определённая служба присутствует, то она предоставляется доверенным приложением.

Концепции

Сообщения

На низком уровне приложения взаимодействуют через D-Bus, отправляя сообщения друг другу. Сообщения используются для передачи вызовов удалённых процедур, а также ответов и ошибок, связанных с ними. При использовании через шину у сообщений есть пункт назначения, что означает, что они маршрутизируются только к заинтересованным сторонам, избегая перегрузки из-за «наплыва» или широковещательной рассылки.

Однако специальный тип сообщения, называемый «сигнальным сообщением» (концепция, основанная на механизме «сигналы и слоты» Qt), не имеет предварительно определённого пункта назначения. Поскольку его цель состоит в использовании в контексте «один ко многим», сигнальные сообщения разработаны для работы по механизму «добровольного участия».

Модуль Qt D-Bus полностью инкапсулирует низкоуровневую концепцию сообщений в более простой, объектно-ориентированный подход, знакомый разработчикам Qt. В большинстве случаев разработчик не должен беспокоиться об отправке или получении сообщений.

Имена служб

При взаимодействии через шину приложения получают так называемое «имя службы»: именно так это приложение выбирает, чтобы быть известным другим приложениям на той же шине. Имена служб регулируются демоном шины D-Bus и используются для маршрутизации сообщений от одного приложения к другому. Аналогичной концепцией именам служб являются IP-адреса и имена хостов: компьютер, как правило, имеет один IP-адрес и может иметь одно или несколько имён хостов, связанных с ним в соответствии со службами, которые он предоставляет сети.

С другой стороны, если шина не используется, имена служб также не используются. Если сравнивать это снова с компьютерной сетью, это эквивалентно сети «точка-точка»: поскольку узел известен, нет необходимости использовать имена хостов для его поиска или его IP-адреса.

Формат имени службы D-Bus фактически очень похож на имя хоста: это последовательность букв и цифр, разделённых точками. Общепринятая практика заключается даже в том, чтобы называть имя своей службы в соответствии с доменным именем организации, которая определила эту службу.

Например, служба D-Bus определяется freedesktop.org и может быть найдена на шине под именем службы:

org.freedesktop.DBus

Пути объектов

Как и хосты сети, приложения предоставляют конкретные услуги другим приложениям, экспортируя объекты. Эти объекты организованы иерархически, подобно отношениям «родитель-потомок», которыми обладают классы, производные от QObject. Однако есть одно различие: существует понятие «корневого объекта», который является конечным родителем всех объектов.

Если продолжить аналогию с веб-сервисами, пути объектов эквивалентны пути в 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 &

Информация о сообщениях будет выводиться в консоль, из которой было запущено приложение.

Использование модуля

Использование модуля Qt требует компоновки против библиотеки модуля, либо напрямую, либо через другие зависимости. Различные инструменты сборки поддерживают это, включая CMake и qmake.

Сборка с помощью CMake

Используйте команду find_package() для поиска необходимых компонентов модуля в пакете Qt6:

find_package(Qt6 COMPONENTS DBus REQUIRED)
target_link_libraries(mytarget PRIVATE Qt6::DBus)

См. также обзор Сборка с помощью CMake.

Сборка с помощью qmake

Чтобы настроить модуль для сборки с помощью qmake, добавьте модуль в качестве значения переменной QT в файле проекта .pro:

QT += dbus

Эволюция модуля

Изменения в Qt D-Bus перечисляет важные изменения в API и функциональности модуля, которые были внесены для серии Qt 6.

Лицензии и авторские права

Модуль Qt D-Bus доступен по коммерческим лицензиям от The Qt Company. Кроме того, он доступен по лицензиям свободного программного обеспечения: GNU Lesser General Public License, версия 3 или GNU General Public License, версия 2. Подробнее см. Qt Licensing.

Кроме того, модуль Qt D-Bus в Qt 6.0.0 может содержать модули сторонних разработчиков по следующим разрешительным лицензиям:

Дополнительные материалы

В следующих документах содержится информация об интеграции Qt с D-Bus и подробности о механизмах отправки и получения информации о типах через шину:

• Использование адаптеров Qt D-Bus
• Система типов Qt D-Bus
• Компилятор XML Qt D-Bus (qdbusxml2cpp)
• Классы Qt D-Bus C++
• Примеры Qt D-Bus
• Просмотрщик D-Bus