在同一多播地址上加入源特定多播
Joining a source specific multicast on same multicast address
我正在尝试使用源特定多播 (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
步数
- 配置以便只有 Source1 发送到多播地址
- 启动绑定到多播地址的reader (reader1) 并以ssm src 作为Source1 和接口作为Interface1 加入多播
- 观察在reader1
上看到数据
- 执行相同的操作 (reader2)，但使用 Source2 和 Interface2
期望的结果：
Reader1 可以看到来自组播的数据。
Reader2 看不到来自多播的数据。
我担心上述情况不会发生，因为在我使用非源特定多播进行的测试中 IP_ADD_MEMBERSHIP 具有全局效果。所以 reader2 的套接字可以看到数据，因为它绑定到唯一的多播地址，该地址已经加入到看到数据的接口。 this link under "Joining a Multicast" 中的信息与我的观察相符。
很可能 IP_ADD_SOURCE_MEMBERSHIP 的行为与 IP_ADD_MEMBERSHIP 不同，但文档很少且在这方面并不具体。
具体问题：
- 是使用 IP_ADD_SOURCE_MEMBERSHIP 全局的多播加入，即会导致任何绑定到多播地址的套接字从该源接收数据包。
- 一般应该如何使用SSM？一个多播地址有 N 个源有意义吗？
本人网络编程经验不足，理解上有不足之处还请见谅
感谢您的帮助。
我已经解决了这个问题，在获得 Unix Network Programming 的副本后，该行为至少看起来清晰易懂。
答案是肯定的，所有多播加入都是全局的，无论它们是 SSM 还是其他方式。这样做的原因是加入实际上在发出加入请求的进程的几层以下生效。基本上，它告诉 IP 层接受来自指定源的多播数据包，并将它们提供给绑定到具有多播地址的套接字的任何进程。
SSM其实是因为IPv4的地址限制space才引入的。当在 Internet 上使用多播时，几乎没有足够的唯一多播地址，以至于每个想要使用多播的人都可以拥有一个唯一的地址。 SSM 将源地址与多播地址配对，这对形成一个全局唯一标识符，即共享多播地址，例如239.10.5.1 和源 192.168.1.5。所以SSM存在的原因纯粹是为了方便有限地址space中的组播。在我们的软件在 (Cisco) 中运行的环境中，SSM 用于冗余和传输的便利性，将多个数据流堆叠在同一个 IP:port 组合上，并让下游客户端 select 他们想要的流.这一切都很好，直到给定的主机想要访问多播中的多个流，因为它们都在同一个多播地址上，所有订阅的进程都获得所有数据，由于网络堆栈的工作方式，这是不可避免的.
最终解决方案
既然已经理解了行为，解决方案就很简单了，但在每个 运行 过程中确实需要额外的代码。每个进程都必须过滤来自多播地址的传入数据，并且只从他们感兴趣的源读取数据。我曾希望 SSM 中内置了一些 "magic" 来自动执行此操作，但是有不是。 recvfrom() 已经提供了发件人地址，所以这样做成本相对较低。
我正在尝试使用源特定多播 (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
步数
- 配置以便只有 Source1 发送到多播地址
- 启动绑定到多播地址的reader (reader1) 并以ssm src 作为Source1 和接口作为Interface1 加入多播
- 观察在reader1 上看到数据
- 执行相同的操作 (reader2)，但使用 Source2 和 Interface2
期望的结果：
Reader1 可以看到来自组播的数据。
Reader2 看不到来自多播的数据。
我担心上述情况不会发生，因为在我使用非源特定多播进行的测试中 IP_ADD_MEMBERSHIP 具有全局效果。所以 reader2 的套接字可以看到数据，因为它绑定到唯一的多播地址，该地址已经加入到看到数据的接口。 this link under "Joining a Multicast" 中的信息与我的观察相符。
很可能 IP_ADD_SOURCE_MEMBERSHIP 的行为与 IP_ADD_MEMBERSHIP 不同，但文档很少且在这方面并不具体。
具体问题：
- 是使用 IP_ADD_SOURCE_MEMBERSHIP 全局的多播加入，即会导致任何绑定到多播地址的套接字从该源接收数据包。
- 一般应该如何使用SSM？一个多播地址有 N 个源有意义吗？
本人网络编程经验不足，理解上有不足之处还请见谅
感谢您的帮助。
我已经解决了这个问题，在获得 Unix Network Programming 的副本后，该行为至少看起来清晰易懂。
答案是肯定的，所有多播加入都是全局的，无论它们是 SSM 还是其他方式。这样做的原因是加入实际上在发出加入请求的进程的几层以下生效。基本上，它告诉 IP 层接受来自指定源的多播数据包，并将它们提供给绑定到具有多播地址的套接字的任何进程。
SSM其实是因为IPv4的地址限制space才引入的。当在 Internet 上使用多播时，几乎没有足够的唯一多播地址，以至于每个想要使用多播的人都可以拥有一个唯一的地址。 SSM 将源地址与多播地址配对，这对形成一个全局唯一标识符，即共享多播地址，例如239.10.5.1 和源 192.168.1.5。所以SSM存在的原因纯粹是为了方便有限地址space中的组播。在我们的软件在 (Cisco) 中运行的环境中，SSM 用于冗余和传输的便利性，将多个数据流堆叠在同一个 IP:port 组合上，并让下游客户端 select 他们想要的流.这一切都很好，直到给定的主机想要访问多播中的多个流，因为它们都在同一个多播地址上，所有订阅的进程都获得所有数据，由于网络堆栈的工作方式，这是不可避免的.
最终解决方案
既然已经理解了行为，解决方案就很简单了，但在每个 运行 过程中确实需要额外的代码。每个进程都必须过滤来自多播地址的传入数据，并且只从他们感兴趣的源读取数据。我曾希望 SSM 中内置了一些 "magic" 来自动执行此操作，但是有不是。recvfrom()已经提供了发件人地址，所以这样做成本相对较低。