ZMQ多线程C客户端

时间：2016-11-03 14:44:59

标签： c multithreading zeromq

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

我看了一眼：

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

但是我没有看到使用多线程ZMQ_DEALER套接字与多线程服务器（ZMQ_ROUTER套接字对话）的客户端示例

所以我正在寻找DEALER和ROUTER模式。我希望客户端（DEALER）是多线程的：

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

或

  • 使用的是 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. 我需要集成第三方应用程序（让我们称之为 3pa ）。 3pa每秒平均发送约4个 HTTP POST 请求（每个请求的大小约为60 KB）给HTTP侦听器（我使用的是mongoose）。< / LI>
  2. 3pa仅在收到HTTP POST＆＃34;回复＆＃34;后发送下一个"HTTP/1.1 200 OK\r\n"发送请求超时后 OR 。所以3pa似乎是单线程的。
  3. 如果我无法快速回复 200 OK ，3pa将继续在内存中排队，直至崩溃。
  4. 当我收到3pa的请求时，我需要使用ZMQ通过3G移动分组网络将其发送到后端服务器。由于3G移动分组网络延迟和带宽，每个请求需要大约1-3秒才能发送，并且大约需要1-3秒才能启动，传输和传送ZMQ重播new ZFrame("OK") 3pa方面。

    5. 因此，如果我们进行基本计算，由于3G-mobile-packet网络性能，3pa队列容量将如此快速地填满。

1 个答案:

答案 0 :(得分：1)

从OP / Update 1中提供的一些细节来看，在谈到增加线程数量的想法之前，让我们先关注问题的根本原因。

什么确实重要？

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

下一步可能，如果3pa重新定位到它自己的NIX-proximity不足以保存游戏，那就是创建o单用途的http-proxy，即可获得那些60KB + http-请求（将被转发到正当目标）并立即将{strong> 200 OK 响应下游注入3pa，以便从内部解锁阻止循环并允许它发送另一个已排队的 HTTP POST 。

脏？是的，不是。它解决了穷人3pa设计的弱点，并允许在特定情况下进行操作。

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

尽管ZeroMQ可扩展正式通信模式构建模块是多方通信方案的智能示例，但不要指望它们不受LoS，丢失消息和其他现实问题的影响。 REQ/REP 模式能够在一个被删除的内部FSA状态中陷入僵局，从中没有（字面上为零）工具来保存/复苏互连的FSA状态机来自一个不可挽回的相互僵局的国家。

在此类设计中使用其他一些可扩展的形式通信模式，并准备好在出现问题时为潜在的抢救状态需求提供额外的信令方式。 ZeroMQ有很多工具可以做到更聪明，而不仅仅依靠一个简单的原型，亲近的眼睛和小说相信一切都将永远没有错误（这不是我们生活的现实，对： o））。

Mixed SIG & TRANSPORT layers

真实客户端运行许多zmq套接字实例，一些用于信令，一些用于传输服务，一些用于远程访问客户端的内部CLI接口，另一些用于分布式日志收集器，一些用于自我诊断和托管系统健康检查。简单的，主要是非阻塞设计的客户端可能包含一些成千上万的SLOC，因此不要指望任何此类解决方案只包含来自库wiki-pages或一些闪亮博客文章的一些SLOC的副本。

  

有人可能还想 read other ZeroMQ posts, ，还有指向神话般的Pieter HINTJENS'书的链接，这是我的必读< / strong>推荐给那些感兴趣的人，因为我开始喜欢ZeroMQ的思维方式和设计优先级。值得信赖的时间和努力，不管你信不信，分布式处理还有其他更重要的规则，而不仅仅是为了设计更糟糕和不可行的设备而要求更多线程。

能够改变糟糕的设计更好的一个，仍然可以运行一个单线程，设计良好的应用程序，可以移动xKB消息并保持端​​到端延迟几十毫秒，即使远程服务器执行复杂的AI / ML“处理”胖“ - 数据有效载荷。

值得一试，不是吗？

相关问题
最新问题