我将使用在Windows上运行的C ++中的客户端/服务器应用程序，服务器本身由“管理器”可执行文件构成，生成一次，“工作”可执行文件产生1到29次，具体取决于配置。
coms位于客户端和“manager”进程之间，“manager”进程和“worker”进程之间（配置它们，将数据发送到进程）以及某些“worker”进程之间。 在旁注：当我说工人流程时，我并不是说流程为超级性能并行完成相同的工作：它们都配置不同，做不同的工作，性能确实不是问题。这里几个过程的分离更多的是稳定性。
现在我不知道选择做什么的网络库。
我知道boost :: asio，我熟悉boost和它的特殊风格，但我担心我团队中的其他成员不是。 我也被建议使用zeroMq。 而且我已经看到了其他一些有利有弊的人。但我有点失落了！
使用zeroMq，我认为我们放弃了asio的主导者？所以在某种意义上它感觉它是较低的水平？ 另一方面，它提供了我认为对我们没用的发布/订阅等功能。
这些库中没有一个能够帮助我们使用序列化部分（交换的数据是异质的）。我认为谷歌协议缓冲区可以在这一点上帮助我们，除非有一个可以做到的所有库？
我们模糊地考虑的其他选择是Corba，amqp。前者感觉笨拙，我们被建议反对它。后者感觉过于复杂。 （？）
有任何建议吗？
答案 0 :(得分：3)
ZeroMQ works just fine与Boost.Asio集成，如果你选择了那条路线。也就是说，我建议您使用Boost.Asio实现您的客户端和服务器，如果这是您熟悉的。这是一个写得很好的图书馆，有很好的文档记录，如果你有问题，它有一个活跃的用户社区（就是我们）。
根据我的经验，大多数倾向于回避Asio的开发人员都不熟悉非阻塞I / O，并且更倾向于使用不依赖于简单示例的每个连接线程方法来设计他们的设计。将您的同事指向Asio examples，将其发送到StackOverflow，以便他们可以阅读boost-asio标记中的问题。如果他们仍然不相信，也许会向他们展示基于Asio的TR2 networking library提案，它可能会在某一天达到标准。
答案 1 :(得分：0)
使用ZMQ，您可能希望使用发布/订阅模型（与zmq 2.2相比，zmq 3.x特别有效，因为3.x执行基于发布的订阅过滤，而2.2执行基于客户端的过滤）。
所有工作人员都会使用SUB套接字连接到管理器（无论他们是什么类型的工作者）并订阅它需要处理的消息。管理器将绑定一个Pub套接字并推出它从客户端收到的所有消息。工作人员只会收到它订阅的消息。这是非常有效的，并且非常诚实地实现这种行为。
如果您有多个工作人员处理相同的消息（性能），您需要创建一个中间“工作人员”，该工作人员订阅该特定消息类型并绑定一个PUSH套接字，其中相同类型的工作人员将使用PULL套接字连接到该中间“worker”（也称为路由器）。这样，当工作人员完成任务时，传入的消息将“排队”并散开。
我可能会从一开始就创建这个中间步骤，以便您可以在没有太多问题的情况下开箱即用（如果真的需要的话）。