Несколько издателей и подписчиков в nanomsg (nng)

Как настроить несколько издателей и подписчиков с помощью транспорта TCP. Я подозреваю, что вы не делаете автоматическое создание сетки / шины. Таким образом, каждому издателю нужна уникальная точка привязки IP-адреса, верно? У них просто есть подписчики, которые подключаются к каждому издателю через один сокет.

(это обсуждалось в: https://www.freelists.org/post/nanomsg/does-nanomsg-support-multi-producer-in-pubsub-mode,10)

Это в основном правильно?

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

  • Мне не нужна полностью подключенная сетка
  • Я полагаю, что фильтрация по основному дереву в каждом узле лучше, чем я бы придумал
  • Мне нравится аспект auto-discovery для pub/sub, а не ручная разводка сетки для автобусных транспортов.
  • (т.е. автоматический "вход и выход из сетки")

По сути, у меня есть 2 производителя (которые в основном занимаются публикацией, но могут время от времени получать запросы на добавление дополнительной информации о публикуемом потоке, поэтому им нужно прислушиваться). А затем о пяти потребителях, которые в основном получают поток данных из издатели, но нужно время от времени отправлять запросы производителям.

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

Так что это двунаправленная архитектура паб / саб. И я смотрю на самый простой способ реализовать это. (движение довольно легкое).

Конечно, транспорт UDP был бы хорош для этого, но я не держу дыхание.

Источник

2 ответа

Решение

NanoMSG NNG является очень симметричным и ортогональным. У меня была пара бесед с Гдамором.

Каждая конечная точка может быть push, req, bus или любой другой. Вы можете иметь несколько конечных точек (например, 2 push или push и req/res). Протокол может быть в любом направлении. Rec может быть блокирующим, асинхронным или основанным на опросе.

Если вы хотите увидеть, как это сделать, смотрите:

https://github.com/nanomsg/nng/issues/551

Источник

Легко:

Использовать NN_PUB/NN_SUB как это было разработано, для неблокирующего, асинхронного, широковещательного направления.

Используйте другой асинхронный канал "снизу вверх", будь то NN_PAIR/NN_PAIR или любой другой, более сложный шаблон архетипа Scalable Formal Communication, например NN_PUSH/NN_PULL или наоборот NN_PUB/NN_SUB это соответствует как вашим намерениям, так и целям латентности.

Рабочие процессы будут свободны .nn_send() всякий раз, когда кто-то чувствует такую ​​потребность, а остальное находится в руках "центрального" процесса.

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

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

Это все, что вам нужно.

Источник
Другие вопросы по тегам