потерянные пакеты происходят только при первом запуске - PullRequest
1 голос
/ 30 апреля 2019

Я пытаюсь улучшить производительность моего многоадресного приложения (чтобы уменьшить потерю пакетов), которое работает в огромной сети

Мои эксперименты показывают, что при первом запуске приложениянекоторые потерянные пакеты.Но когда я снова запускаю приложение после предыдущего запуска (иногда с небольшой задержкой), потери пакетов не происходит.Хотя, когда я перезапускаю приложение после большой задержки (например, около 20 минут), я снова вижу потерю пакетов.

И когда я проверял их метки времени, я видел, что потерянные пакеты были в основном пакетамикоторые были отправлены в начале.Таким образом, похоже, что коммутаторы или маршрутизаторы нуждаются в некотором прогреве!или что-то еще (я не знаю, как назвать это явление).

Я проверил результаты tcpdump, и количество пакетов, полученных приложением получателя, было точно таким же количеством пакетов, которые былиполучено сетевой корзиной.

И я уже попробовал следующие приемы: 1 - изменить привязку процесса на разных ядрах процессора и политику планирования 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);

    ////
}

Мне было интересно, нет ли какого-либо возможного способадобавить некоторый код, чтобы выяснить, разогрет ли коммутатор (или маршрутизатор)!достаточно?

1 Ответ

1 голос
/ 30 апреля 2019

Хорошо, если ваши коммутаторы и маршрутизаторы являются частью динамической многоадресной сети (например, на основе PIM, IGMP), которая требует определенной настройки пути (в зависимости от типа сети m-cast, различной процессы могут повлиять на настройку пути между отправителем и получателем), и у вас нет контроля над конфигурацией вашей сети m-cast (чтобы вы могли это исправить или настроить статический путь), тогда вы не можете ничего сделать.

Даже если у вас есть контрольный доступ, не все события, вызывающие потерю пакета m-cast, могут быть «фиксированными» (некоторые из них свойственны m-casting). Например, как если бы ваш m-cast работал в режиме PIM-sparse, то переключение с общего дерева на самое короткое дерево может привести к потере. Когда точка рандеву (RP, найденная в m-приведениях разреженного режима) завершает процесс регистрации отправителя, некоторая потеря пакета неизбежна и т. Д.

Посоветуйтесь со своими сетевыми администраторами - посмотрите, могут ли они помочь вам установить «статический» путь между отправителем (что не всегда возможно) и получателями, или, по крайней мере, минимизировать потерю пакетов (в м -casting).

С точки зрения приложения: если вы также пишете часть получателя - тогда лучше использовать некоторый механизм обратной связи, указывающий потерю пакета и возможную повторную передачу контента.

...