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

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

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

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

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

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

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

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


person janto    schedule 03.02.2016    source источник


Ответы (1)


Да:

<под> . . . может попытаться поохотиться на такого же оленя из противоположного леса

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

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

Значение по умолчанию 0 ( false )

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


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

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

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

Применимые типы сокетов все, только для транспорта, ориентированного на подключение.

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

person user3666197    schedule 07.02.2016