В рамках проекта D-Bus Broker развивается замена шины D-Bus
Дэвид Герман (David Herrmann), в своё время разработавший шину обмена сообщениями Bus1 для ядра Linux, представил новый проект D-Bus Broker, в рамках которого предпринята попытка переосмысления D-Bus и создания новой реализации, устраняющей недостатки штатного демона D-Bus. Код проекта написан на языке Си и распространяется под лицензией Apache 2.0.
Мотивом создания новой реализации стала излишняя раздутость и переусложнённость dbus-daemon, в сочетании с обилием отражённых в системе отслеживания ошибок проблем — от неконтролируемого расходования памяти и пропадании сообщений, до возникновения взаимных блокировок и крахов процесса. Некоторые из проблем остаются нерешёнными до 7 лет, в большей части из-за того, что их принципиально невозможно устранить без нарушения гарантированной в dbus-daemon функциональности и существенных архитектурных изменений.
В отличие от Bus1 проект D-Bus Broker реализован целиком в пространстве пользователя, остаётся полностью совместим с эталонной реализацией D-Bus и может быть использован для прозрачной замены dbus-daemon. При этом новая реализация спроектирована с оглядкой на поддержку востребованной на практике функциональности и уделяет главное внимание работе по увеличению производительности и повышению надёжности. В D-Bus Broker также принципиально не реализованы функции, помеченные как устаревшие, и расширенные возможности, не отражённые в спецификации D-Bus.
Ключевые архитектурные изменения в D-Bus Broker:
Уход от идеи глобальной совместной шины (Shared Medium), к которой соединяются все обработчики сообщений и через которую осуществляется отправка сообщений. Вместо общей шины предложена концепция отдельных пиров, не имеющих глобального состояния. Когда какой-то пир отправляет сообщения, эта операция рассматривается как транзакция между отправителем и одной или несколькими точками назначения.
Отказ от использования дополнительных IPC-механизмов, так как D-Bus сам по себе является IPC и создание надстроек IPC над IPC приводит к появлению взаимных блокировок. Иными словами D-Bus Broker является самодостаточным процессом, который позволяет оперировать только локальными данными и не привязан к внешним обработчикам, таким как чтение файлов и обращение к NSS.
Учёт ресурсов в привязке к пользователям. Каждый ресурс и переданный в шину объект привязан к конкретному пользователю. Таким образом, существенно упрощается реализации ограничений и лимиты больше не привязываются к пиру (ограничения теперь зависят от активности каждого пользователя, а не от общей нагрузки на обработчик).
Воплощение принципа, что сообщение никогда не может быть потеряно без обработки ошибки. В случае возникновения проблем не допускается возникновения неопределённых ситуаций, каждая ошибка доставки должна быть выявлена и обработана, а в случае невозможности обработки ошибки процесс должен завершить свою работу, а не просто игнорировать возникшие проблемы.
Что касается высокой производительности D-Bus Broker, то её ценой является привязка к современным окружениям Linux — для своей работы проект требует наличия ядра Linux 4.10 и glibc 2.16, и принципиально не может быть использован в старых дистрибутивах Linux или в других ОС. Предоставляются опциональные компоненты для интеграции с systemd и SELinux. Обеспечивается работа только локального IPC без поддержки сетевого взаимодействия (при необходимости проброса на другой хост предлагается пробрасывать локальный сокет через SSH).
>>> Подробности на OpenNet.ru
Мотивом создания новой реализации стала излишняя раздутость и переусложнённость dbus-daemon, в сочетании с обилием отражённых в системе отслеживания ошибок проблем — от неконтролируемого расходования памяти и пропадании сообщений, до возникновения взаимных блокировок и крахов процесса. Некоторые из проблем остаются нерешёнными до 7 лет, в большей части из-за того, что их принципиально невозможно устранить без нарушения гарантированной в dbus-daemon функциональности и существенных архитектурных изменений.
В отличие от Bus1 проект D-Bus Broker реализован целиком в пространстве пользователя, остаётся полностью совместим с эталонной реализацией D-Bus и может быть использован для прозрачной замены dbus-daemon. При этом новая реализация спроектирована с оглядкой на поддержку востребованной на практике функциональности и уделяет главное внимание работе по увеличению производительности и повышению надёжности. В D-Bus Broker также принципиально не реализованы функции, помеченные как устаревшие, и расширенные возможности, не отражённые в спецификации D-Bus.
Ключевые архитектурные изменения в D-Bus Broker:
Уход от идеи глобальной совместной шины (Shared Medium), к которой соединяются все обработчики сообщений и через которую осуществляется отправка сообщений. Вместо общей шины предложена концепция отдельных пиров, не имеющих глобального состояния. Когда какой-то пир отправляет сообщения, эта операция рассматривается как транзакция между отправителем и одной или несколькими точками назначения.
Отказ от использования дополнительных IPC-механизмов, так как D-Bus сам по себе является IPC и создание надстроек IPC над IPC приводит к появлению взаимных блокировок. Иными словами D-Bus Broker является самодостаточным процессом, который позволяет оперировать только локальными данными и не привязан к внешним обработчикам, таким как чтение файлов и обращение к NSS.
Учёт ресурсов в привязке к пользователям. Каждый ресурс и переданный в шину объект привязан к конкретному пользователю. Таким образом, существенно упрощается реализации ограничений и лимиты больше не привязываются к пиру (ограничения теперь зависят от активности каждого пользователя, а не от общей нагрузки на обработчик).
Воплощение принципа, что сообщение никогда не может быть потеряно без обработки ошибки. В случае возникновения проблем не допускается возникновения неопределённых ситуаций, каждая ошибка доставки должна быть выявлена и обработана, а в случае невозможности обработки ошибки процесс должен завершить свою работу, а не просто игнорировать возникшие проблемы.
Что касается высокой производительности D-Bus Broker, то её ценой является привязка к современным окружениям Linux — для своей работы проект требует наличия ядра Linux 4.10 и glibc 2.16, и принципиально не может быть использован в старых дистрибутивах Linux или в других ОС. Предоставляются опциональные компоненты для интеграции с systemd и SELinux. Обеспечивается работа только локального IPC без поддержки сетевого взаимодействия (при необходимости проброса на другой хост предлагается пробрасывать локальный сокет через SSH).
>>> Подробности на OpenNet.ru
Ещё новости по теме:
18:20