привет!

хочу такое:
есть приложение получающее даные из сети.
есть "модули", которые получают эти данные и генерят события для других модулей.(ну, т.е. тупо предоставяют возможность всем желающим подключиться к этим событиям)
некоторые модули, в свою очередь, генерят другие события, и опять же — предоставляют возможность всем желающим подключиться к этим событиям. и получается каша, жестко связанная каша.
это все еще больше осложняется тем, что кол-во модулей растет, модули меняются, итд...

вопрос мой заключается в том, как вообще строятся такие архитектуры? я полагаю, что тут подошел бы собжектайзер... ну, или, нужно закодить какой-то диспетчер, в котором все модули будут иметь одинаковые права(т.е. подписываться и публиковать сообщения)

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

Здравствуйте, niXman, Вы писали:

X>есть приложение получающее даные из сети.
X>есть "модули", которые получают эти данные и генерят события для других модулей.(ну, т.е. тупо предоставяют возможность всем желающим подключиться к этим событиям)
X>некоторые модули, в свою очередь, генерят другие события, и опять же — предоставляют возможность всем желающим подключиться к этим событиям. и получается каша, жестко связанная каша.
X>это все еще больше осложняется тем, что кол-во модулей растет, модули меняются, итд...

X>вопрос мой заключается в том, как вообще строятся такие архитектуры? я полагаю, что тут подошел бы собжектайзер... ну, или, нужно закодить какой-то диспетчер, в котором все модули будут иметь одинаковые права(т.е. подписываться и публиковать сообщения)

Используют очереди сообщений, например IBM MQ, rabbitmq (с этой, правда, я не работал).

Здравствуйте, niXman, Вы писали:

X>хочу такое:
X>есть приложение получающее даные из сети.
X>есть "модули", которые получают эти данные и генерят события для других модулей.(ну, т.е. тупо предоставяют возможность всем желающим подключиться к этим событиям)

Паттерн обозреватель (observer) — его реализации на C++
вот примеры:
https://www.codeproject.com/Articles/328365/Understanding-and-Implementing-Observer-Pattern-2
https://www.bogotobogo.com/DesignPatterns/observer.php
https://sourcemaking.com/design_patterns/observer/cpp/3

X>некоторые модули, в свою очередь, генерят другие события, и опять же — предоставляют возможность всем желающим подключиться к этим событиям. и получается каша, жестко связанная каша.

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

X>это все еще больше осложняется тем, что кол-во модулей растет, модули меняются, итд...

А чем тебя Qt с его SIGNAL/SLOT системой не устраивает?
Вот есть connection с очередью:
https://woboq.com/blog/how-qt-signals-slots-work-part3-queuedconnection.html
Правда, не уверен, что это решит именно твою задачу.

Кстати, на boost также есть реализация этого паттерна:
https://www.boost.org/doc/libs/1_63_0/doc/html/signals.html
https://habr.com/post/171471
https://stackoverflow.com/questions/768351/complete-example-using-boostsignals-for-c-eventing
https://stackoverflow.com/questions/10418582/how-do-i-use-boostsignals-to-implement-the-observer-pattern

X>вопрос мой заключается в том, как вообще строятся такие архитектуры? я полагаю, что тут подошел бы собжектайзер... ну, или, нужно закодить какой-то диспетчер, в котором все модули будут иметь одинаковые права(т.е. подписываться и публиковать сообщения)

Гуглим по: "Observer Pattern C++" и его реализации с диспетчированием и очередью.

Здравствуйте, AlexGin, Вы писали:

AG>Сделать что-то, типа очереди сообщений.
да, я об этом и написал.

AG>Для каждого узла — своя очередь. Возможно — очередь с приоритетом.
нет. канал сообщений нужен один для всех модулей.

AG>А чем тебя Qt с его SIGNAL/SLOT системой не устраивает?
сигналы и слоты у меня и так есть при помощи boost.signals2 + lambda.
да и Qt я предпочитаю не использовать совсем.

AG>Гуглим по: "Observer Pattern C++" и его реализации с диспетчированием и очередью.
спасибо, гуглю.

Здравствуйте, niXman, Вы писали:

X>вопрос мой заключается в том, как вообще строятся такие архитектуры? я полагаю, что тут подошел бы собжектайзер... ну, или, нужно закодить какой-то диспетчер, в котором все модули будут иметь одинаковые права(т.е. подписываться и публиковать сообщения)
Похоже ты начинаешь подходить к написанию микросервисов .
Есть AMQP, есть олдскульный D-BUS, есть CORBA (не стоит её использовать). Да, тут действительно агентаня архитектура напрашивается, но это сейчас популярно в виде микросервисов и очередей сообщений.
Фаулер про микросервисы.
У микросервисов есть плюсы — они будут работать в своих процессах и не надо будет городить межтредовую синхронизацию.

Здравствуйте, Kernan, Вы писали:

кстати да, микросервисная архитектура тоже подходит...

K>Фаулер про микросервисы.
почитаю, спасибо!

Здравствуйте, niXman, Вы писали:

X>вопрос мой заключается в том, как вообще строятся такие архитектуры?

Сильно по разному и подходят к их проектированию с разных сторон.
Например, один ключевой вопрос: нужно ли вам иметь эти "модули" в виде независимых процессов, общающихся через какой-то IPC? Это может потребоваться для:

a) обеспечения отказоустойчивости (упал один модуль, другие продолжили работать);
b) обеспечения защищенности (разные модули могут работать с разными привилегиями);
c) обеспечения горизонтальной масштабируемости путем разнесения модулей по разным нодам.

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

Еще один ключевой вопрос: требуется ли взаимодействие только в режимах 1:N или 1:1. Или где-то нужно 1:N, а где-то 1:1. Так, если у вас модули -- это отдельные процессы, которые взаимодействуют в режиме 1:1, то вам прямая дорога в область микросервисов. Если отдельные процессы и 1:N, то нужно брать какой-то MQ-брокер, и плясать уже от него. Если модули должны быть внутри процесса -- то напрашивается использование фреймворков вроде SObjectizer-а или TBB.

Еще один ключевой вопрос: нужна ли персистентность для сообщений. Если нужна, тогда имеет смысл смотреть в сторону использования какого-то MQ-брокера. Или вообще тупо строить всю работу через БД, где отдельные таблички будут играть роль "каналов".

X>я полагаю, что тут подошел бы собжектайзер...

Да, судя по поверхностному описанию, подошел бы.

X>ну, или, нужно закодить какой-то диспетчер, в котором все модули будут иметь одинаковые права(т.е. подписываться и публиковать сообщения)

В SObjectizer-е вам, скорее всего, не нужно будет делать своих диспетчеров. У него внутри уже восемь штук своих, готовых.

Еще можете посмотреть в сторону Intel TBB, той его части, которая касается Data Flow и Dependency Graph.

Здравствуйте, Kernan, Вы писали:

K>и не надо будет городить межтредовую синхронизацию.

Самостоятельно городить межтредовую синхронизацию в XXI веке может иметь смысл разве что для каких-то ну очень уж специфически условий. Например, когда нужно иметь N писателей для одного читателя, а значение N очень большое и вы не можете позволить писателям простаивать в ожидании одного-единственного mutex-а. Для обычных же условий всегда можно найти что-то готовое.

Здравствуйте, so5team, Вы писали:

S>Сильно по разному и подходят к их проектированию с разных сторон.
S>Например, один ключевой вопрос: нужно ли вам иметь эти "модули" в виде независимых процессов, общающихся через какой-то IPC? Это может потребоваться для:

S>a) обеспечения отказоустойчивости (упал один модуль, другие продолжили работать);
S>b) обеспечения защищенности (разные модули могут работать с разными привилегиями);
S>c) обеспечения горизонтальной масштабируемости путем разнесения модулей по разным нодам.
это совсем идеальный вариант, но сейчас мне нужно сделать рабочий прототип. от этого и будет зависеть судьба проекта...

S>Либо же принципиально важно, чтобы все "модули" находились в рамках одного процесса с обменом информацией через общую память без каких-либо IPC.
это не принципиально, это проще.

S>Еще один ключевой вопрос: требуется ли взаимодействие только в режимах 1:N или 1:1. Или где-то нужно 1:N, а где-то 1:1. Так, если у вас модули -- это отдельные процессы, которые взаимодействуют в режиме 1:1, то вам прямая дорога в область микросервисов. Если отдельные процессы и 1:N, то нужно брать какой-то MQ-брокер, и плясать уже от него. Если модули должны быть внутри процесса -- то напрашивается использование фреймворков вроде SObjectizer-а или TBB.
выше ответил.
а что такое TBB?

S>Еще один ключевой вопрос: нужна ли персистентность для сообщений. Если нужна, тогда имеет смысл смотреть в сторону использования какого-то MQ-брокера. Или вообще тупо строить всю работу через БД, где отдельные таблички будут играть роль "каналов".
непонимаю вопроса касательно данного контекста...

S>Еще можете посмотреть в сторону Intel TBB, той его части, которая касается Data Flow и Dependency Graph.
оф, еще и это читать %)

Здравствуйте, niXman, Вы писали:

S>>c) обеспечения горизонтальной масштабируемости путем разнесения модулей по разным нодам.
X>это совсем идеальный вариант, но сейчас мне нужно сделать рабочий прототип. от этого и будет зависеть судьба проекта...

Для прототипа имеет смысл брать SObjectizer Реклама, конечно же

Если более серьезно. Можно взять тот же ZeroMQ. На нем можно делать и прототип и, затем, уже решение для продакшена. Но если опыта работы с ZeroMQ не было, то процесс входа в него будет не быстрым. Да и внутри одного процесса работать через ZeroMQ будет неудобно.

Можно сразу взять какой-то брокер сообщений. RabbitMQ или Kafka. И плясать сразу от возможностей конкретного брокера.

Можно таки взять SObjectizer, сделать прототип, работающий в одном процессе, а потом для IPC реализовать какие-то кастомные mbox-ы, работающие, скажем, через те же MQ-брокеры (пример здесь).

X>а что такое TBB?

Intel Threading Building Blocks. Одна из самых известных в мире C++ библиотек для parallel и concurrent computing.

S>>Еще один ключевой вопрос: нужна ли персистентность для сообщений. Если нужна, тогда имеет смысл смотреть в сторону использования какого-то MQ-брокера. Или вообще тупо строить всю работу через БД, где отдельные таблички будут играть роль "каналов".
X>непонимаю вопроса касательно данного контекста...

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

Здравствуйте, so5team, Вы писали:

ок, значит SObjectizer подходит.
тогда мои вопросы:
есть ли в SObjectizer возможность узнать, подписан ли кто-нить на какое-то конкретное сообщение?
есть ли в SObjectizer возможность отправлять сообщения не зная, подписан ли кто-нить на него?
есть ли в SObjectizer возможность узнать, кто прислал какое-то конкретное сообщение?
есть ли в SObjectizer возможность заблокироваться после отправки какого-то конкретного сообщения, пока все подписанты не выйдут из своих обработчиков какого-то конкретного сообщения?
(динамические подписки/отписки вроде не нужны...)
приложите, пожалуйста, ссылки(если имеются) на соответствующие доки для скорейшего вхождения.

S>Если вы можете пережить потерю сообщения при, скажем, рестарте одного модуля или всего приложения, то персистентность вам не нужна.
да, это не критично. критично не терять сообщения во время работы программы.

Здравствуйте, so5team, Вы писали:

в доке говориться: "There are two types of messages in SObjectizer: ordinary messages with some data inside and signals."
знчаит ли это, что сигналы не могут содержать никаких данных для подписчиков, кроме самого факта возникновения сигнала?


и еще вопрос, опять по доке: "It is necessary to mention that the agent should know which mbox should it use to send and receive messages."
т.е. если я хочу реализовать общий канал сообщений для нескольких агентов, то каждый агент должен использовать общий mbox?
какая-то несвязанная каша в голове =)

Здравствуйте, niXman, Вы писали:

X>тогда мои вопросы:

Прежде всего нужно сказать, что в SO-5 есть такие понятия как "почтовый ящик" (mbox) и "канал" (mchain). И хотя mchain может притворятся mbox-ом, а функции send/send_delayed/send_periodic свободно работают и с mbox-ами, и с mchain-ами, между ними есть достаточно большая разница:

* для получения сообщений из mbox-ов нужно подписываться на mbox-ы. Соответственно, делать это могут только агенты. Получение сообщений из mchain-а осуществляется посредством свободных функций receive/select. Это могут делать не только агенты. Подписываться на mchain-ы не нужно, да и нельзя;

* mbox-ы бывают двух типов: Multi-Producer/Multi-Consumer (MPMC) и Multi-Producer/Single-Consumer (MPSC). MPMC-mbox-ы предназначены для обмена в режиме 1:N. Т.е. если на сообщение типа M подписано 1000 получателей, то отосланное в MPMC-mbox сообщение будет доставлено всем получателям. MPSC-mbox-ы предназначены для обмена в режиме 1:1, т.е. за MPSC-mbox-ом может быть не более одного получателя. mchain-ы ведут себя как MPSC-mbox-ы. При этом в MPMC-mbox-ы нельзя отсылать мутабельные сообщения, а в MPSC-mbox-ы и в mchain-ы можно;

* mbox-ы не хранят сообщения. Т.е. когда в mbox отсылается сообщение, то оно доставляется только тем агентам, которые на mbox подписаны. Нет подписчиков -- сообщение улетело в никуда (хотя в so_5_extra есть специальный retained_mbox, который специально ведет себя несколько по-другому). Тогда как mchain-ы хранят сообщения до тех пор, пока кто-нибудь сообщение не прочитает посредством receive/select;

* mbox-ы -- это безразмерные сущности, ограничений на количество сообщений, которые можно отослать в mbox нет. Поэтому при работе через mbox-ы можно легко организовать перегрузку агентов-подписчиков (т.е. отсылать можно быстрее, чем получатели будут способны обрабатывать). Для защиты от перегрузки нужно применять какие-то инструменты (например, message limits). В свою очередь mchain-ы бывают как безразмерные, так и с ограничениями на размер. В последнем случае в mchain защита от перегрузки как бы идет в комплекте.

Соответственно, при проектировании решения нужно выбирать между использованием mbox-ов и mchain-ов. Как правило, выбор простой: если все пишется на агентах, то и взаимодействие строится на mbox-ах. Если агенты не применяются, то только mchain-ы. Бывают еще и случаи, когда часть приложения на агентах, часть без -- тогда агенты общаются друг с другом через mbox-ы, а с остальной частью приложения -- через mchain.

X>есть ли в SObjectizer возможность узнать, подписан ли кто-нить на какое-то конкретное сообщение?

Отправитель не знает, есть ли кто-нибудь за mbox-ом/mchain-ом. Только подписчик может проверить существование собственной подписки через agent_t::so_has_subscription().

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

X>есть ли в SObjectizer возможность отправлять сообщения не зная, подписан ли кто-нить на него?

Да. Именно так все в SO-5 и работает.

X>есть ли в SObjectizer возможность узнать, кто прислал какое-то конкретное сообщение?

Тут не понятно. Расшифруйте.

X>есть ли в SObjectizer возможность заблокироваться после отправки какого-то конкретного сообщения, пока все подписанты не выйдут из своих обработчиков какого-то конкретного сообщения?

Нет, такого нет. Доставка сообщения происходит асинхронно. Если вам нужно, чтобы отправитель сообщения продолжил работу после того, как все адресаты сообщение обработали, то вам нужно вводить какую-то обратную связь. Скажем, получатель сообщения отсылает подтверждение. А отправитель накапливает у себя эти подтверждения.

X>(динамические подписки/отписки вроде не нужны...)

Они есть.

X>приложите, пожалуйста, ссылки(если имеются) на соответствующие доки для скорейшего вхождения.

Начинать нужно отсюда. Далее здесь нужно смотреть отдельные разделы, посвященные конкретным специфическим темам.

Здравствуйте, niXman, Вы писали:

X>знчаит ли это, что сигналы не могут содержать никаких данных для подписчиков, кроме самого факта возникновения сигнала?

Да, именно это и означает.

Здравствуйте, so5team, Вы писали:

значит нужно использовать mbox`ы.
мутабельные сообщения не нужны.

X>>есть ли в SObjectizer возможность узнать, кто прислал какое-то конкретное сообщение?
S>Тут не понятно. Расшифруйте.
вопрос, скорее вакуумно-сферический =)
вот один агент послал mbox`у сообщение. на этот mbox подписан другой агент, который и получил это сообщение. есть ли возможность получателю узнать, какой агент отправил это сообщение? (повторюсь — вопрос надуманный ввиду несвязанной каши в голове)

S>Нет, такого нет. Доставка сообщения происходит асинхронно. Если вам нужно, чтобы отправитель сообщения продолжил работу после того, как все адресаты сообщение обработали, то вам нужно вводить какую-то обратную связь. Скажем, получатель сообщения отсылает подтверждение. А отправитель накапливает у себя эти подтверждения.
с этим понятно. и логично.

X>>(динамические подписки/отписки вроде не нужны...)
S>Они есть.
ок, учту.

S>Начинать нужно отсюда. Далее здесь нужно смотреть отдельные разделы, посвященные конкретным специфическим темам.
я со второй начал, ибо она лежит третьей ссылкой на основной странице вики.

up
лучше бы я начал с первой, некоторые вопросы не пришлось бы задавать =)

up
по первой ссылке есть такое: "For ordinary messages there are two possibilities: arbitrary type T which is MoveConstructible can be used as message type or type of message must be derived from so_5::message_t."
мне кажется, тут некоторая неоднозначность после or.
если я правильно понимаю, тут должно быть что-то вроде: "For ordinary messages there are two possibilities: arbitrary type T which is MoveConstructible can be used as message type or type which is derived from so_5::message_t."

Здравствуйте, niXman, Вы писали:

X>вот один агент послал mbox`у сообщение. на этот mbox подписан другой агент, который и получил это сообщение. есть ли возможность получателю узнать, какой агент отправил это сообщение? (повторюсь — вопрос надуманный ввиду несвязанной каши в голове)

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

Если нужно передать информацию об отправителе, то такая информация должна включаться в само сообщение, например:

struct some_message final {
  const so_5::mbox_t reply_to_;
  ...
  some_message(so_5::mbox_t reply_to, ...) : reply_to_{std::move(reply_to)}, ...
};

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, niXman, Вы писали:

X>>вот один агент послал mbox`у сообщение. на этот mbox подписан другой агент, который и получил это сообщение. есть ли возможность получателю узнать, какой агент отправил это сообщение? (повторюсь — вопрос надуманный ввиду несвязанной каши в голове)

S>Нет. Вызвано это тем, что сообщения могут ходить не только между агентами. В больших приложениях есть и SObjectizer-части и не-SObjectizer-части. И сообщения часто летят из не-SObjectizer-частей агентам. Но, т.к. отправителем в данном случае является вообще не агент, то и обратного адреса нет.

S>Если нужно передать информацию об отправителе, то такая информация должна включаться в само сообщение, например:
S>

struct some_message final {
S>  const so_5::mbox_t reply_to_;
S>  ...
S>  some_message(so_5::mbox_t reply_to, ...) : reply_to_{std::move(reply_to)}, ...
S>};

понял.

первую ссылку дочитал %)

итак.
исходные данные мне приходят по сети посредством вебсокета.
в качестве вебсокета я использую boost.beast, который поверх boost.asio.
по первой ссылке я этого не встречал, но где-то вы писали о том, что в SObjectizer есть что-то для интеграции то ли asio в SObjectizer, то ли наоборот... куда мне смотреть далее?

Здравствуйте, niXman, Вы писали:

X>в качестве вебсокета я использую boost.beast, который поверх boost.asio.
X>по первой ссылке я этого не встречал, но где-то вы писали о том, что в SObjectizer есть что-то для интеграции то ли asio в SObjectizer, то ли наоборот... куда мне смотреть далее?

Можно смотреть вот на это: so_5::extra::env_infrastructures::asio::simple_mtsafe.
Можно вот на это: so_5::extra::disp::asio_thread_pool Но все это мы делали для standalone-версии Asio, с Boost-овской без доработок не поедет.

А можно вообще не делать какой-либо интеграции, а отдельно работать с Boost.Beast/Asio на одном пуле потоков, отдельно крутить SObjectizer на другом. И передавать информацию из Beast-а в SObjectizer через mbox-ы.

А можно и без Boost.Beast-а обойтись. Взять наш RESTinio. Пример того, как RESTinio и SObjectizer живут вместе можно увидеть в нашем демо-проекте Shrimp. Поддержка WebSocket-ов в RESTinio есть. По нашим впечатлениям, работать с RESTinio проще, чем с Beast-ом.

Здравствуйте, so5team, Вы писали:

S>А можно и без Boost.Beast-а обойтись. Взять наш RESTinio. Пример того, как RESTinio и SObjectizer живут вместе можно увидеть в нашем демо-проекте Shrimp. Поддержка WebSocket-ов в RESTinio есть. По нашим впечатлениям, работать с RESTinio проще, чем с Beast-ом.

не знал что RESTinio поддерживает вебсокеты.

есть ли какой-нить туториэл по использованию вебсокетов из RESTinio и использованию RESTinio впаре с SObjectizer?