丢包只发生在第一次运行

rez*_*brh 6 c++ sockets linux networking multicast

我正在尝试提高在大型网络上运行的多播应用程序的性能(以减少其数据包丢失)

我的实验表明,在应用程序的第一次运行中,有一些丢失的数据包。但是当我在上次运行后再次运行应用程序时(有时也有一点延迟),没有丢包。虽然当我在长时间延迟(例如 20 分钟左右)后重新运行应用程序时,我再次看到数据包丢失。

当我检查他们的时间戳时,我看到丢失的数据包大部分是在开始时发送的数据包。所以看起来交换机或路由器需要一些预热!或其他东西(我不知道如何称呼这种现象)。

我检查了tcpdump结果,接收器应用程序收到的数据包数量与网络购物车收到的数据包数量完全相同。

我已经尝试了以下技巧: 1- 更改进程在不同 CPU 内核和调度策略上的关联性 2- 更改套接字描述符的优先级

改变套接字描述符的优先级已经使它变得更好(减少了丢失的数据包数量)但是在将优先级设置为高之后,再次有一些丢失的数据包)

// For example
MulticastSender multicast_sender;
multicast_sender.init();

// Here I need a function in order to find out the switch is already warmed up or not


while (some condition)
{
    ////

    multicast_sender.send(something);

    ////
}

Run Code Online (Sandbox Code Playgroud)

我想知道是不是有任何可能的方法来添加一些代码来确定交换机(或路由器)是否已经预热!足够的?

Dmi*_*try 1

好吧,如果您的交换机和路由器是动态多播网络的一部分(例如,基于PIM, IGMP),则确实需要特定的路径设置(取决于多播网络的类型,各种进程可能会影响发送者之间的路径设置)和接收器),并且您无法控制您的 m-cast 网络配置(以便您可以修复它,或设置静态路径),那么您无能为力。

即使您确实具有控制访问权限,也并非所有导致 m-cast 数据包丢失的事件都可以“修复”(其中一些事件是 m-casting 所固有的)。例如,如果您的 m-cast 在某种PIM-sparse模式下运行,那么从共享树到最短树的切换可能会导致丢失。当集合点(RP在稀疏模式 m-cast 上发现)完成发送者的注册过程时,一些数据包丢失是不可避免的,等等。

请咨询您的网络管理员 - 看看他们是否可以帮助您在发送方(这并不总是可能)和接收方之间设置“静态”路径,或者至少最大限度地减少数据包丢失(移动广播中有某些调整) 。

从应用程序的角度来看:如果您还编写接收器的部分 - 那么最好采用某种反馈机制来指示数据包丢失和可能的内容重新传输。