ZeroMQ - Можем ли мы проверить подписчиков перед отправкой сообщения? - PullRequest
0 голосов
/ 09 марта 2020

Шаблон classi c ZeroMQ PUB , это что-то вроде:

  1. форматирование вашего полного сообщения
  2. отправка вашего сообщения
  3. (управляется ZMQ), если есть подписчик на topi c, затем отправьте его, иначе tra sh it?

Что я заметил в одном из моих приложений, так это то, что форматирование некоторых сообщений очень тяжелое и занимает много времени. Когда у меня нет подписчика на topi c, я делаю всю эту работу даром.

Мне было интересно, есть ли способ проверить, подписан ли topi c перед форматированием остальная часть сообщения.

Я понимаю, что возникнет проблема TOCTOU:
1. проверьте, подписан ли topi c (это не так)
2. (ZMQ получает подписку на topi c)
3. данные не отправляются ...

или
1. проверьте, подписан ли topi c (он есть)
2. start форматирование сообщения
3. (ZMQ получает отмену подписки на topi c)
4. отправка в сокет, данные не отправляются (потерянное время)

... и я в порядке с обоими.

Я пробовал с сообщениями, состоящими из нескольких частей (отправив сначала "header / topi c" без форматирования остальной части сообщения), но:
- это похоже, здесь не то, что я имею в виду
- мои подписчики также должны обрабатывать сообщения, состоящие из нескольких частей (могут делать простые zmq_recv()), что немного раздражает нг

Есть идеи? Я думаю, что вижу, где патчить xpub.cpp, добавив метод, который будет копировать / вставлять часть xpub::xsend() (https://github.com/zeromq/libzmq/blob/656205b5f9159677d325cff5e6e26c97f95d8cd7/src/xpub.cpp#L289), но я даже не уверен, что это то, что сообщество ZMQ будет заинтересованы в.

1 Ответ

0 голосов
/ 10 марта 2020

В случае, если кто-то никогда не работал с ZeroMQ,
здесь можно получить удовольствие от первого взгляда на "Принципы ZeroMQ * менее чем за Пять секунд"
, прежде чем углубляться в детали



Q : " Можем ли мы проверить подписчики до отправки сообщения? "

Да, мы можем.

Если это действительно необходимо, остерегайтесь XPUB Archetype собирает входящие сообщения управления подпиской (если они поступают), пригодные для выполнения чего-то подобного.

Это не означает, что можно оставаться в стороне и полагаться на это. Если только в полностью ограниченной среде, где жесткие политики контроля версий и обеспечения соблюдения правил являются строгими и действующими, всегда может существовать клиент, который не использует более новую, измененную версию, которая выполняет topi c - фильтрация на стороне (X)PUB. Учитывая такую ​​возможность, фильтр SUB-стороны topi c должен быть полностью смоделирован, если он доставляет все записи управления подписками на сторону (X)PUB, как ожидают более новые версии, перед тем, как начать слепо "верить" в такую ​​политику test-before-send .

Проклятое управление версиями: o)

Вы также можете знать, что topi c - filtering (поскольку, как мы надеемся, так и останется) не требует никакого форматирования тем меньше накладных расходов на обмен сообщениями. Он работает как простое сопоставление битовых полей, производительность которого была настроена, так что, кто бы когда-нибудь хотел потратить хоть один [ns] дополнительных накладных расходов в этом домене?

Добро пожаловать в Искусство Дзэн-оф-Ноль

...