收听多播对我有何伤害？
我收到来自交易所的恢复源，用于恢复其主要源中丢失的数据。
交易所强烈建议仅在需要数据时收听恢复源，并在恢复所需数据后离开多播。
我的问题是，如果我使用asio，并且在不需要时不从NIC读取，有什么危害？ 这些消息有序列号，因此我不会意外处理卡上“留下”的旧消息。
这真的会损害我的应用程序吗？
I'm receiving a recovery feed from an exchange for recovering data missed from their primary feed.
The exchange strongly recommends listening to the recovery feed only when data is needed, and leaving the multicast once I have recovered the data I need.
My question is, if I am using asio, and not reading from the NIC when I don't need it, what is the harm? The messages have sequence numbers, so I can't accidentally process an old message "left" on the card.
Is this really harming my application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
收听您的恢复源也可能对网络级别产生潜在影响。 正如 pjz 提到的，您的 NIC 和 IP 堆栈将有更多的帧/数据包需要处理。 此外，更多的可用带宽被应用程序未使用的数据占用； 如果您的链路出现拥塞，这可能会导致丢帧。 是否可能发生拥塞取决于您的服务器连接的是 100Mb 还是 1Gb、您的主机正在发送/接收多少其他流量等。
另一个潜在的问题是对其他主机的影响。 如果您的主机所连接的交换机没有启用 IGMP 监听，则该交换机上的所有主机同一 VLAN 将接收额外的组播流量，这可能导致它们遇到与上述相同的问题。
如果您有一个网络团队为您管理网络，那么是否值得向他们寻求一些建议？ 如果您认为有必要订阅冗余源，那么明智的做法是计算出您的网络中已经存在的冗余级别以及主源上的消息丢失的可能性有多大。
Listening to your recovery feed could also have a potential impact on a network level. As pjz mentioned, your NIC and IP stack will have more frames/packets to process. In addition, more of your available bandwidth is being used up by data that is not being used by your application; this could lead to dropped frames if there is congestion on your link. Whether congestion is likely to occur depends on whether your server is 100Mb or 1Gb attached, how much other traffic your host is sending/receiving, etc.
Another potential concern is the impact on other hosts. If the switch your host is attached to does not have IGMP snooping enabled, then all hosts on the same VLAN will receive the additional multicast traffic, which could lead them to experience the same problems as mentioned above.
If you have a networking team administering your network for you, it may be worth seeking out some recommendations from them? If you feel it is necessary to subscribe to a redundant feed, it would seem prudent to work out what level of redundancy already exists in your network and how likely it is that messages on the primary feed will be lost.
它可能不会损害你的应用程序，而是损害你的机器 - 由于网卡仍然配置到多播组中，它仍然在监听这些消息并传递它们，然后你的软件会忽略它们并让它们得到被丢弃。 这是您的网络堆栈和内核正在做的大量额外工作，因此通常会给计算机带来大量额外负载，而不仅仅是您的应用程序。
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.
对 muz 评论的补充...
这不太可能对您的系统产生任何影响，但值得注意的是维护多播组成员资格会产生相关开销（假设您使用 IGMP - 考虑到“离开多播”的限制，这可能是合理的）
IGMP 要求定期发送和处理多播组成员资格。 并且（正如 muz 的评论中提到的）如果您和多播源之间有任何能够进行 igmp 监听的交换机或路由器，那么它们就能够禁用给定网络的多播。
An addition to muz's comment...
It's unlikely that this will make any difference to your system, but it's worth being aware that there is an overhead associated with maintaining a multicast membership (assuming that you're using IGMP - which is probably reasonable given the restriction about "leaving the multicast")
IGMP requires the sending and processing of multicast group memberships at regular intervals. And (as alluded to in muz's comment) if you have any switches or routers between you and the multicast source that are capable of igmp snooping then they are able to disable the multicast for a given network.