c - ZMQ 多线程 C 客户端

Question

我想要多线程 zmq 客户端的 C 示例，我已经在使用多线程服务器，但我有要求让每个客户端从多线程而不是从单个线程发送请求。

我看过:

http://zguide.zeromq.org/c:asyncsrv
https://github.com/booksbyus/zguide/blob/master/examples/C/

但我没有看到使用 ZMQ_DEALER 套接字的多线程与多线程服务器(一个 ZMQ_ROUTER 套接字)通信的客户端示例

所以我正在寻找 DEALER 和 ROUTER 模式。我希望客户端(DEALER)是多线程的:

• 如果我遵循与多线程服务器示例相同的类比，我需要一个绑定(bind)多个经销商线程的代理，对吗？

或

• 使用 pthread_create 就够了吗？

目前我的客户端类似于hello world C:

zctx_t ctx = zctx_new ();
void *client = zsocket_new (ctx, ZMQ_REQ);
assert (client);
zsocket_connect (client, config.SERVER_ENDPOINT);

// SKIPPED: I get the data (hm->body.p) to be send through zmq...

// We send a request, then we work to get a reply

zstr_sendf(client, "%.*s", (int) hm->body.len,hm->body.p);

char *reply = zstr_recv (client);
if (  reply ) {
      zsys_info ("server replied (%s)", reply);
      free (reply);
} 

请帮助我使我的 C 客户端成为多线程 zmq 客户端。

更新 1(更多详细信息):

1. 我有一个需要集成的第 3 方应用程序(我们称它为 3pa )。 3pa 平均每秒发送约 4 个 HTTP POST 请求(每个请求的大小约 60 KB)到 HTTP 监听器(我正在使用 mongoose ).
2. 3pa 仅在收到 "HTTP/1.1 200 OK\r\n" "reply"< 后发送下一个 HTTP POST strong>OR 在发送请求超时后。所以3pa似乎是单线程的。
3. 如果我无法快速响应 200 OK，3pa 将继续在内存中排队，直到崩溃。
4. 当我收到来自 3pa 的请求时，我需要使用 ZMQ 通过 3G 移动数据包网络将其发送到后端服务器。由于 3G-mobile-packet 网络延迟和带宽，每个请求需要大约 1-3 秒才能发送，ZMQ 重放大约需要 1-3 秒 new ZFrame("OK") 到启动、传输和交付(在 3pa 端接收)。

因此，如果我们进行初等微积分，由于 3G 移动分组网络性能，3pa 队列容量将很快被填满。

Answer 1

根据 OP/Update 1 中提供的一些细节，
让我们先关注问题的根本原因，
然后再讨论增加线程数的想法。

---

真正重要的是什么？

鉴于 3pa 已作为 BlackBox 引入，具有经验丰富的阻塞设计(由永远等待表示，直到交付200 OK，在超时事件时逃逸)
最好的第一步将操作 3pa 按原样，而是托管/托管在一些更好的 NIX 对等/托管中心，而不是延迟昂贵的 3G 移动数据包 radio 接入网络的当前“外围”最后一英里部分，这将两者都避免/防止容量驱动的 DoS 引入的数据包重新传输，以防任何优先调用流量抢占 3G 信道并使 RAN 拥塞，并且绝对会降低往返延迟的成本，目前在某个地方支付的上述水平以上2~6+秒。

下一步可能，如果 3pa 搬迁到 NIX-proximity 本身不足以拯救游戏，将创建一个单一用途的 http-proxy，它将接收那些60KB+ http 请求(然后将中继到适当的目标)并且会立即将 200 OK 响应下游注入(inject) 3pa，以便将其从内部阻塞循环中解锁，并允许其发送另一个出列的 HTTP POST。

肮脏？是和不是。它解决了糟糕的 3pa 设计的弱点，并允许在特定情况下运行它。

---

最后一点 - 在真实场景中尽量避免使用 REQ/REP 模式。

虽然 ZeroMQ 可扩展正式通信模式构建 block 是多方通信方案的智能示例，但不要指望它们不受 LoS、丢失消息和其他现实世界问题的影响。 REQ/REP 模式能够在脱轨的内部 FSA 状态下自行死锁，从中没有(字面上为零)工具来保存/恢复内部 -来自无法挽救的相互死锁状态的孪生 FSA 状态机。

在此类设计中使用其他一些可扩展的正式通信模式，并准备好在出现问题时提供额外的信号发送方式，以表示可能需要挽救状态。 ZeroMQ 有很多工具可以更聪明地做到这一点，而不是仅仅依赖于一个简单的原型(prototype)，闭上眼睛并相信一切都将永远无错误地工作的小说(这不是我们生活的现实，对吧: o)).

真实世界的客户端操作许多 zmq-socket 实例，一些用于信号，一些用于传输服务，一些用于远程访问客户端的内部 CLI 界面，一些用于分布式日志收集器，一些用于 self 诊断和托管系统健康检查。简单的、主要是非阻塞设计的客户端可能包含几千个 SLOC，所以不要期望任何此类解决方案仅包含来自图书馆 wiki 页面或一些 Shiny 的博客文章的几个 SLOC 的副本。

One might also like to read other ZeroMQ posts, with also a link to the fabulous Pieter HINTJENS' book, that has been my must-read recommendation for those interested since I started to love the ZeroMQ way of thinking and design priorities. Worth the time and efforts, believe me or not, distributed processing has other, more important rules, than just asking for more threads for otherwise poor and un-feasible design.

Being able to change a poor design into a better one, one can still operate a single-threaded, well designed, application that can move xKB-messages and keep the end-to-end latencies under a few tens of milliseconds, even with a remote server doing a complex AI/ML-processing of the "fat"-data payloads.

Worth a try, isn't it?