NanoMsg (NNG) 和 FlatBuffers 是否适合这个项目？

Question

大声喊出我们应该考虑的更好的东西：

我正在寻找一种非常快速和简单的方法来获取多个程序（例如 5 个）——每个程序都运行在私有 OpenStack 云上的不同节点上以相互通信。

• 数据包将是简短的 C++ 结构（小于 100 字节）
• 流量会很少（可能低于 100/秒）
• 延迟确实不是问题。 （朋友之间的几毫秒是多少？） - 我们有很多周期和记忆
• 消息应该作为发布/订阅客户端/服务器范式完成
• 库应该是 C++ 友好的。但可在 Windows 和 Linux 上运行
• 我们稍后可能需要额外的语言绑定
• 我们不希望丢失消息

这是我的第一个想法。但如果你有其他东西可以提供。大声喊出来。

UDP 套接字层的友好包装器：

• NanoMSG（NNG，因为它是 nanoMsg 的活跃项目）https://github.com/nanomsg/nng

C++ 结构数据的编码器/解码器：

• 平面缓冲区https://google.github.io/flatbuffers/

Answer 1

对于序列化，几乎任何具有正确语言绑定的东西都可以。 Google Protocol Buffers 与语言无关，有很多可用的绑定。唯一要避免的是源代码中内置的序列化（就像 Boost 的序列化是 / was），因为那样你就不能轻易地将它移植到另一种语言。

对于消息传输，ZeroMQ、NanoMsg 是不错的选择。但是，我认为这真的归结为

1. 您多么不想丢失消息，
2. 首先就是您所说的“丢失的消息”。

ZeroMQ（和 NanoMsg）的问题是（AFAIK）当故障发生时没有真正的方法知道消息的命运。例如，在 ZeroMQ 中，如果您发送一条消息，而接收方恰好正在工作并已连接，则消息将通过连接传输。发送端现在认为工作已经完成，消息已经传递。但是，除非并且直到接收端实际调用zmq_recv() 并完全处理它收到的内容，否则如果接收端进程崩溃，或者出现电源故障等，消息仍然会丢失。这是因为直到它被消耗消息存储在 ZeroMQ 运行线程内的 RAM 中（在各自的 Context()-instance 的控制域内）。

您可以通过让某种 ack 消息以另一种方式返回、超时等来解决此问题。但这开始变得很棘手，您最好使用 RabbitMQ 之类的东西。

Answer 2

非常尊重玛格丽特·汉密尔顿为阿波罗计划所做的工作。

喊出来。

尊敬的博士，
上面的购物清单中没有提到许多对专业决策很重要的功能。

如果 Apollo AGC 示例在这里能有所帮助，那就更好了。

seek 下的包：

• 应该让您的代码控制相关的处理优先级，
• 应该让每个通道增加/减少/映射 IO 线程资源池使用情况，
• 应该让我们设置 L3+ 传输 ToS 优先级标记，
• 应该让我们修改 O/S 配置的 L3/L2 堆栈实现资源，
• 应该允许来自应用程序端的非阻塞控制，没有任何死锁的风险，
• 应该提供广泛的传输类组合，涵盖 { inproc: |个人电脑：|提示：| tcp: | udp：|虚拟机：|计划：| epgm: } 根据需要在混合中使用

如果这一切听起来对您在 Draper Lab 的进一步努力很重要，ZeroMQ 将顺利适应（如果某些延迟/性能数据可能需要在类固醇上提高，因为比上面的成熟组合更重要，也可能喜欢评论 Martin Sustrik 的另一个孩子，比他的 ZeroMQ 还小——nanomsg 工具）。

---

不管怎样，如果你确实有(cit.)“...很多循环和记忆...”，请让我进去，我有很多TFLOP-s 处理，如果你允许，在空闲时间:o)

---

Nota Bene：

鉴于最近的 cmets，让我补充一点关于使用海军研究实验室发布的面向 NACK 的可靠多播 (NORM) norm:// 传输类，这可能会对您的纯 PUB/SUB- 有所帮助设计意图，它似乎可以解决“不希望丢失消息”的愿望，否则不会被照顾，根据 Zen-of-Zero ，这会将所有此类操作留给用户端应用程序代码和 distributed-system 行为。