我需要一个可靠地为多个客户端服务的单个服务器的架构，客户端响应无响应的服务器，类似于0MQ指南中的懒惰盗版模式（即，他们使用zmq_poll轮询回复;如果超时，则断开连接并重新连接客户端套接字并重新发送请求。）
我采取了＆＃34;懒惰的海盗模式＆＃34;作为起点，来自ZMQ C语言示例目录（lpclient.c和lpserver.c）。从lpserver.c中删除了模拟的故障内容，以便它可以正常运行而不模拟崩溃，如下所示：
服务器有一个简单的循环：
- 从套接字中读取下一条消息
- 做一些模拟工作（1秒睡眠）
- 回复称已提供服务
客户端有简单的循环：
- 向服务器发送请求
- 运行zmq_poll以检查具有某些设置超时值的响应
- 如果超时已超时，请断开并重新连接以重置连接并在下一次循环迭代开始时重新发送请求
这对一两个客户来说非常有用。然后我尝试通过运行它们来为20个客户服务：
$ ./lpserver＆amp;
$ for i in {1..20} 做 ./lpclient＆amp; 完成
我得到的行为是：
- 客户端都发送请求并开始轮询回复。
- 服务器在收到的第一条消息上执行一秒钟的工作，然后回复
- 第一个客户端收到其响应并发送新请求
- 服务器对其获得的第二条消息执行一秒钟的工作，然后回复
- 第二个客户端收到其回复并发送新请求
- 服务器接收第三个客户端的请求，但第三个客户端在工作完成之前超时（2.5秒超时，服务器工作时间为1秒，因此第三个请求客户端开始退出）。
- 多个客户端（第四到第N个）超时并重新发送请求。
- 服务器继续处理来自传入消息队列的失效请求并执行占用服务器的工作，导致所有客户端最终超时，因为需要20秒才能通过所有已解除的消息来完成每一轮队列。< / LI>
最终所有客户端都已死亡，服务器仍在吐出对已失效连接的响应。这很糟糕，因为服务器不断响应客户端放弃的请求（因此不应该期望已经完成工作），并且花费所有这些时间来处理死请求可以保证所有未来的客户端请求都会超时。
这个例子是作为一种处理多个客户端和单个服务器的方式而提出的，但它根本不起作用（我的意思是，如果你做得很快并且有很长的超时，你会有一些错觉可靠性，但很容易想象这种灾难性的崩溃在这种设计下的重头戏。）
那么什么是一个好的选择呢？是的，我可以缩短工作所需的时间（如果需要可以缩短工作线程）并延长超时时间，但这并没有真正解决核心缺点 - 只是降低其可能性 - 这不是解决方案
我只需要一个简单的请求/回复模式来处理多个客户端和一个服务器，它按照接收的顺序按顺序处理请求，但是在服务器的情况下客户端可以可靠地超时花费太长时间，服务器不会浪费资源来响应已失效的请求。