Каков наилучший способ минимизировать влияние потерянных пакетов на медиапоток в реальном времени, отправляемый по TCP?

Question

Мы внедрили приложение для совместной работы с аудио и видео поверх Silverlight и пытаемся настроить его.Одной из проблем, с которыми мы сталкиваемся, является увеличение задержки потока при каждом отбрасывании пакета: нам нужно дождаться, чтобы потеря пакета была обнаружена, запрошена, а затем, чтобы потерянный пакет был повторно отправлен.Конечно, это играет чертовски с последовательностью нашего аудио потока.(Мы бы переключились на UDP, если могли, но Silverlight не поддерживает это в браузере. Мы также отключили алгоритм Nagle, в общем, как только мы передадим массив byte [] для передачи,он передается и в одном пакете. Я знаю, что размер пакета TCP! = количество отправленных данных, но с отключенным алгоритмом Nagle, он близок. И у нас есть адаптивный буфер дрожания, поэтому мы можем иметь дело с потерянными пакетами, но потерянный пакет через TCP / IP значительно увеличивает количество аудио, которое нам нужно буферизовать, и, следовательно, задержку.)

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

(1) Мы могли бы попытаться увеличить наши пакеты.В настоящее время мы посылаем смесь больших (~ 1024 байт видео) пакетов и маленьких (~ 70 байт аудио) пакетов по одному и тому же потоку TCP.Но мы могли бы объединить аудио и видео данные вместе, то есть, присоединяя некоторые наши видео данные к нашим аудио пакетам, когда есть место.Это сделало бы отдельные пакеты несколько большими, но сократило бы общее количество пакетов.

(2) Мы могли бы разделить аудио и видео на два отдельных потока TCP.Это означает, что если видеопоток остановился из-за потерянного пакета, аудиопоток не остановился бы, и наоборот.Конечно, это немного увеличило бы издержки и не уменьшило бы общее количество отправленных пакетов.

(3) Мы могли бы инвертировать мультиплексирование аудио в несколько отдельных потоков TCP, а затем снова собрать их надальняя сторона.Это эффективно позволило бы нам «подделать» единый стиль доставки пакетов UDP.Если бы у нас было 8 аудиопотоков, и один из них застопорился из-за потерянного пакета, другие потоки все равно могли бы доставлять свои данные вовремя, и все, что нам нужно было бы сделать, - это обработать 1/8 аудиопакетов.быть недоступным, пока не остановится поток.Конечно, это не идеально, но это может привести к лучшему восприятию, чем остановка всего потока и невозможность воспроизведения любых пакетов до повторной передачи потерянного пакета.

Есть мысли по поводу любой из этих возможностей?Любые другие предложения?Или нам просто нужно кодировать все три, а затем проверить их?

Answer 1

Если вы снова включите алгоритм Nagle, вы бы (i) позволили TCP отправлять буферы максимального размера в соответствии с MTU пути, а не по вашему собственному определению;(ii) выполнить ваше предложение (1) о совмещении аудио и видео пакетов;и (iii) уменьшить общее количество пакетов.Устойчивая производительность насыщенного TCP-соединения с алгоритмом Nagle и без него одинакова, поэтому вы ничего не потеряете, кроме как при начальном заполнении окна.

Вы также должны запустить самый большой буфер отправки сокетов, какой только возможнопозволить себе: не менее 128 тыс., или удвоить или увеличить в четыре раза, если это возможно;и вам также следует использовать как можно больший сокетный сокет receive , хотя перед подключением сокета должен быть установлен буфер приема сокета> 64k, чтобы другой конец мог сказать о масштабировании окна во время TCP-квитирования.

Answer 2

Я второй @Kevin Nisbet в буфере (к сожалению). Если вы используете TCP вместо UDP, буфер должен быть настолько большим, насколько необходимо, чтобы сервер получал уведомления о пропущенных байтах и ​​чтобы они достигли клиента.

Так как TCP доставляет данные в приложение в виде упорядоченного потока, когда пакет теряется, стек не может доставить дополнительный байт приложению до тех пор, пока подтверждение, сообщающее о пропущенных байтах, не будет отправлено на сервер, обработано и байты не поступят в клиент. Между тем, единственное, что поддерживает ваше приложение, это буфер. Знаете ли вы, сколько времени занимает поездка туда и обратно, включая обработку?

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

С помощью Selective Ack, по крайней мере, серверу нужно только отправить отсутствующий чанк, но стеку все же нужно дождаться прибытия чанка. Он не может передать полученные данные приложению, а затем заполнить недостающие части. Вот что делает UDP :) Может, тебе стоит написать в MS ...

Исходя со стороны сети, я немного сдерживаюсь в отправке нескольких копий одного и того же контента. Полоса пропускания в вашем приложении? Возможно, какая-то избыточность (FEC или аналогичная) лучше, чем дублирование вашего контента. Кроме того, если потеря пакетов может произойти, я не думаю, что было бы разумно увеличить объем трафика в сети. Ваш компьютер работает полудуплекс? : -D

Answer 3

Как вы определили, что потеря пакетов вызывает сбои?

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

В любом случае, независимо от того, какие настройки вы используете, вы будете ограничены TCP / IP, требующим повторной передачи пакета. Полагаю, самое важное, на что я бы хотел обратить внимание, это то, что на вашем сервере и на клиентских компьютерах включены некоторые из более продвинутых опций. Я специально имею в виду выборочные подтверждения и быстрые повторные передачи (по умолчанию в любой современной ОС они должны быть). При быстрых повторных передачах клиент будет очень быстро запрашивать пропущенный пакет, когда он обнаружит пропущенный, а при выборочных подтверждениях сервер будет только повторно передавать недостающие части потока.

В конечном счете, звучит так, как будто вы не используете достаточно большой буфер дрожания, если вы не можете допустить потерю одного пакета. Также возможно, что ваше приложение не настолько согласовано во времени, которое используется для отправки данных в стек tcp. Я бы взял несколько пакетов и попытался бы получить хорошее представление о том, что происходит в сети, и посмотреть, что вы можете сделать оттуда.

Answer 4

Это приложение будет использоваться через Интернет?Является ли причиной потери пакетов из-за качества Интернета?Если это так, помимо разработки приложения, которое будет максимально отказоустойчивым, вы также можете убедиться, что интернет-каналы имеют приемлемое качество.Хорошие интернет-каналы сегодня не должны иметь потерю пакетов более 0,1%.Вы можете протестировать интернет-каналы и интернет-провайдеров, используя наш инструмент Packet Loss .Это бесплатно, так что помогите себе.