【问题标题】:Can multicast be used with reliable messaging in OMG DDS standard, or is unicast required?多播可以与 OMG DDS 标准中的可靠消息传递一起使用,还是需要单播?
【发布时间】:2023-12-31 20:55:01
【问题描述】:

我目前正试图弄清楚我编写的 DDS 应用程序。

我的作者和读者目前已启用可靠性,因此如果读者错过了一条消息,作者将重新发布该消息。我也在使用默认的多播,而不是使用单播来发现发布者和订阅者。

根据多播协议,我只使用端口70007001 需要打开。然而,当我使用wireshark 进行分析时,我看到端口70107011(单播)端口也是打开的。

经过一番挖掘,我发现了这个link,似乎要为读取器和写入器使用可靠性,您需要启用单播,这就是为什么单播端口也打开并被使用的原因。

是否真的必须启用单播才能可靠地传递消息?如果需要,为什么需要这样做,以及为什么多播不能执行此功能?

【问题讨论】:

  • 我认为使用可靠协议时对单播的要求是一个实现细节。当然可以实现该协议,使得可靠性消息(Heartbeat 和 AckNack)通过多播传送;但这可能不是大多数情况下的最佳配置。
  • @CTucker 说了什么。

标签: publish-subscribe multicast data-distribution-service unicast


【解决方案1】:

在这种情况下,大部分流量将通过 MC 流出。有时,可靠性协议会发送一条消息,实际上是“我有可用的序列号 N 到 M。”

每个阅读器(这在不同的实现中是可调的)都会以“ok”或“我没有得到 x 或 z”的内容(通过单播!)做出响应。

如果只有一个读者没有得到 x,那么 MC 修复样本 x 是没有意义的,因为只有一个读者需要它。所以作者会将它单播给吱吱作响的读者。

简而言之,我可以再花 10 段来讨论配置选项和调整行为。

但是是的 tl;dr:预期的行为。

【讨论】:

  • 谢谢!这就是我的想法,但我不想只是猜测技术报告的说法。
最近更新 更多