我收到了来自交易所的恢复提要,用于恢复其主要提要中丢失的数据。
交易所强烈建议仅在需要数据时收听恢复提要,并在我恢复所需数据后离开多播。
我的问题是,如果我使用的是 asio,并且在不需要时不从 NIC 读取,有什么害处?这些消息有序列号,所以我不会意外处理卡上“留下”的旧消息。
这真的会损害我的应用程序吗?
我收到了来自交易所的恢复提要,用于恢复其主要提要中丢失的数据。
交易所强烈建议仅在需要数据时收听恢复提要,并在我恢复所需数据后离开多播。
我的问题是,如果我使用的是 asio,并且在不需要时不从 NIC 读取,有什么害处?这些消息有序列号,所以我不会意外处理卡上“留下”的旧消息。
这真的会损害我的应用程序吗?
It's likely not harming your application so much as harming your machine - since the nic is still configured into the multicast group, it's still listening to those messages and passing them up, before your software ignores them and they get discarded. That's a lot of extra work that your network stack and kernel are doing, and therefore a lot of extra load on the machine in general, not just your app.
收听您的恢复源也可能对网络级别产生潜在影响。正如 pjz 提到的,您的 NIC 和 IP 堆栈将有更多的帧/数据包要处理。此外,更多的可用带宽被应用程序未使用的数据所占用;如果您的链接出现拥塞,这可能会导致丢帧。是否可能发生拥塞取决于您的服务器是 100Mb 还是 1Gb 连接,您的主机正在发送/接收多少其他流量等。
另一个潜在的问题是对其他主机的影响。如果您的主机所连接的交换机未启用IGMP 侦听,则同一 VLAN 上的所有主机都将收到额外的多播流量,这可能导致它们遇到与上述相同的问题。
如果您有一个网络团队为您管理您的网络,是否值得向他们寻求一些建议?如果您认为有必要订阅冗余订阅源,那么确定网络中已经存在的冗余级别以及主订阅源上的消息丢失的可能性似乎是谨慎的。
muz评论的补充......
这不太可能对您的系统产生任何影响,但值得注意的是,与维护多播成员资格相关的开销(假设您使用的是 IGMP - 考虑到“离开多播”的限制,这可能是合理的)
IGMP 要求定期发送和处理多播组成员资格。并且(正如 muz 的评论中提到的)如果您和多播源之间有任何交换机或路由器能够进行 igmp 侦听,那么他们就能够禁用给定网络的多播。