Может ли ZeroMQ обеспечить основу для двунаправленной неблокирующей асинхронной передачи?

A1: Да, это возможно в ZeroMQ или nanomsg типах инструментов

И ZeroMQ, и его младшая сестра nanomsg разделяют видение
Масштабируемости (что вы еще не подчеркнули)
Формального (запрограммированного формального поведения)< br>Общение (да, именно об этом)
Шаблон (грамотно вырезанный и готовый к повторному использованию и комбинированию по мере необходимости)

Тем не менее, если вы предпочитаете иметь только один шаблон сокета на каждой «стороне», тогда вам нужно выбрать такой формальный шаблон, который оставил бы вам полную свободу от любого жестко запрограммированного поведения для достижения вашей цели.

Таким образом, a) "...только один" выполним - соло zmq.PAIR (что в некоторых частях документации отмечено как все еще экспериментальное устройство) или NN.BUS или пару PUSH/PULL, если вы откажетесь от разрешения только одного (что на самом деле устраняет все крутые возможности совместного использования zmq.Context() экземпляра потока ввода-вывода( s) для повторного использования низкоуровневого механизма ввода-вывода. Если вы потратите несколько минут на примеры, упомянутые ниже, вы вскоре поймете, что прямо противоположная политика довольно распространена и выгодна для целей проектирования, когда в системной архитектуре используется больше и даже больше шаблонов.

a) "...неблокирующий" выполним, указав правильные директивы zmq.NOBLOCK для соответствующих .send() / .recv() функций и используя быстрые, неблокирующие .poll() циклы в вашем приложении. дизайн архитектуры.

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

На c) "... сбой X после сбоя Y" выполним на { ZeroMQ | nanomsg }-grounds путем тщательного сочетания неблокирующего режима всех функций + вашего дизайна. способен обрабатывать исключения в ситуациях, когда он не получает никаких POS_ACK от предполагаемой { local | remote }-функциональности. Именно в этом отношении будет справедливо отметить, что некоторые из формальныхобычных Cкоммуникационных Pфакторов не обладают такой гибкостью из-за к какому-то обязательному внутреннему поведению, которое "жестко запрограммировано" внутри, поэтому следует с должным вниманием отнестись к выбору правильного FCP-архетипа для каждой такой еще масштабируемой, но отказоустойчивой роли.

Q2: No.

Лучший следующий шаг:

Вас могут заинтересовать другие ZeroMQ сообщений здесь и также не пропустите ссылку на указанную там книгу >>>

Q1: да
Q2: нет, ZMQ_DEALER должен использоваться как приложением X, так и приложением Y. См. http://zguide.zeromq.org/c:asyncsrv. Обратите внимание, что ZMQ_ROUTER в этом примере просто предназначен для распределения запроса от мультиклиента к другому потоку, где ZMQ_DEALER выполняет реальную работу.