2

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

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

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

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

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

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

4

2 回答 2

3

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

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

  1. 你多么不想丢失消息，
  2. 首先，您所说的“丢失的消息”到底是什么意思。

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

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

于 2018-06-17T21:57:24.547 回答
2

With an utmost respect to Margaret HAMILTON's work for Apollo Programme. enter image description here

Yell out.

Dear Dr.,
there are many features, that will become important for a professional decision, that were not mentioned in the shopping-list above.

If the Apollo AGC example could help here, the better.

The package under seek :

  • ought keep your code in control of relative processing-priorities,
  • ought let one increase / decrease / map IO-threads resources-pool usage, per channel,
  • ought let one setup the L3+ transport ToS-prioritisation tagging,
  • ought let one modify O/S configured L3 / L2 stack implementation resources,
  • ought permit non-blocking controls from application programme side, without risks of any deadlocks,
  • ought provide wide portfolio of transport-classes covering { inproc: | ipc: | tipc: | tcp: | udp: | vmci:| pgm: | epgm: } as needed to get employed in a mix

if all that sounds important for your further efforts in Draper Lab, the ZeroMQ will smoothly fit in ( if some latency / performance figures might need boosted on steroids as being more important than the mature mix above, may also enjoy to review Martin Sustrik's another kid, younger than his ZeroMQ - the tools ).

Anyway, if you indeed have (cit.) "... lots of cycles and memory ...", just let me in, I have lots of TFLOP-s to process, if you permit, in the spare time :o)

Nota Bene:

Given the recent comments, let me add a remark on using Naval Research Laboratory published NACK-Oriented Reliable Multicast (NORM) norm:// transport-class, that may help your pure PUB/SUB-design intentions, for which it seems it can fix the desire to "prefer not to lose messages" that is otherwise not taken care off, according to the Zen-of-Zero, which leaves all such operations onto the user-side application code and behaviour.

于 2018-06-15T19:07:08.880 回答