LINUX.ORG.RU

Самодельная UNIX-сокетная шина vs DBUS

 , , , ,


2

3

Добрый день! Есть встраиваемый сетевой девайс на linux kernel 4.14.40. Есть небольшое число микросервисов (userspace-бинарей, всего их 4-6 программ). Нужно организовать между ними IPC. Есть ли смысл интегрировать DBUS если количество микросервисов небольшое? Или легче сделать что-то самодельное через UNIX-сокеты или может пайпы, shared memory. Что посоветуете? Заранее спасибо!

Dbus монструозен. Но прежде чем делать с нуля, глянь ubus из openwrt.

apt_install_lrzsz ★★★
()

Будь пацаном, конечно самопал.

ilovewindows ★★★★★
()

embedded

D-Bus

А он туда вообще влезет? Так-то архитектурно он нифига не под embedded пилился (хотя не могу отрицать что его туда впихивали).

Я бы сделал своё на сокетах, потому что архитектура и интерфейс dbus — это просто Адъ!

mord0d ★★★★★
()

Сам никогда не использовал, но выглядит привлекательно https://nanomsg.org

The communication patterns, also called "scalability protocols", are basic blocks for building distributed systems. By combining them you can create a vast array of distributed applications. The following scalability protocols are currently available:

    PAIR - simple one-to-one communication

    BUS - simple many-to-many communication

    REQREP - allows to build clusters of stateless services to process user requests

    PUBSUB - distributes messages to large sets of interested subscribers

    PIPELINE - aggregates messages from multiple sources and load balances them among many destinations

    SURVEY - allows to query state of multiple applications in a single go
hbee ★★★★
()

Если влезает и не нужно какого-то особого софт-реалтайма или передавать гигабайты данных — бери дбас, конечно.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

ну вот я например открыл страницу пакета dbus в alpine.

Installed size 500 kB

в эмбед такое потащит только идиот с systemd головного мозга (тут такие есть, как мы видим). Да и не в эмбед тоже

Lrrr ★★★★★
()
Последнее исправление: Lrrr (всего исправлений: 1)

Мне больше всего shared memory на вид нравится.

den73 ★★★★★
()
Ответ на: комментарий от hbee

Использую nanomsg уже несколько лет на работе - вполне неплохой вариант очереди сообщений без брокера. Только автор умер и продолжают ее в виде nng - https://github.com/nanomsg/nng.
А так рекомендую не изобретать велосипед и использовать что-либо стандартное - очередь сообщений (тотже nanomsg) или redis как общую память с сетевым доступом, или mqtt сервер mosquitto.

sigurd ★★★★★
()
Ответ на: комментарий от byko3y

Вроде жив: https://github.com/gdamore

Это не автор nanomsg, это текущий разработчик, который поддерживает nanomsg и пилит nng.
Автор - Martin Sustrik (он же и один из авторов zeromq)
А nanomsg - это переписывание Zeromq с нуля.

sigurd ★★★★★
()
Последнее исправление: sigurd (всего исправлений: 4)
Ответ на: комментарий от sigurd

Вроде как кольцо в общей памяти достаточно быстро делается, сборка такого велосипедика выглядит побыстрее чем освоение чужого. Фик знает, конечно, что там у ТС за данные к обмену.

ilovewindows ★★★★★
()
Ответ на: комментарий от intelfx

Ну за архитектуру не скажу (тем более реализаций больше, чем одна), но, соглашусь, что libdbus - тот ещё адок и использовать её напрямую без обертки (GDBus/sd-dbus/…) - то ещё удовольствие.

SkyMaverick ★★★★★
()
Ответ на: комментарий от SkyMaverick

libdbus мерзкий, да. Но никто же не обязывает им пользоваться. А sd-bus кстати написан с нуля, я именно им и пользуюсь всегда.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

libdbus - тот ещё адок и использовать её напрямую без обертки (GDBus/sd-dbus/…) - то ещё удовольствие.

Бгг. Слышь, ТС, тут тебе предлагают кроме libdbus ещё и обёртку к нему в embedded тащить.

А sd-bus кстати написан с нуля, я именно им и пользуюсь всегда.

Первое что нагуглилось – что это API от systemd.

Бгг. Слышь, ТС, тебе тут предлагают кроме libdbus ещё и systemd в embedded тащить.

…А @fornlr наверное думал что пошутил

dimgel ★★★★★
()
Ответ на: комментарий от fornlr

Сокет-сервер + произвольное количество сокет-клиентов + отдельный поток на select-loop общий для сервера и всех клиентов + детектирование ошибок транспорта (гарантированный ответ, в т.ч. ответ-ошибка после таймаута) + авто-реконнект клиентов + мультиплатформенность linux/windows + куча каментов в коде = 1400 строк (h+cpp, не считая тестов). Dbus не нужен.

dimgel ★★★★★
()
Ответ на: комментарий от sigurd

А мы на работе ушли с Zeromq на nanomsg. Поэтому нам не насрать.

И как успехи? Мне правда любопытно. Я когда-то думал о таком, но в итоге забил и переделал софт на микросервисы с HTTP, и это оказалось лучше чем ZMQ в том случае.

hateyoufeel ★★★★★
()
Ответ на: комментарий от intelfx

мне казалось даже самые отбитые гномосеки признавали, что dbus это dogshit, даже относительно DCOP, написанного в пьянном угаре…

Ford_Focus ★★★★★
()
Ответ на: комментарий от Ford_Focus

Другой-то стандартной универсальной IPC всё равно нет.

К тому же, если имелась ввиду реализация (к демону, не спорю, у многих есть вопросы), то с относительно недавних пор появились несколько альтернативных реализаций. Хоть dbus-broker тотже.

SkyMaverick ★★★★★
()

Человек пришёл спросить про embedded микросервисы. Судя по контексту, на одном хосте. И только один предложил не париться и запилить shm. LOR во всей красе :(

Shadow ★★★★★
()
Ответ на: комментарий от PPP328

Ключевые слова «стандартной универсальной». Ясно, что в рамках собственного решения, можно запилить чего хочешь на кольцевых буферах с двух сторон и сокетах/пайпах/shm/«ещё какая-нибудь технология передачи». Договориться только о протоколе и сериализации данных.

Я имел ввиду общесистемный для Линукса стандартный и всеми понимаемый user-mode IPC - D-BUS, и если стоит задача как-то выходить из рамок собственных решений, то с ним придётся так или иначе возиться.

SkyMaverick ★★★★★
()
Последнее исправление: SkyMaverick (всего исправлений: 2)
Ответ на: комментарий от PPP328

Потом тебе нужна интеграция с системой (хоть с темже systemd). Ну и что ты там будешь делать о своим json-rpc?

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

SkyMaverick ★★★★★
()
Ответ на: комментарий от Shadow

Человек пришёл спросить про embedded микросервисы. Судя по контексту, на одном хосте. И только один предложил не париться и запилить shm.

Т.е. по вашему, микросервисы будут сами само-опыляться без входных и выходных данных? Или обмен между микросерверами делаем по одному протоколу, а обмен входными и выходными данными - по другому?

И одной shm недостаточно для общения, еще и семафоры нужно будет использовать для синхронизации.
Тогда уж проще исмпользовать ядерный IPC msgsnd()-msgrcv()

sigurd ★★★★★
()
Последнее исправление: sigurd (всего исправлений: 2)
Ответ на: комментарий от sigurd

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

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

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

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

sigurd ★★★★★
()
Ответ на: комментарий от sigurd

Согласен.
Но предложить же надо - во многих случаях хорошее решение.

Shadow ★★★★★
()
Ответ на: комментарий от SkyMaverick

Потом тебе нужна интеграция с системой (хоть с темже systemd). Ну и что ты там будешь делать о своим json-rpc?

Потом тебе нужна интеграция с внешним миром (хоть с той же виндой). Ну и что ты там будешь делать со своим DBUS?

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328

Микросервисы на виндах? Месье знает толк.

В третий раз тебе говорю, речь (конкретно моя) была про системный IPC, а не про то, что ты можешь заюзать для связи СВОИХ сервисов. Универсальный системный user-mode IPC в Linux один - D-BUS. Точка. Работать с ним умеют чуть менее, чем все (даже init). Если у тебя все компоненты системы заточены исключительно под собственную реализацию, то хоть json-rpc, хоть пайпы, хоть COM переизобретай - пофигу чуть более чем совсем, лишь бы в необходимые рамки влезало.

SkyMaverick ★★★★★
()
Последнее исправление: SkyMaverick (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.