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

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

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

embedded

D-Bus

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

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

Влезет. Чего бы нет? Другое дело, что он всё равно какой-то мутный.

Сам никогда не использовал, но выглядит привлекательно 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

Рекомендую D-Bus через Systemd. Хорошо заходит.

Довольно простое решение.

Рекомендую D-Bus через Systemd. Хорошо заходит.

Неплохое введение: https://habr.com/en/post/551532/

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

О, архитекторы пожаловали.

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

Installed size 500 kB

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

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

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

Только автор умер и продолжают ее в виде nng - https://github.com/nanomsg/nng

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

NNG — это переписывание nanomsg с нуля.

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

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

Автор - Martin Sustrik (он же и один из авторов zeromq)

А когда он умер?

https://www.linkedin.com/in/martin-sustrik-b93b186/?originalSubdomain=sk

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

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

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

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

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

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

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

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

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

Во, я нашёл ещё более удобную обёрточку. Рекомендую.

На чём модно сейчас дубасить? (c++ + D-Bus)

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

Шустрик жив. Умер его дружок по ZeroMQ.

https://en.m.wikipedia.org/wiki/Pieter_Hintjens

Ну и славно! Просто Шустрик забросил nanomsg и несколько лет не отвечал на все запросы.

Да и насрать. Nanomsg не то чтобы сильно лучше Zmq.

Да и насрать. Nanomsg не то чтобы сильно лучше Zmq.

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

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

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

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

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

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

HTTP+json работает везде - linux, windows, embedded. Сейчас слезаем с иглы DBUS на лицо сокетов.

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

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

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

«стандартной универсальной»

https://www.jsonrpc.org/specification
https://ru.wikipedia.org/wiki/JSON-RPC#%D0%A0%D0%B5%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8 - - только на вики 70 реализации перечислено. Достаточно стандартно?

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

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

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

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

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

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

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

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

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

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

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

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

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