ZeroMQ: как опубликовать несколько получателей, кроме одного из них

У меня есть N подписчики издателя. Сообщение представляет собой простое логическое значение. Шаблон обмена сообщениями немного отличается от обычного PUB/SUB :

  • Когда один подписчик получает true, все остальные подписчики должны получать false.

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

Сейчас у меня есть идея: PUB/SUB отправить false всем, а затем отправить true исключительному подписчику с шаблоном PUSH/PULL или PAIR/PAIR. Но это похоже на взлом.

Будет ли простое решение, основанное на шаблоне PUB/SUB, вместо циклического использования шаблона 1-к-1?


distributed-computing messaging zeromq pyzmq low-latency
person kakyo    schedule 20.05.2020    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

Поэтому, если PUB отправляет сообщение, содержащее один номер, например. «3», пока узел SUB, который является # 3, знает свою собственную идентичность, он получит сообщение «3» и примет его как «истинное», предназначенное для него самого.

Тем временем все остальные узлы SUB также получают сообщение «3», но знают, что они не #3, и поэтому интерпретируют это как ложное, предназначенное для них самих.

У вас могут возникнуть проблемы, если клиентские узлы PUB не смогут узнать свою личность. Но решение этой проблемы кажется довольно простым с помощью конфигурации во время выполнения. Другой способ — использовать XPUB/XSUB и использовать сообщение о подписке от XSUB к XPUB как способ для клиента «заявить о себе» в PUB, но затем немедленно отменить это, чтобы вернуться к пустой теме (чтобы получить каждое сообщение XPUB).

person bazza    schedule 21.05.2020
comment
Ух ты. Звучит супер запутанно. Я думаю, что, вероятно, просто использую логику на стороне приложения для фильтрации с помощью простого цикла. Спасибо за объяснение, хотя. - person kakyo; 21.05.2020
comment
@kakyo Удачи! - person bazza; 21.05.2020
comment
Да, знание - это только первая часть проблемы, следующая - справиться, если не избежать слабо, если не не-управлять всеми дубликатами удостоверений, следующая - как чтобы обнаружить добавленный узел, о котором PUB не знает, которого до сих пор не было, следующим является то, как обнаружить потерянный узел, отправка любых будущих сообщений не имеет значения, но PUB не знает об этом. (Управление подпиской, это тема). В любом случае, если реализация не критична, отправка битового поля с одним и только одним битом ON будет работать для простой передачи сигналов с отображением битовых позиций с наименьшими возможными затратами :o) - person user3666197; 21.05.2020
comment
@bazza Кстати, верно ли ваше предположение немедленно отменить это? AFAIR, тема-фильтр (теперь, в post v4.x+ API, работающем на (X)PUB-стороне) может иметь несколько (много) подписок, поэтому первая из них будет пустой (т.е. подписка на что-либо) + наличие любая следующая тема подписки { id и/или что-то еще, по-прежнему будет доставлять все сообщения на эту (X)SUB-сторону, поскольку -blank по-прежнему соответствует любому такому сообщению, не так ли? ? Таким образом, если мы игнорируем проблемы с управлением динамически (исчезающими) идентификаторами одноранговых узлов, XPUB/XSUB является бесплатным каналом сигнализации. - person user3666197; 21.05.2020
comment
@ user3666197, ах, ты прав. Если можно подписаться на несколько тем, то одна из этих тем может быть предназначена для всех узлов (X)SUB для получения всех сообщений. UUID/GUID звучит как хороший способ гарантировать отсутствие конфликта идентификаторов (например, «3» становится «‹guid string›». Что касается потерянных узлов, неизвестно, будет ли это проблемой для OP, но, возможно, регулярная повторная подписка клиентом Узлы XSUB можно использовать как способ сказать, что я все еще здесь! - person bazza; 21.05.2020
comment
Приятно слышать от вас кусочки мудрости. Как всегда, Салют, сэр! - person user3666197; 21.05.2020

arrow_upward
1
arrow_downward

Вопрос : "Будет ли простое решение, основанное на шаблоне PUB/SUB, вместо циклического использования шаблона 1-к-1?"

О, конечно, будет.

Используйте архетип XPUB/XSUB. Каждый XSUB начинается с отправки своего сообщения "подписка", UUID#-хэша или аналогичным образом.

XPUB, как и .recv()-s XSUB-s "subscription"-сообщение, регистрирует новый одноранговый узел, это UUID#-хеш и в случаях, когда он действительно хочет послать какое-то сообщение именно этому пиру и никакому другому сейчас, он просто .send()-сит такое сообщение, сделав UUID#-хеш, поставленный в качестве бинарного-префикса к нему (т.е. дописав "слева" стороне фактического сообщения, как вы знаете из PUB/SUB ), так как именно так работает фильтрация тем.

Так просто.
Так здорово...

person user3666197    schedule 20.05.2020