ZeroMQ: Рекомендуемый шаблон для клиентов inproc из нескольких потоков, отправляющих упорядоченные сообщения на сервер? - PullRequest
1 голос
/ 07 ноября 2019

Мои требования

  • Клиенты из разных потоков в одном процессе
  • Сервер в отдельном потоке в одном процессе
  • Клиенты выдают сообщения на сервер
  • Сервер использует сообщения, распечатывая их в порядке отправки по мировым часам на стороне источника, прозрачный для потоков и любого планирования.

Ответы на вопросы, такие как

высказывать разные мнения. Поэтому я должен просто попросить клиентов нажать PUSH на один inLL-сервер PULL, созданный в другом потоке, или использовать шаблон роутер-дилер?

И в одном из комментариев второго вопроса я получаю STREAMER pattern , который, кажется, существует в pyzmq, но я не уверен, является ли это правильным решением или этодоступно с C API вообще?

1 Ответ

0 голосов
/ 07 ноября 2019

Q : Рекомендуемый шаблон для клиентов inproc из нескольких потоков, отправляющих заказанные сообщения на сервер?

Любой ответ на такой сформулированный вопросзависит от недостающей части информации: каковы установленные предпочтения, которые приводят к различию между недостаточным, достаточным, лучшим и лучшим решением для вышеописанных операций.

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

Вам нужно обрабатывать статический или динамический набор клиентов?

Предпочитаете ли вы производительность по сравнению с объемом оперативной памяти?


Без какого-либо из перечисленных «критериев» серьезный человек никогда не «порекомендует», поскольку любое такое утверждение будет справедливым мнением.

PUSH/PULL может быть достаточнодля неподтвержденной доставки (вариант использования оптимистической слепоты, если в производстве приемлема философия дизайна вне поля зрения ума)

PAIR/PAIR может быть достаточно для быстрого .poll( ZeroWait, ZMQ_POLLIN ) серверного сканера, с возможностью отправки POSACK-ответов на стороне сервера соответствующим потокам клиента, чьи сообщения были доставлены и приняты для обработки на стороне сервера (определяемое пользователем сообщение-подтверждениепротокол рукопожатия, обработка POSACK / NACK-таймаутов / эскалаций не по порядку и т. д. выходит за рамки данного поста)

PUB/SUB или XPUB/XSUB может быть достаточно для более сложного управления тематикой сигнализации, двунаправленной в X-версиях, если это оправдывает дополнительные затраты на фильтрацию тем (в зависимости от версии ZeroMQ, независимо от того, распространяется ли она по всем клиентским потокам или централизованно)на стороне сервера)

Решение за вами.

...