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

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

0 голосов
/ 24 июня 2018

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

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

Это в принципе правильно?

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

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

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

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

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

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

Ответы [ 2 ]

0 голосов
/ 27 июня 2018

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

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

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

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

0 голосов
/ 24 июня 2018

Легко:

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

Используйте другой асинхронный канал «снизу вверх», будь то NN_PAIR/NN_PAIR или любой другой, более сложный шаблон масштабируемого архетипического формального общения, например NN_PUSH/NN_PULL или обратный NN_PUB/NN_SUB, который соответствует вашим намерениям и целям латентности.

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

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

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

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

...