А если реализовать reliable протокол на основе UDP с selective acknowledgements и ретрансмитами,
чем он будет лучше TCP, например для передачи звука?

Правильно ли я понимаю, что TCP клиент не отправляет следующую порцию данных, пока не получит ACK?

Здравствуйте, Yodo, Вы писали:

Y>А если реализовать reliable протокол на основе UDP с selective acknowledgements и ретрансмитами,
Y>чем он будет лучше TCP, например для передачи звука?

Смотря, как будет реализован...

Y>Правильно ли я понимаю, что TCP клиент не отправляет следующую порцию данных, пока не получит ACK?

Правильно.

Здравствуйте, Yodo, Вы писали:

Y>А если реализовать reliable протокол на основе UDP с selective acknowledgements и ретрансмитами,
Y>чем он будет лучше TCP, например для передачи звука?
Да ничем, кроме специфичных вещей вроде UDP hole punching. А зачем? Если нужна надёжная доставка, то всё равно получится аналог TCP. Разве что можно будет немного изменить настройки, которые улучшат работу в отдельно взятой локальной сети.

Y>Правильно ли я понимаю, что TCP клиент не отправляет следующую порцию данных, пока не получит ACK?
Не совсем так. В TCP есть скользящее окно. Передатчик должен следить чтобы объём неподтверждённых данных не превышал размер окна. До этого момента передатчик может отправлять в сеть данные без ожидания ACK.

Y>А если реализовать reliable протокол на основе UDP с selective acknowledgements и ретрансмитами,
Y>чем он будет лучше TCP, например для передачи звука?
Передачу звука мона делать на не reliable протоколе используя психоакустическое кодирование. То есть такое, которое допускает определенные потери информации без значительных искажений звука в колонках клиента. В этом случае UDP рулит.

Y>Правильно ли я понимаю, что TCP клиент не отправляет следующую порцию данных, пока не получит ACK?
Отправляет в пределах запрошенного tcp window size и потом ждет ack.

От звука и видео хочется получить минимальную задержку в приемлемом качестве.
Со звуком более менее понятно — там фреймы меньше 1500 байт, поэтому reliable и не нужен.
А видео фрейм может быть побит на 10 и больше UDP пакетов. Тогда если один из них пропадёт — придётся досылать, иначе декодер будет кубики показывать.
Для видео TCP использовать?
Так вроде бы везде UDP используют и для видео тоже.
Может частично reliable нужно делать?

Здравствуйте, Yodo, Вы писали:

Y>А если реализовать reliable протокол на основе UDP с selective acknowledgements и ретрансмитами,
Y>чем он будет лучше TCP, например для передачи звука?

Скорее всего, ничем. Не надо писать такое для передачи звука, если под передачей звука имеется в виду синхронный трафик.

В любой физически реальной среде передачи действует принцип, аналогичный известному лозунгу: "Мы делаем быстро, качественно и дёшево — выберите любые два". Аналогами этих вариантов являются соответственно:

скорость и оперативность передачи данных

надёжность передачи данных (защита от потерь, искажений)

экономность передачи (требовать ресурсы, сравнимые с затратой в идеальных условиях)

Три комбинации двух вариантов из трёх дают три стиля трафика:

1. Наливной (англ. bulk). Надёжность и экономность передачи достигаются за счёт снижения скорости при проблемах передачи: неподтверждённые данные пересылаются до достижения результата или определения невозможности связи. Яркие примеры применения — скачивание фильма, доступ к базе данных для выписки товара. Яркие примеры реализации — TCP, HTTP, ODBC, SOAP, IMAP4...

2. Синхронный. Скорость и экономность важнее, допускается определённая потеря данных при передаче (которая для большинства целей применения такого типа трафика лучше, чем задержка вследствие попыток перепосылки). Яркие примеры применения — voice-over-IP, потоковое видео... Яркий пример реализации — RTP.

3. Управляющий. Важнее достучаться вовремя до получателя и получить подтверждение об этом, чем экономия ресурсов (хотя практически, безусловно, реализации не стараются поглощать всё — и дизайн протокола должен не допускать неконтролируемый рост объёмов и скоростей потоков данных). Примеры реализации — STP, OSPF, сигнальный уровень SIP.

В пределах одного протокола или применения возможно сочетание разных стилей трафика — например, во всех реализациях VoIP есть управляющий трафик и синхронный трафик.

Проблема любого решения, которое пытается передавать с "selective acknoledgements" и ретрансмитами, в том, что все эти меры приведут к тому, что данные будут получены позже и будет происходить одно из трёх:
1) Данные будут непредсказуемо задерживаться, а потом ускоренно проигрываться (случай TCP). Это самый кошмарный случай, потому что наш слух лучше относится к потерям, чем к плаванию темпа.
2) Данные будут собираться в длинное окно (не менее трёх RTT взаимодействия между сторонами, чтобы получить хоть сколько-то достаточную надёжность доставки). Соответственно голос будет устойчиво отставать — в случае межконтинентальной связи на секунду. Это уже чувствительно.
3) Перепосылки будут тратить драгоценный канал и задерживать более поздние, то есть более важные, пакеты.

Возможно, Вам и получится подобрать решение, которое избавляет от всех трёх описанных проблем. Но слабо верится.

Y>Правильно ли я понимаю, что TCP клиент не отправляет следующую порцию данных, пока не получит ACK?

Важно даже не это (в общем-то отправляет в пределах окна), а то, что у него собственный механизм задержек передачи, который неуправляем.

Здравствуйте, Yodo, Вы писали:

Y>А видео фрейм может быть побит на 10 и больше UDP пакетов. Тогда если один из них пропадёт — придётся досылать, иначе декодер будет кубики показывать.
Y>Для видео TCP использовать?
Для видео используют декодеры, которые добавляют FEC (Forward Error Correction). Как и для аудио, кстати.

Здравствуйте, Yodo, Вы писали:

Y>От звука и видео хочется получить минимальную задержку в приемлемом качестве.
Y>Со звуком более менее понятно — там фреймы меньше 1500 байт, поэтому reliable и не нужен.
Y>А видео фрейм может быть побит на 10 и больше UDP пакетов. Тогда если один из них пропадёт — придётся досылать, иначе декодер будет кубики показывать.

Это решается не так. Один из методов, например, такой: изображение делится на несколько частей такого размера, чтобы полная передача одной части занимала не более, чем один IP пакет. Каждая из частей получает поток из полного кадра плюс цепочка дельт (которые значительно меньше), причём дельты могут группироваться как механически (склейка субкадров), так и логически (если считаются спектрально, то это делается не для каждой части, а для группы). Далее, применяется введение избыточности представления с тем, чтобы, например, из N пакетов подряд было достаточно получить N-2 и по ним восстановить остальные.

Y>Для видео TCP использовать?

Если речь про скачивание фильма — да, если про поток в реальном времени — нет. Про это подробнее сказал рядом.

Здравствуйте, Yodo, Вы писали:

Y>А если реализовать reliable протокол на основе UDP с selective acknowledgements и ретрансмитами,
Y>чем он будет лучше TCP, например для передачи звука?

Y>Правильно ли я понимаю, что TCP клиент не отправляет следующую порцию данных, пока не получит ACK?
PGM?

Здравствуйте, ononim, Вы писали:

[]

O>Передачу звука мона делать на не reliable протоколе используя психоакустическое кодирование. То есть такое, которое допускает определенные потери информации без значительных искажений звука в колонках клиента. В этом случае UDP рулит.

А подробнее можно?

Здравствуйте, Yodo, Вы писали:

Y>А если реализовать reliable протокол на основе UDP с selective acknowledgements и ретрансмитами,
Y>чем он будет лучше TCP, например для передачи звука?
Всем передающим звук — не изобретайте велосипеды, а берите Opus. Он умеет делать Forward Error Correction _и_ интерполяцию потерянных фрагментов ( http://www.opus-codec.org/ ). Лучше сделать всё равно не получится.

O>>Передачу звука мона делать на не reliable протоколе используя психоакустическое кодирование. То есть такое, которое допускает определенные потери информации без значительных искажений звука в колонках клиента. В этом случае UDP рулит.
P>А подробнее можно?
ну например, есть такой формат сжатия аудио как WavPack:

WavPack также включает уникальный «гибридный» режим, который предоставляет все преимущества сжатия без потерь с дополнительным бонусом: вместо создания одного файла, в этом режиме создается относительно небольшой файл высокого (точнее, указанного при кодировании) качества с потерей (.WV), который может проигрываться сам по себе, а также файл «коррекции» (.WVC), который (в комбинации с предыдущим .WV) позволяет полностью восстановить оригинал.

Теперь делаем следующий финт ушами — шлем wv потоком по TCP, параллельно — .wvc по UDP. Если UDPшные дойдут — звук клиент получит хайфайный lossless. А не дойдут — ну все равно все расслышит.
Ну это сходу придумалось. Должны быть более специализированные форматы/протоколы,. Если нет — их надо придумать

Здравствуйте, ononim, Вы писали:

[]

O>Теперь делаем следующий финт ушами — шлем wv потоком по TCP, параллельно — .wvc по UDP.
O>Если UDPшные дойдут — звук клиент получит хайфайный lossless. А не дойдут — ну все равно все расслышит.

Ну, это понятно. Не понятно при чем здесь психоакустика =)

O>Ну это сходу придумалось. Должны быть более специализированные форматы/протоколы,. Если нет — их надо придумать :beer:

ER профили для AAC, не?

O>>Теперь делаем следующий финт ушами — шлем wv потоком по TCP, параллельно — .wvc по UDP.
O>>Если UDPшные дойдут — звук клиент получит хайфайный lossless. А не дойдут — ну все равно все расслышит.
P>Ну, это понятно. Не понятно при чем здесь психоакустика =)
Ну притом что форматы сжатия аудио с потерями — это и есть психоакустика. Там же не просто так, каждые 5 из восьми байт выкидываются

O>>Ну это сходу придумалось. Должны быть более специализированные форматы/протоколы,. Если нет — их надо придумать
P>ER профили для AAC, не?
хз мот быть. Вон киберакс ссылочку подкинул тут — http://rsdn.ru/forum/network/4967947.1

Автор: Cyberax
Дата: 18.11.12

— вот оно похоже и есть

Здравствуйте, watch-maker, Вы писали:

Y>>А если реализовать reliable протокол на основе UDP с selective acknowledgements и ретрансмитами,
Y>>чем он будет лучше TCP, например для передачи звука?
WM>Да ничем, кроме специфичных вещей вроде UDP hole punching. А зачем? Если нужна надёжная доставка, то всё равно получится аналог TCP. Разве что можно будет немного изменить настройки, которые улучшат работу в отдельно взятой локальной сети.

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

Здравствуйте, ononim, Вы писали:

хъ

P>>Ну, это понятно. Не понятно при чем здесь психоакустика =)

O>Ну притом что форматы сжатия аудио с потерями — это и есть психоакустика.

Ну если с такой стороны подойти — то да.
В прочем, справедливости ради, сжатие с потерями не обязательно психоакустика.
Ну т.е. заквантовал — уже с потерями, но психоакустики в терминах барков, pre\post masking, ATH и иже с ним в этом нет ни грамма.

O>Там же не просто так, каждые 5 из восьми байт выкидываются :)

Я как бы в курсе, почему и удивился. =)

O>>>Ну это сходу придумалось. Должны быть более специализированные форматы/протоколы,. Если нет — их надо придумать :beer:

P>>ER профили для AAC, не?

O>хз мот быть. Вон киберакс ссылочку подкинул тут — http://rsdn.ru/forum/network/4967947.1

Автор: Cyberax
Дата: 18.11.12

— вот оно похоже и есть

Что то сильно на серебряную пулю смахивает.
Чуваки запилили все на коротких окнах в угоду low-delay, при этом соответ. имеют спектральное разрешение чуть менее чем нихера (как при этом будет работать таж психоакустика — хз). Какой-то костыль правда приделали в виде pre-filter для взвешивания гармоник.
Да, переизобрели SBR. При этом типа переплюнули HE AAC.
Правда http://listening-tests.hydrogenaudio.org/igorc/results.html как то не солидно смотрится в сравнении с http://tech.ebu.ch/docs/tech/tech3324.pdf
Не, то что "Forward Error Correction _и_ интерполяцию потерянных фрагментов" — реально интересно.

O>>хз мот быть. Вон киберакс ссылочку подкинул тут — http://rsdn.ru/forum/network/4967947.1

Автор: Cyberax
Дата: 18.11.12

— вот оно похоже и есть
P>Что то сильно на серебряную пулю смахивает.
P>Чуваки запилили все на коротких окнах в угоду low-delay, при этом соответ. имеют спектральное разрешение чуть менее чем нихера (как при этом будет работать таж психоакустика — хз). Какой-то костыль правда приделали в виде pre-filter для взвешивания гармоник.
P>Да, переизобрели SBR. При этом типа переплюнули HE AAC.
P>Правда http://listening-tests.hydrogenaudio.org/igorc/results.html как то не солидно смотрится в сравнении с http://tech.ebu.ch/docs/tech/tech3324.pdf
P>Не, то что "Forward Error Correction _и_ интерполяцию потерянных фрагментов" — реально интересно.
В моем представлении протокол должен быть примерно следующим: раскладываем поток на несколько уровней "важности". Простейший пример несколько частей спектра — 200-4000, 4000-8000, 100-200 + 8000-12000, 20-100 + 12000-20000. Либо как в случае WavPack — несколько уровней сжатия с потерями, с постепенным улучшением качества за счет дельта-данных (ух термин то какой придумал). И шлем их, попутно анализируя процент потерь. Потому обратная связь с клиентом нужна обязательно, мона по TCP. Причем по TCP вместе с контрольной инфой мона гнать скажем еще и самый важный уровень, без которого тот ничего не услышит/разберет. Далее, по UDP досылаем все остальное, исходя из возможностей канала — навешивая на более важные уровни больше ECC и по возможности пользуясь QoS. Интерполяция — в принципе тоже полезно, но тут уже наверно и начинается психоакустика

Здравствуйте, Patalog, Вы писали:

P>Чуваки запилили все на коротких окнах в угоду low-delay, при этом соответ. имеют спектральное разрешение чуть менее чем нихера (как при этом будет работать таж психоакустика — хз). Какой-то костыль правда приделали в виде pre-filter для взвешивания гармоник.
P>Да, переизобрели SBR. При этом типа переплюнули HE AAC.
Opus работает лучше, чем любой другой кодек. Разве что на самых низких (менее 9Кб) полосах он может сливать другим. При этом в Opus поддерживается runtime-настройка по всему диапазону возможностей.

P>Правда http://listening-tests.hydrogenaudio.org/igorc/results.html как то не солидно смотрится в сравнении с http://tech.ebu.ch/docs/tech/tech3324.pdf
Там старая версия кодека тестировалась.

Здравствуйте, Cyberax, Вы писали:

[]

P>>Да, переизобрели SBR. При этом типа переплюнули HE AAC.

C>Opus работает лучше, чем любой другой кодек.

Лучше чем HE v2? :wow:

C>Разве что на самых низких (менее 9Кб) полосах он может сливать другим.

Я так понимаю что ты в курсе. Расскажи подробнее, за счет чего, собст.
Я просмотрел по диагонали, ничего прорывного не увидел.
А главное не понял, как можно на обкоцанном спектре получить нормальную психоакустику, которая как раз таки может дать реальный профит.
И накой хрен они прикрутили туда адамара?

P>>Правда http://listening-tests.hydrogenaudio.org/igorc/results.html как то не солидно смотрится в сравнении с http://tech.ebu.ch/docs/tech/tech3324.pdf

C>Там старая версия кодека тестировалась.

В любом случае hydrogenaudio, при всем к нему уважении, далеко не EBU.

Здравствуйте, Patalog, Вы писали:

P>>>Да, переизобрели SBR. При этом типа переплюнули HE AAC.
C>>Opus работает лучше, чем любой другой кодек.
P>Лучше чем HE v2?
Yup. На аналогичных битрейтах, понятное дело.

C>>Разве что на самых низких (менее 9Кб) полосах он может сливать другим.
P>Я так понимаю что ты в курсе. Расскажи подробнее, за счет чего, собст.
P>Я просмотрел по диагонали, ничего прорывного не увидел.
Вкратце — они используют сразу все возможные уловки, включая их по необходимости. На низких битрейтах используется предсказание, потом по мере появления полосы плавно включается DCT-based кодировщик. Ну и туда до кучи ещё закинули встроенный в протокол FEC. При выпадении кадров FEC, в первую очередь, восстанавливает голосовые данные.

У меня проект сейчас делается — разработчики не нарадуются от этого кодека. Он умеет вообще ВСЁ, единственная проблема — пока реализация не совсем оптимальна. По сравнению с другими кодеками не так много параллельных потоков сервер держит.

P>А главное не понял, как можно на обкоцанном спектре получить нормальную психоакустику, которая как раз таки может дать реальный профит.
Умм.. А с чего он там обкусанный?

Вот тут сравнение ещё: http://www.opus-codec.org/comparison/