Как отладить потерю пакетов?

Question

Я написал приложение на C ++ (работающее в Linux), которое обслуживает поток RTP со скоростью около 400 кбит / с. В большинстве пунктов назначения это работает нормально, но в некоторых пунктах назначения теряется пакет. Кажется, что проблемные пункты назначения имеют более медленное соединение, но оно должно быть достаточно быстрым для потока, который я отправляю.

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

Я уже проверил несколько вещей: - в tcpdump я вижу все пакеты RTP, отправляемые на отправляющую машину - на месте есть буфер отправки UDP (я пробовал размеры от 64 до 300 КБ) - пакеты RTP в основном остаются ниже 1400 байт, чтобы избежать фрагментации

Что может сделать отправляющее приложение, чтобы минимизировать вероятность потери пакетов, и как лучше всего отладить такую ​​ситуацию?

Answer 1

Не отправляйте пакеты большими пакетными порциями.

Потеря пакета обычно вызвана медленными маршрутизаторами с ограниченным размером буфера пакетов. Медленный маршрутизатор может нормально обрабатывать 1 Мбит / с, если у него есть время для отправки, скажем, 10 пакетов до получения еще 10, но если сторона отправителя 100 Мбит / с отправляет ему большой кусок из 50 пакетов, у него нет другого выбора, кроме как отбросить 40 из них.

Попробуйте распределить отправку так, чтобы вы писали только то, что необходимо написать в каждый период времени. Если вам приходится писать по одному пакету каждую пятую секунды, делайте так вместо записи 5 пакетов в секунду.

Answer 2

netstat имеет несколько полезных опций для отладки ситуации.

Первый - это netstat -su (сбросить статистику UDP):

dima@linux-z8mw:/media> netstat -su                                                      
IcmpMsg:                                                                                 
    InType3: 679
    InType4: 20
    InType11: 548
    OutType3: 100
Udp:
    12945 packets received
    88 packets to unknown port received.
    0 packet receive errors
    13139 packets sent
    RcvbufErrors: 0
    SndbufErrors: 0
UdpLite:
    InDatagrams: 0
    NoPorts: 0
    InErrors: 0
    OutDatagrams: 0
    RcvbufErrors: 0
    SndbufErrors: 0
IpExt:
    InNoRoutes: 0
    InTruncatedPkts: 0
    InMcastPkts: 3877
    OutMcastPkts: 3881
    InBcastPkts: 0
    OutBcastPkts: 0
    InOctets: 7172779304
    OutOctets: 785498393
    InMcastOctets: 525749
    OutMcastOctets: 525909
    InBcastOctets: 0
    OutBcastOctets: 0

Уведомление "RcvbufErrors" и "SndbufErrors"

Дополнительным параметром является мониторинг приема и отправки буферов UDP процесса:

dima@linux-z8mw:/media> netstat -ua
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 *:bootpc                *:*
udp        0      0 *:40134                 *:*
udp        0      0 *:737                   *:*
udp        0      0 *:mdns                  *:*

Здесь вам нужно взглянуть на столбцы Recv-Q и Send-Q интересующего вас соединения. Если значения высокие и не падают до нуля, то процесс не сможет справиться с нагрузкой.

Вы можете использовать эти команды при отправке и при получении машины.

Также вы можете использовать mtr , который объединяет traceroute и ping - он пропингует каждый переход на маршруте Это может обнаружить медленный переход на вашем маршруте. Запустите его на других компьютерах, чтобы проверить подключение ко второму.

Answer 3

RTP обычно использует UDP , что по своей природе является потерями.Пакеты могут быть потеряны в любом месте между отправителем и получателем, поэтому локальная отладка не покажет вам ничего полезного.

Очевидные действия:

• a: Уменьшите общую скорость передачи данных
• b: уменьшите «пиковую» скорость передачи данных, посылая небольшие пакеты чаще, чем один огромный кусок каждые несколько секунд.то есть, УМЕНЬШИТЕ свой буфер отправки UDP - возможно, даже до 1400 байт.
• c: Посмотрите, можете ли вы переключиться на вариант TCP RTP.

Если все остальное не удается, WireShark твой друг.Это даст вам достоверную картину того, сколько данных и когда отправляется вашим приложением.

Answer 4

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

Answer 5

Возможно, это не тот ответ, который вам нужен, но если бы у меня были проблемы с потерей пакетов, я бы попытался переключить свое приложение на использование TCP, и у меня больше не было забот о потере пакетов.