我有以下场景；主机 HostRec:
1) 主机的 NIC bond0 已加入多播组多播1 和多播2 - 因为应用程序已请求此。
2) 我在同一台主机 HostRec 上启动了一个多播监听应用程序，它监听多播 3 和 UDP 端口 3 上的流量。
3) 我在另一台主机 HostSend 上启动了一个多播发送应用程序。
在这一点上，我有以下 3 个场景:
a) 如果 step3 的发送应用程序在多播地址 multicast3 和 udp port3 上发布，则消息被上面 step2 启动的监听应用程序正确接收。这是预期的行为。
b) 如果多播发送应用程序在多播 2 和端口 3 上发布消息，则在 step2 上启动的监听应用程序仍会收到这些消息。如果多播发送应用程序在多播 1 和端口 3 上发布消息，则行为相同。这种行为是错误的。
c) 如果发送应用程序(step3)开始在多播地址multicast4 和udp port3 上发布(HostRec 上的NIC bond0 没有加入这个多播组)，则消息没有被step2 上启动的监听应用程序正确接收。这又是预期的行为。
您能否建议主机的多播内核配置是否有问题？
uname -a
Linux HostRec 2.6.18-164.2.1.el5 #1 SMP Mon Sep 21 04:37:42 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
谢谢，
索马里奥
最佳答案
这是预期的行为，尽管起初看起来确实有点奇怪。尽管您认为您绑定(bind)到了多播组/端口，但您真正在做的是:
这两个 Action 是相当独立的。第一个的结果是您的进程将接收所有 UDP 数据包(或非多播)，这些数据包目的地是您的端口/接口(interface)。第二个的结果是确保寻址到给定多播地址的数据包(由网络路由器)发送到您的接口(interface)。
大多数人不希望这样，事实上他们只想接收单个多播组的数据，而不想担心网络上正在发生什么。实现这一点的最佳方法是确保一个端口仅用于一个多播组。通常的做法是使用多播组的最后一个八位字节作为端口的最低有效八位字节。例如 224.0.0.22/端口 19022 和 224.0.0.150/19150。这样你就永远不会得到错误的数据(只要没有人是 UDP 单播数据到这些端口)。
关于linux - 接收不需要的多播流量的应用程序，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/11560460/