组播成员优先级

本文介绍了组播成员优先级的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我遇到了一个具体问题如下的问题: 我有一个多播组，在该组中，我已经观察到，多播组中的成员发送的udp数据包会根据其他成员加入该组的顺序而被其他成员接收. 例如:如果server1,2,3,4按各自的顺序加入组，则如果在该组中接收到一个数据包，则该数据包将首先被1接收，然后是2，依此类推. 我还通过一些测试应用程序检查了此行为. 我正在使用Winsock2，请让我知道它们是否在内核级别进行排序，并在可能的情况下对组成员进行优先级排序.

Hi, I have come across a problem whose specifics are as follows: I have a multicast group in which i have observed that, a udp packet sent by a member in a multicast group is received by other membes based on the sequence in which they have joined the group. for eg: If server1,2,3,4 join groups in respective sequence then if a packet is received in the group it is received first by 1 then 2 and so on. I have checked this behaviour via some test applications aswell. I am using Winsock2 ,Please let me know if their is sequencing at kernel level and to priortize the group members if possible.

推荐答案

这种类型的优先级排序不会有道理，并且不能成为一般规则. 考虑一个多播组，并假设您的所有计算机目前都在同一以太网段上，以说明这一点. 广播UDP数据包时，多播组的所有其他成员将在同一时间有效地在同一条线路上在同一时间点(不包括传播延迟)接收它. 根据接收计算机的状态，处理将花费不同的时间.接收方计算机无法确定哪一个首先应对数据包做出反应，以此类推. 同样的情况也适用于计算机位于多个子网上的情况. 因此，您要观察的内容是特定于您的设置的.可能是后来加入多播组的那些计算机之所以这样做，是因为它们位于更远的位置(例如，被更多的交换机/路由器隔开).如果确实如此，您将观察到您描述的行为.但是，根本原因不是加入多播组的顺序，而是网络的拓扑. This type of prioritization doesn''t make sense and it cannot be a general rule. Consider a multicast group, and assume all your computers are on the same Ethernet segment for the moment to illustrate the point. When a UDP packet is broadcast, all other members of the multicast group will receive it at the same point in time (excluding propagation delay) as everything happens, effectively, on the same piece of wire. The processing will take different time depending on the state of the receiving computer. There is no way that the receiving computers have any way of determining which one should react to the packet first and so on. The same would apply to a situation where computers are on more than just one subnet. So what you are observing is specific to your setup. May be those computers that have joined the multicast group later have done so because they are located further (e.g. separated by more switches/routers). If this is indeed the case, you will observe the behaviour that you have described. However, the root cause is NOT the order of joining the multicast group, but the topology of the network.