Правильный способ общения с процессом-монитором

dbus, tcp, http, shared memory... выбирай

• Православно, портабельно, но геморройно - через сокеты.
• Православно, локально и непортабельно на винды - юникс-сокеты.
• Православно, портабельно и с меньшим геморроем чем на голых сокетах - всякие легковесные MQ типа nanomsg/zeromq.
• Поттерингославно - dbus.
• Энтерпрайзненько - какой-нибудь RPC или вебсервис типа SOAP.
• Хипстерски - RESTful поверх http.
• Олдфажно-бородато POSIX mq
• Быстро и локально - shared memory
• И ещё много способов которые я навскидку не соображу

а чем не устраивает просто запись в файл ?

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

Ты бы ЯП уточнил. А так, если есть тяга к сокетам то лучше что-то типа zmq чтобы не мараться с сокетами.

Тока не юзай dbus.

threads /socket
ой
sockets /thread

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

SNMP

Тогда уже более легковесный MQTT.

То, что нужно, спасибо. Узнал много нового.

ZeroMQ

Важен был принципиальный вопрос как лучше сделать, чтобы велосипед не придумывать. Язык C будет (может, прототип на Perl). Почему не dbus?

Омг, сериализовать данные в трубу даже куте умеет.

zmq был изначально задизайнен под твои задачи: типа сокеты нового поколения. У них не идеальны, я рекомендую таки ознакомится с доками. Особенно по поводу надёжной доставки сообщений. Я их не люблю, но они, по-моему, даже применяются «в большом продакшене». Требуют немного времени на освоение, но сильно облегчают роль в написании сетевых приложений т.к. поддерживают многие популярные паттерны аля publish/subscribe итп. В своё время были тупые грабли с недоступностью соденинения при внезапной смерти сервера или типа того. Короче, убедись что твоё приложение корректно восстанавливает работу после пропадания сети и смерти сервера или клиента.

Ну а dbus это исключительно локальная хрень с длинными нечитаемыми «путями». По мне так лажа полная. Но я затрудняюсь аргументированно объяснить почему кроме некоторых личных предпочтений.

Спасибо.

Ну а dbus это исключительно локальная хрень с длинными нечитаемыми «путями».

Серьезно чтоль? dbus не умеет в сеть? блин :( а я на досуге хотел его поковырять. Буду тогда искать другой путь RPC

Не умеет, только локально. Для работы по сети посмотри в сторону AMQP реализаций.

dbus не умеет в сеть?

Он умеет (умел), но лучше бы он не умел. Я лет 7 назад (или больше) пытался сделать IPC по сети между хостами, пришёл к выводу что оно абсолютно для этого не пригодно. Я не помню в чём там были проблемы, но тестировал четыре сценария проблем:

1) падение сервера по SIGKILL с последующим запуском

2) падение клиента по SIGKILL с последующим запуском

3) временный обрыв связи во время передачи данных

4) нужно понять какие данные были получены, а какие нет

Так вот, dbus этот тест тогда провалило с треском. Поэтому наличие tcp-транспорта у dbus мне не понятно.

niin perkele! А что его тогда как панацею от всего предлагают? Я потому и думал, что это ж как было бы круто, чтоб компонент вообще где угодно мог работать, а оказывается не такая уж это и крутая штука.

AMQP

Спасибо, гляну. По описанию годная штука.

А что его тогда как панацею от всего предлагают?

Это только для десктопных приложений, оно затачивалось под это. Оно умеет, например, сериализацию и валидацию. Работать на несколько хостов задачи не было. Вот тут можно немного прочитать чем оно отличается от других IPC и какие задачи решались: dbus.freedesktop.org/doc/dbus-faq.html

чтоб компонент вообще где угодно мог работать

Это zmq и прочие message bus. Они затачивались под распределённые (но не децентрализованные) системы. Авторы d-bus прямо отговаривают от такого использования: http://dbus.freedesktop.org/doc/dbus-faq.html#which-ipc

Он умеет (умел), но лучше бы он не умел.

Оу, а я и не знал. Хотя я dbus толком и не тыкал.