UDP vs TCP

[ura]

Всем спасибо за участие! Формулирую точнее - меня интересует скорость передачи сжатого файла размером в 2 МБ по
радиосети с потерями и задержками. При использовании ЮДП програмка сама пересылает битые пакеты.

Такой протокол уже придуман - TFTP называется, легковесный для передачи файлов поверх UDP.

[Marmot]

Всем спасибо за участие! Формулирую точнее - меня интересует скорость передачи сжатого файла размером в 2 МБ по
радиосети с потерями и задержками. При использовании ЮДП програмка сама пересылает битые пакеты.

Такой протокол уже придуман - TFTP называется, легковесный для передачи файлов поверх UDP.

И как у него со скоростью на плохом канале?

[aissp]

1. sctp это вообще-то не о том, я как раз с ним сейчас на Java балуюсь
2. fps-типа игры это тоже не совсем о том, там "r" не обязательно
3. файлы это-таки совсем не медиа контент, а о чем-то специфическом для радио я никогда не читал

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

по поводу 3 прогугли типа 802.11 + tcp найдешь всякое. на практике на моей памяти проблемы были у одной больгой компании с DCL если клиент сидел на фай фае в зашумленном помещении, чем дело там кончилост просто не помню.

[Marmot]

1. sctp это вообще-то не о том, я как раз с ним сейчас на Java балуюсь
2. fps-типа игры это тоже не совсем о том, там "r" не обязательно
3. файлы это-таки совсем не медиа контент, а о чем-то специфическом для радио я никогда не читал

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

А о чем, все-таки? о том что sctp "ето один из типов udp"?

по поводу 3 прогугли типа 802.11 + tcp найдешь всякое. на практике на моей памяти проблемы были у одной больгой компании с DCL если клиент сидел на фай фае в зашумленном помещении, чем дело там кончилост просто не помню.

Не хорошо это как-то, сначала, типа, сказать, а потом в гугл посылать... Примеры правильных udp based протоколов, оптимизированных для радиосетей в студию. Нет примеров, будем это считать пустым базаром.
Кстати, мой пойнт в том, чтo именно для этого и придумали tcp A udp хорош именно там, где частичная потеря пакетов особой роли не играет...

[aissp]

Ох, лениво думать над ответом ну ладно, попробую вспомнить русский.
(1) Я ничего не утверждал, я рассуждал, более того я даже вопрос поставил - "логично?"
(2) Поскольку я не спорил, и не пытался доказать, что я тут самый умный мне непонятно почему и кому я должен представлять доказательства.

Мои пойнты были весьма просты: (а) tcp не идеален (b) имеено поетому появляются udp based протоколы для тех случаев где tcp не идет (c) конкретно для вай фая не идельность tcp связана с тем что гарантированная доставка и попытка передать как можно больше информации плохо соотносится с обилием ошибок передачи, что вызывает частые повторы передачи и ведет к уменьшению скорости передачи (а то и восе невозможности начать передачу после установки соедениения, есть тому пример).

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

По сему мне не совсем ясТТно о чем ето ты?

[Marmot]

...
По сему мне не совсем ясТТно о чем ето ты?

О том, что факт наличия преимуществ udp based протоколов в радиосетях взят с потолка и никаких конкретных примеров существования таких преимуществ приведено небыло...
Так что я остаюсь при следующих своих мнениях:
1. Надо тестировать, а не гадать.
2. Скорее всего, никаких статистически значимых преимуществ у udp based протокола не будет...
3. aissp за базар отвечать не любит (см. sctp)

[Shvonder]

тапками не кидаться но немного теории (возможно лжетеории) для размышления
скорость передачи и ТСР и UDP протоколами по стабильному каналу (без потерь) будет практически одинокова
разница 1-3% (я бы сказал что даже меньше)
Как меня учили:
комп, имеет подключение, если оно не стабильное (обмен пакетами с базой) он типа знает об этом, и когда начинается ТСР сессия, он (как клиент) при синхронизации с сервером сообщает ей что:
нефиг мне слать пакет стандартной длины 1500, у меня тут потерь море - шли меньше (и указывает рекомендованный размер)
Я бы всётаки попытался разобраться как можно комп "убедить" что пакет длиной больше чем 100 (например) запрашивать не нужно.
Просто то направление в котором вы работаете ... это на мой взгляд попытка превратить программным способом протокол UDP в ТСР .....
если длина UDP пакета у вас по умолчанию будет такая же как ТСР (по умолчанию они кстати одинаковы, разница длины только в приставках 8 и 20, а длина полезной инфы в пакете 1500) - то вы на паршивом канале ничего не выиграете: потерянных пакетов в обоих случаях будет одинаковое количество и переданной инфы в единицу времени тоже.
маленький нюанс - некоторые программы по умолчанию формируют длину полезной инфы в пакете, голосовые проги (например скайп) пересылают специально короткие UDP пакеты с полезной инфой обычно 40-80, а торрент кажется 1500.
То есть: если ваша прога влияет на длину пакета UDP - вам визуально может показаться что вы выигрываете во времени, но если комп заставить запрашивать пакеты ТСР такой же длины - время будет одинаково