Руководство по D-BUS

(перевод https://dbus.freedesktop.org/doc/dbus-tutorial.html)

Havoc Pennington

Red Hat, Inc.

<hp@pobox.com>

Дэвид Уиллер

Джон Палмиери

Red Hat, Inc.

<johnp@redhat.com>

Колин Уолтерс

Red Hat, Inc.

<walters@redhat.com>

Версия 0.5.0

Документ
в процессе разработки

Это руководство не завершено. Оно, вероятно, содержит некоторую полезную информацию, но также имеет много пробелов. Прямо сейчас вам также необходимо обратиться к спецификации D-Bus, справочной документации Doxygen и посмотреть несколько примеров того, как другие приложения используют D-Bus.

Определенно, приветствуется улучшение руководства — отправляйте свои исправления или предложения в список рассылки. Если вы создаете привязку D-Bus, пожалуйста, добавьте в этот учебник раздел о вашей привязке, хотя бы небольшой раздел с парой примеров.

Что такое D-Bus?

D-Bus — это система межпроцессного взаимодействия (IPC). Архитектурно он имеет несколько слоев:

  • Библиотека libdbus, которая позволяет двум приложениям подключаться друг к другу и обмениваться сообщениями.

Библиотека libdbus поддерживает только соединения точка-точка, подобно raw-сокету. Однако, вместо отправки по соединению потока байтов, вы отправляете сообщения. Сообщения имеют заголовок, определяющий тип сообщения, и тело, содержащее полезные данные. libdbus также абстрагирует конкретно используемый транспорт (сокеты или что-то еще) и обрабатывает такие подробности, как аутентификация.

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

На обычном компьютере имеется несколько экземпляров демона шины. Первый экземпляр — это глобальный синглтон машины, то есть системный демон, похожий на sendmail или Apache. Этот экземпляр имеет строгие ограничения безопасности на то, какие сообщения он будет принимать, и используется для общесистемной связи. Остальные экземпляры создаются по одному для каждого сеанса входа пользователя. Эти экземпляры позволяют приложениям в сеансе пользователя взаимодействовать друг с другом.

Общесистемный и индивидуальные демоны разделены. Обычный внутрисессионный IPC не использует шину сообщений общесистемного процесса, и наоборот.

Применения D-Bus

В мире существует очень много технологий, заявленная цель которых — «межпроцессное взаимодействие» или «сеть»: CORBA, DCE, DCOM, DCOP, XML-RPC, SOAP, MBUS, Internet Communications Engine (ICE) и наверное еще сотни. Каждый из них предназначен для определенных типов использования. 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);

Функции безопасности для поддержки режима общесистемной шины сообщений.

Концепции

Некоторые базовые концепции применимы независимо от того, какую платформу приложения вы используете для написания приложения D-Bus. Однако конкретный код, который вы напишете, будет отличаться для приложений GLib, Qt и Python.

Вот диаграмма, которая может помочь вам наглядно представить следующие концепции.

Image for post
Image for post

Нативные объекты
и пути к объектам

Ваш фреймворк, вероятно, определяет, что такое «объект»; обычно это базовый класс. Например: java.lang.Object, GObject, QObject, базовый объект python или что-то еще. Назовем их нативным объектом.

Протокол D-Bus низкого уровня и соответствующий API libdbus не оперирует нативными объектами. Однако он предоставляет концепцию, называемую путем к объекту. Идея пути к объекту заключается в том, что привязки более высокого уровня могут давать имена экземплярам собственных объектов и позволяет удаленным приложениям обращаться к ним.

Путь к объекту выглядит как путь в файловой системе, например, объект может называться:

/org/kde/kspread/sheet/3/cells/4/5

Удобочитаемые пути — это хороший тон, но вы можете создать объект с именем

/com/mycompany/c5yo817y0c1y1c5b

, если это имеет смысл для вашего приложения.

Разумно начинать пути к объектам с их пространств имен — с компонентов вашего доменного имени (например,

/org/kde

). Благодаря этому разные модули кода в одном процессе не будут мешать друг другу.

Методы и сигналы

У каждого объекта есть члены. Два вида членов — это методы и сигналы. Методы — это операции, которые могут быть вызваны с объектом, с необязательным вводом (они же аргументы или «входные параметры») и выводом (они же возвращаемые значения или «исходящие параметры»). Сигналы — это широковещательные передачи от объекта всем заинтересованным наблюдателям объекта; сигналы могут содержать полезные данные.

На методы, и сигналы ссылаются по их имени, например «Frobate» или «OnClicked».

Интерфейсы

Каждый объект поддерживает один или несколько интерфейсов. Воспринимайте интерфейс как именованную группу методов и сигналов, как в GLib, Qt или Java. Интерфейсы определяют тип экземпляра объекта.

D-Bus идентифицирует интерфейсы с помощью простой строки с именами, например:

org.freedesktop.Introspectable

Большинство привязок будут отображать эти имена интерфейсов непосредственно на соответствующую конструкцию языка программирования, например, на интерфейсы Java или чистые виртуальные классы C++.

Прокси

Прокси-объект — это удобный нативный объект, созданный для представления удаленного объекта в другом процессе. Низкоуровневый D-Bus API предполагает создание вручную сообщения о вызове метода, его отправку, а затем получение и ручную обработку сообщения с ответом метода. Привязки более высокого уровня в качестве альтернативы предоставляют прокси. Прокси выглядят как обычный нативный объект, но когда вы вызываете метод прокси-объекта, привязка преобразует его в сообщение вызова метода D-Bus, ожидает ответного сообщения, распаковывает возвращаемое значение и возвращает его из нативного метода.

В псевдокоде программирование без прокси может выглядеть так:

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);

Шинные имена

Когда приложение подключается к демону шины, который немедленно присваивает ему имя, называемое уникальным именем подключения. Уникальное имя начинается с символа ‘:’ (двоеточия). Эти имена никогда не используются повторно во время существования шинного демона — то есть вы знаете, что данное имя всегда будет относиться к одному и тому же приложению. Примером уникального имени может быть “:34–907”. Цифры после двоеточия не имеют другого значения, кроме их уникальности.

Когда имя сопоставляется с подключением определенного приложения, считается, что это приложение владеет этим именем.

Приложения могут запрашивать дополнительные общепринятые (well-known) имена. Например, вы можете написать спецификацию для определения имени

com.mycompany.TextEditor

. В вашем определении можно указать, что для владения этим именем приложение должно иметь объект с путём

/com/mycompany/TextFileManager

, поддерживающий интерфейс

org.freedesktop.FileHandler.

Затем приложения для вызова методов могут отправлять сообщения на это шинное имя, объект и интерфейс.

Вы можете думать об уникальных именах как об IP-адресах, а об общепринятых именах как о доменных именах. Таким образом,

com.mycompany.TextEditor

может отображаться например как

:34-907

так же, как

mycompany.com

сопоставляется с чем-то вроде

192.168.0.5

Имена, помимо маршрутизации сообщений, имеют второе важное применение. Они используются для отслеживания жизненного цикла. Когда приложение завершает работу (или аварийно закрывается), ядро операционной системы закрывает его соединение с шиной сообщений. Затем шина сообщений отправляет сообщения уведомления, информирующие остальные приложения о том, что имена приложения потеряли своего владельца. Отслеживая эти уведомления, ваше приложение может надежно отслеживать время жизни других приложений.

Шинные имена также могут использоваться для координации «одноэкземплярных» приложений. Если, например, вы хотите быть уверенным, что работает только одно приложение

com.mycompany.TextEditor

, закрывайте приложение текстового редактора, если такое шинное имя уже имеет владельца.

Адреса

Приложения, использующие D-Bus, являются либо серверами, либо клиентами. Сервер прослушивает входящие соединения; клиент подключается к серверу. Как только соединение установлено, образуется симметричный поток сообщений. Различие клиент-сервер имеет значение только при настройке соединения.

Если вы, используете демон шины, ваше приложение будет клиентом демона шины. То есть демон шины прослушивает соединения, а ваше приложение инициирует соединение с демоном шины.

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

unix:path=/tmp/abcdef

указывает, что сервер будет прослушивать сокет домена UNIX с путём

/tmp/abcdef

и клиент будет подключаться к этому сокету. Адрес может также определять 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 происходит следующим образом:

  • Привязка языка может предоставлять прокси, так что вызов метода внутрипроцессного объекта вызывает метод удаленного объекта в другом процессе. Если это так, приложение вызывает метод на прокси-сервере, и прокси создает сообщение о вызове метода для отправки удаленному процессу.

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

За кулисами излучения сигнала

Сигнал в D‑Bus состоит из одного сообщения, отправляемого одним процессом любому количеству других процессов. То есть сигнал — это однонаправленная трансляция. Сигнал может содержать аргументы (полезные данные), но поскольку он является широковещательным, он никогда не имеет «возвращаемого значения». Сравните это с вызовом метода (см. #), где сообщение о вызове метода имеет соответствующее ответное сообщение метода.

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

Сигнал в D‑Bus передается следующим образом:

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

Интроспекция

Объекты D-Bus могут поддерживать интерфейс

org.freedesktop.DBus.Introspectable

У этого интерфейса есть один метод Introspect, который не принимает аргументов и возвращает строку XML. Строка XML описывает интерфейсы, методы и сигналы объекта. См. Спецификацию D-Bus для получения более подробной информации об этом формате интроспекции.

GLib API

Рекомендуемый GLib API для D-Bus — GDBus, который распространяется с GLib начиная с версии 2.26. Здесь это не задокументировано, для получения подробной информации о том, как использовать GDBus см. Документацию GLib по ссылке:

https://developer.gnome.org/gio/stable/gdbus-convenience.html

Также существует более старый API, dbus-glib. Он устарел и не должен использоваться в новом коде. По возможности также рекомендуется переносить существующий код из dbus-glib в GDBus.

Python API

Python API, dbus-python, теперь документирован отдельно в руководстве dbus-python

http://dbus.freedesktop.org/doc/dbus-python/doc/tutorial.html

(также доступен в doc/tutorial.txt и doc/tutorial.html, если он собран с помощью python-documenttils, в исходном дистрибутиве dbus-python).

Qt API

Привязка Qt для libdbus, QtDBus, распространяется с Qt начиная с версии 4.2. Здесь это не задокументировано. Для получения подробной информации о том, как использовать QtDBus см. документацию Qt

http://qt-project.org/doc/qt-5/qtdbus-index.html.

Electronics engineer who became a programmer.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store