ZeroMQ: Как установить HWM, чтобы он стал действительно "нулем" (не API def'd 0 == INFINITY)?

Question

У меня вопрос по поводу максимальной отметки (HWM) для ZeroMQ PUB/SUB подключение. Эффективно хочу установить HWM значение до нуля.

То есть: если сообщение не может быть доставлено, просто отбросьте его.

К сожалению, кажется, что HWM значение может быть установлено только как 1,
" 0 "означает бесконечность в соответствии с документами API и моим тестированием.

На мой взгляд, используя 0 "означать" бесконечный "в API было ошибкой:/
Это вряд ли изменится.

Есть ли обходной путь, который не требует перекомпиляции ZeroMQ ?

Проблема, с которой я сталкиваюсь, заключается в том, что с ненулевым HWM при сбое соединения по крайней мере одно сообщение находится в очереди и отправляется после восстановления соединения. К этому времени сообщение больше не является действительным и ему нельзя доверять.

Я думал об отбрасывании сообщений на принимающей стороне, включая метку времени, сгенерированную на отправляющей стороне. К сожалению, системные часы не подключены к Интернету и значительно дрейфуют. Синхронизация часов с дополнительным REQ/REP Сокет представит отправителю другие сложные состояния запуска и выглядит как ненужный обходной путь.

Answer 1

Да:

_{, , , может попытаться охотиться на того же оленя из противоположного леса}

Исходя из необходимости,
заявленная в исходной задаче мотивация,
решение может быть получено из установки не ZMQ_???HWM,
но другой параметр:

ZMQ_CONFLATE: Сохранить только последнее сообщение

Значение по умолчанию 0 (ложный)

Применимые типы сокетов ZMQ_PULL, ZMQ_PUSH, ZMQ_SUB, ZMQ_PUB, ZMQ_DEALER

_{Если установлено, сокет должен хранить только одно сообщение в своей входящей / исходящей очереди, причем это сообщение является последним полученным сообщением / последним отправленным сообщением. Игнорирует} ZMQ_RCVHWM _{а также} ZMQ_SNDHWM _{опции.
Не поддерживает многокомпонентные сообщения, в частности, только одна его часть хранится во внутренней очереди сокетов.}

и некоторая помощь может исходить от "превентивной меры", скрытой в:

ZMQ_IMMEDIATE: Очередь сообщений только для завершенных подключений

Все применимые типы сокетов, только для транспортов с установлением соединения.

_{По умолчанию очереди исходящих подключений будут заполняться, даже если подключение еще не завершено. Это может привести к "потерянным" сообщениям в сокетах с циклической маршрутизацией (REQ, PUSH, DEALER).
Если эта опция установлена ​​в 1, сообщения должны быть поставлены в очередь только для завершенных соединений. Это приведет к блокировке сокета, если нет других подключений, но предотвратит заполнение очередей в каналах, ожидающих подключения.}