【问题标题】:Joining a source specific multicast on same multicast address在相同的多播地址上加入特定源的多播
【发布时间】:2015-04-29 16:38:51
【问题描述】:

我正在尝试使用源特定多播 (SSM) 为 linux 上的应用程序设置多播源,并且代码运行正常(使用 C 接口),但我想验证系统的行为是否符合我的预期到。

设置:
多播地址 - 233.X.X.X:9876
源 1 - 192.X.X.1
源 2 - 192.X.X.2
接口 1 - 192.X.X.100
接口1 - 192.X.X.101

步骤

  1. 配置以便只有 Source1 发送到多播地址
  2. 启动一个读卡器(reader1),绑定多播地址,以ssm src作为Source1,interface作为Interface1加入多播
  3. 观察在 reader1 上可以看到数据
  4. 做同样的事情 (reader2) 但使用 Source2 和 Interface2

期望的结果:
Reader1 可以看到来自多播的数据。
Reader2 看不到来自多播的数据。

我担心上述情况不会发生,因为在我使用非特定源多播的测试中,IP_ADD_MEMBERSHIP 具有全局影响。所以 reader2 的套接字可以看到数据,因为它绑定到唯一的多播地址,该地址已加入到查看数据的接口。 this link under "Joining a Multicast" 的信息与我的观察相符。

很可能 IP_ADD_SOURCE_MEMBERSHIP 的行为与 IP_ADD_MEMBERSHIP 不同,但文档很少而且在这方面没有具体说明。

具体问题:

  1. 是使用 IP_ADD_SOURCE_MEMBERSHIP 全局的多播连接,即会导致绑定到多播地址的任何套接字绑定()从该源接收数据包。
  2. 一般应该如何使用 SSM?一个多播地址有 N 个源有意义吗?

我对网络编程没有经验,所以请原谅我理解的任何不足。

感谢您的帮助。

【问题讨论】:

    标签: c linux sockets networking multicast


    【解决方案1】:

    我已经解决了这个问题,在获得Unix Network Programming 的副本后,这种行为至少看起来清晰易懂。

    1. 答案是肯定的,所有多播连接都是全局的,无论它们是 SSM 还是其他。这样做的原因是,连接实际上在发出连接请求的进程之后的几层中生效。基本上,它告诉 IP 层接受来自指定源的多播数据包,并将它们提供给绑定到具有多播地址的套接字的任何进程。

    2. 由于 IPv4 的地址空间有限,实际上引入了 SSM。当在互联网上使用多播时,几乎没有足够的唯一多播地址,以至于每个想要使用的人都可以拥有一个唯一的地址。 SSM 将源地址与多播地址配对,后者作为一对形成全球唯一标识符,即共享多播地址,例如239.10.5.1 和源 192.168.1.5。所以 SSM 存在的原因纯粹是为了在有限的地址空间中促进多播。在我们的软件在(Cisco)中运行的环境中,SSM 被用于冗余和传输便利,在同一个 IP:port 组合上堆叠多个数据流,并让下游客户端选择他们想要的流。这一切都很好,直到给定的主机想要访问多播中的多个流,因为它们都在同一个多播地址上,所有订阅的进程都获取所有数据,由于网络堆栈的工作方式,这是不可避免的.

    3. 最终解决方案
      既然已经理解了行为,解决方案就很简单了,但是在每个运行的进程中确实需要额外的代码。每个进程必须过滤来自多播地址的传入数据,并且只从他们感兴趣的源中读取数据。我曾希望 SSM 中内置了一些“魔法”来自动执行此操作,但没有. recvfrom() 已经提供了发件人地址,因此这样做成本相对较低。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-05-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-02-26
      相关资源
      最近更新 更多