Что заставляет сокет REQ НЕ получать ответы от REP?

Question

Я реализовал шаблон ленивого пирата для своего клиентского модуля, который отлично подходит для повторных запросов. Но вот в чем проблема.

1. REQ Client отправляет сообщение на сервер REP. [OK]
2. Сервер REP интерпретирует сообщение. [OK]
3. Сервер REP выполняет какое-то действие и готовит ответ. [OK]
4. Сервер REP отправляет ответ. [OK]
5. REQ Клиенты опрашивают сообщение, но не получают его до истечения времени ожидания. [НЕ ОК]
6. REQ Клиент перезапускает сокет и снова пытается отправить запрос. [НЕ ОК]
7. Сервер REP снова выполняет действие. [ПРОБЛЕМА]
8. На этот раз REQ Client успешно получает ответ. [OK]

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

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

У меня также есть несколько таких клиентов, подключенных к серверу, может ли это быть проблемой?

Спасибо!

Answer 1

Q1 : "Может ли это _{... сосуществование на основе сопрограмм ...} быть причиной этого?"

Да,
в основном, если сопрограммы используют один и тот же экземпляр REQ -архетипа.

Q2 : "... может ли это _{... несколько таких клиентов подключены к серверу ...} быть проблемой? "

Нет,
при условии, что каждый клиент работает с собственным экземпляром REQ -архетипа, подключенного к REP - (сервер), не должно быть причин для неминуемых блокировок (подробнее см. REQ/REP принципиальная вероятность попасть в безнадежный взаимный тупик, где единственное, чего вы не можете знать, это когда это произойдет, но мы все можем быть уверены, что это произойдет)

Если требуется atomi c, одноэлементное уникальное выполнение (и если реализация сервера позволяет это), можно регистрировать каждую задачу REQ - {UUID}, чтобы предотвратить двойное -шоты на одну и ту же цель-задачу.

Трудно сказать больше, без реального MCVE / MWE-представления проблемы (.poll -ing l oop logi c / таймаут / стратегии-исправления)

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