NanoMsg (NNG) 和 FlatBuffers 是否适合这个项目？
NanoMsg (NNG) & FlatBuffers the correct fit for this project?
如果有更好的我们应该考虑，请大声说出来：
我正在寻找一种非常快速和简单的方法来获取多个程序（例如 5 个）- 每个 运行 在私有 OpenStack 云上的不同节点上相互通信。
- 数据包将是短的 C++ 结构（小于 100 字节）
- 流量会很轻（可能低于 100/秒）
- 延迟确实不是问题。 （朋友之间的几毫秒是多少？）-我们有很多周期和内存
- 消息应该按照 pub/sub client/server 范式
- 库应该是 C++ 友好的。但是在 Windows 和 Linux
上工作
- 稍后我们可能需要额外的语言绑定
- 我们不希望丢失消息
这是我的第一个想法。但是如果你有别的东西可以提供。大声喊出来。
UDP 套接字层的友好包装器：
- NanoMSG（NNG 因为它是 nanoMsg 的活跃项目）https://github.com/nanomsg/nng
Encoder/Decoder 对于 C++ 结构数据：
- FlatBuffers https://google.github.io/flatbuffers/
Yell out.
亲爱的博士，
上面 shopping-list 中没有提到的许多功能对于做出专业决定很重要。
如果 Apollo AGC 示例可以帮助到这里，那就更好了。
正在寻找的包：
- 应该让您的代码控制相对 processing-priorities,
- 应该增加/减少/映射 IO-threads resources-pool 每个通道的使用情况，
- 应该设置 L3+ 传输 ToS-prioritisation 标记，
- 应该修改O/S 配置的 L3/L2 堆栈实现资源，
- 应该允许 non-blocking 从应用程序端进行控制，没有任何死锁的风险，
- 应该提供广泛的 transport-classes 产品组合，涵盖 { inproc: |工业电脑： | tipc： | TCP: |开发计划署： |虚拟机：| PGM： | epgm: } 根据需要加入混音
如果这一切听起来对你在 Draper Lab 的进一步努力很重要，那么 ZeroMQ 将顺利融入（如果某些延迟/性能数据可能需要在类固醇上得到提升，因为它比上面的成熟组合更重要，也可能喜欢回顾 Martin Sustrik 的另一个孩子，比他的 ZeroMQ 更年轻——nanomsg 工具）。
无论如何，如果你确实有 (cit.) “...大量的循环和内存...”，只是让我进来，我有很多TFLOP-s要处理，如果你允许的话，在空闲时间:o)
诺塔贝内：
鉴于最近的评论，让我对使用海军研究实验室发表的 NACK-Oriented 可靠多播 (NORM) norm:// transport-class，这可能有助于您纯粹的 PUB/SUB-设计意图，为此它似乎可以解决 “不想丢失消息[=57”的愿望=]”，根据 Zen-of-Zero，将所有此类操作留给 user-side 应用程序代码和 distributed-system行为。
对于序列化，几乎任何具有正确语言绑定的东西都可以。 Google Protocol Buffers 与语言无关，有很多可用的绑定。唯一要避免的是你的源代码中内置的序列化（就像 Boost 的序列化是/曾经是），因为那样你就不能轻易地将它移植到另一种语言。
对于消息传输，ZeroMQ、NanoMsg 都是不错的选择。但是，我认为这真的归结为
- 您多么不想丢失消息，
- 首先 "lost message" 正是您的意思。
关于 ZeroMQ（和 NanoMsg）的事情是（AFAIK）当发生故障时没有真正的方法知道消息的命运。例如，在 ZeroMQ 中，如果您发送一条消息，而接收方恰好正在工作并处于连接状态，则该消息将通过连接进行传输。发送端现在认为工作已经完成，消息已经传递。但是，除非并且直到接收端实际调用 zmq_recv() 并完全处理它收到的内容，否则如果接收端进程崩溃，出现电源故障等，消息仍然会丢失。这是因为直到它被消费后，消息存储在 ZeroMQ 运行 线程内的 RAM 中（在相应的 Context()-实例的控制域内）。
您可以通过让某种 ack 消息以另一种方式返回、超时等来解决这个问题。但这开始变得繁琐，您最好使用 RabbitMQ 之类的东西。
如果有更好的我们应该考虑，请大声说出来：
我正在寻找一种非常快速和简单的方法来获取多个程序（例如 5 个）- 每个 运行 在私有 OpenStack 云上的不同节点上相互通信。
- 数据包将是短的 C++ 结构（小于 100 字节）
- 流量会很轻（可能低于 100/秒）
- 延迟确实不是问题。 （朋友之间的几毫秒是多少？）-我们有很多周期和内存
- 消息应该按照 pub/sub client/server 范式
- 库应该是 C++ 友好的。但是在 Windows 和 Linux 上工作
- 稍后我们可能需要额外的语言绑定
- 我们不希望丢失消息
这是我的第一个想法。但是如果你有别的东西可以提供。大声喊出来。
UDP 套接字层的友好包装器：
- NanoMSG（NNG 因为它是 nanoMsg 的活跃项目）https://github.com/nanomsg/nng
Encoder/Decoder 对于 C++ 结构数据：
- FlatBuffers https://google.github.io/flatbuffers/
Yell out.
亲爱的博士，
上面 shopping-list 中没有提到的许多功能对于做出专业决定很重要。
如果 Apollo AGC 示例可以帮助到这里，那就更好了。
正在寻找的包：
- 应该让您的代码控制相对 processing-priorities,
- 应该增加/减少/映射 IO-threads resources-pool 每个通道的使用情况，
- 应该设置 L3+ 传输 ToS-prioritisation 标记，
- 应该修改O/S 配置的 L3/L2 堆栈实现资源，
- 应该允许 non-blocking 从应用程序端进行控制，没有任何死锁的风险，
- 应该提供广泛的 transport-classes 产品组合，涵盖 { inproc: |工业电脑： | tipc： | TCP: |开发计划署： |虚拟机：| PGM： | epgm: } 根据需要加入混音
如果这一切听起来对你在 Draper Lab 的进一步努力很重要，那么 ZeroMQ 将顺利融入（如果某些延迟/性能数据可能需要在类固醇上得到提升，因为它比上面的成熟组合更重要，也可能喜欢回顾 Martin Sustrik 的另一个孩子，比他的 ZeroMQ 更年轻——nanomsg 工具）。
无论如何，如果你确实有 (cit.) “...大量的循环和内存...”，只是让我进来，我有很多TFLOP-s要处理，如果你允许的话，在空闲时间:o)
诺塔贝内：
鉴于最近的评论，让我对使用海军研究实验室发表的 NACK-Oriented 可靠多播 (NORM) norm:// transport-class，这可能有助于您纯粹的 PUB/SUB-设计意图，为此它似乎可以解决 “不想丢失消息[=57”的愿望=]”，根据 Zen-of-Zero，将所有此类操作留给 user-side 应用程序代码和 distributed-system行为。
对于序列化，几乎任何具有正确语言绑定的东西都可以。 Google Protocol Buffers 与语言无关，有很多可用的绑定。唯一要避免的是你的源代码中内置的序列化（就像 Boost 的序列化是/曾经是），因为那样你就不能轻易地将它移植到另一种语言。
对于消息传输，ZeroMQ、NanoMsg 都是不错的选择。但是，我认为这真的归结为
- 您多么不想丢失消息，
- 首先 "lost message" 正是您的意思。
关于 ZeroMQ（和 NanoMsg）的事情是（AFAIK）当发生故障时没有真正的方法知道消息的命运。例如，在 ZeroMQ 中，如果您发送一条消息，而接收方恰好正在工作并处于连接状态，则该消息将通过连接进行传输。发送端现在认为工作已经完成，消息已经传递。但是，除非并且直到接收端实际调用 zmq_recv() 并完全处理它收到的内容，否则如果接收端进程崩溃，出现电源故障等，消息仍然会丢失。这是因为直到它被消费后，消息存储在 ZeroMQ 运行 线程内的 RAM 中（在相应的 Context()-实例的控制域内）。
您可以通过让某种 ack 消息以另一种方式返回、超时等来解决这个问题。但这开始变得繁琐，您最好使用 RabbitMQ 之类的东西。