加入同一多播地址上的源特定多播

rad*_*man 4 c sockets linux networking multicast

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

设置:
多播地址 - 233.XXX:9876
源 1 - 192.XX1
源 2 - 192.XX2
接口 1 - 192.XX100
接口 1 - 192.XX101

脚步

  1. 配置为仅 Source1 发送到多播地址
  2. 启动绑定到多播地址的读取器 (reader1) 并加入多播,其中 ssm src 作为 Source1,接口作为 Interface1
  3. 观察在 reader1 上看到数据
  4. 执行相同的操作 (reader2),但使用 Source2 和 Interface2

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

我担心上述情况不会出现,因为在我使用非源特定多播的测试中,IP_ADD_MEMBERSHIP 具有全局效果。因此 reader2 的套接字可以看到数据,因为它绑定到已加入到查看数据的接口的唯一多播地址。“加入多播”下的此链接中的信息与我的观察相符。

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

具体问题:

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

我对网络编程缺乏经验,所以请原谅我理解上的任何缺陷。

感谢您的任何帮助。

rad*_*man 5

我已经完成了这个工作,并且在获得了Unix Network Programming的副本之后,该行为至少看起来清晰且易于理解。

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

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

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