Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 186
Это ж сколько эмпэтришек в машину… =)
UDP пакеты в отличие TCP не контролируются на целостность и используются там, где не важен конечный вид данных либо потери не критичны. Использовать же его для передачи данных таких как файлы и т.д. думаю не лучший выбор…
в протоколе bittorrent вроде бы есть своя проверка целостности, так что ничего страшного
Да ничего страшного, только вот если придут неправильные данные придётся перекачивать кусочек, и так каждый раз. В битторренте смысл проверки хеша кусочков как мне думается вовсе не в контроле за ошибками обмена, а в защите от злонамеренной подделки данных.
тогда хиленькая что-то защита… Скорее всё же для контроля за ошибками.
а если придет TCP с некорректной контрольной суммой(битый пакет, например) вы думаете его перекачивать не придется? :)
Придётся, к тому же пакет может не прийти, и тогда его тоже надо отправлять заново. Собственно говоря TCP и решает эту проблему, это и есть его отличие от UDP, т.е. пакет будет доставлен в той же последовательности и без потерь.
А теперь представим, что мы используем UDP, значит сам программный клиент будет требовать доставить ему данные, что является лишней нагрузкой на CPU, да и зачем, когда TCP все равно для этих целей окажется эффективнее.
Причём время отклика для торрент сетей не играет никакой роли. Для них последовательная скачка зло и лишь тормозит систему, и пока весь файл не скачаешь все равно не посмотришь.
А теперь представим, что мы используем UDP, значит сам программный клиент будет требовать доставить ему данные, что является лишней нагрузкой на CPU, да и зачем, когда TCP все равно для этих целей окажется эффективнее.
Причём время отклика для торрент сетей не играет никакой роли. Для них последовательная скачка зло и лишь тормозит систему, и пока весь файл не скачаешь все равно не посмотришь.
так TCP и так не аппаратно реализован в PC.
В некоторых сетевухах аппаратно, их ещё рекомендуют для мощных серверов покупать, кластеризация и всё такое. Впрочем я говорил не столько про это, сколько про то, что программная реализация TCP будет эффективнее проверки того же самого средствами различных битторрент клиентов.
Ладно там где сосредоточены дешёвые мощные сети, а висит какой-нибудь Вася Пупкин на дохлом постоянно глючащем канале, вот уж где начнётся веселье.
Ладно там где сосредоточены дешёвые мощные сети, а висит какой-нибудь Вася Пупкин на дохлом постоянно глючащем канале, вот уж где начнётся веселье.
программная реализация TCP будет эффективнее проверки того же самого средствами различных битторрент клиентовАсь? Вы вообще о чём? В случае UDP контрольную сумму по прежнему считает карточка (если умеет), остальное — всё также считает CPU, только протокол проще. Почему вдруг упрощение протокола снизит эффективность???
Если говорить популярным языком, UDP используется для надёжных сетей, TCP для ненадёжных, из этого принципа выбирается, что использовать. Интернет считается ненадёжной сетью, нормально построенная локальная сеть надёжной.
В ненадёжных сетях TCP/IP будет более эффективен, и это не я придумал. Впрочем пользуйся UDP если тебе так охота, в конце концов все популярные клиенты, да и многие трекеры поддерживают эту возможность.
В ненадёжных сетях TCP/IP будет более эффективен, и это не я придумал. Впрочем пользуйся UDP если тебе так охота, в конце концов все популярные клиенты, да и многие трекеры поддерживают эту возможность.
Если говорить популярным языком, UDP используется для надёжных сетей, TCP для ненадёжных, из этого принципа выбирается, что использовать.Ссылку на источник не дадите? Чтобы знать чего людям никогда не давать читать. Выбор UDP или TCP делается на основании конкретных требований. Так в NFSv1-v3 действительно использовался UDP ибо в надёжных сетях это позволяло экономить вычислительные мощности и сеть работала быстрее. Но вот NFSv4 от поддержки UDP отказалась — даже в локальной сети поддерживается только TCP и SCTP. Несмотря на то, что современные локальные сети уж никак не менее надёжны чем те, которые были в 80е годы, когда появилась NFS. Однако же DNS использует UDP и TCP — причём TCP используется только как «запасной вариант» в случае проблем с UDP.
Интернет считается ненадёжной сетью, нормально построенная локальная сеть надёжной.Тогда почему в NFSv4, предназначенной в первую очереднь для локальных сетей произошёл отказ от UDP? Почему DNS, предназначенный в первую очередь для сети Интернет использует в качестве основного протокола UDP? Потому что разрабатывавшие их специалисты по сетям — идиоты? И потому что сотни и тысячи людей за многие годы этого не заметили? Согласитесь — притянутое за уши объяснение…
В ненадёжных сетях TCP/IP будет более эффективен, и это не я придумал.Я не знаю кто это придумал и что он при этом курил, но мне бы хотелось доказательств этого бредового утверждения. Всё зависит от задачи — в частности Bittorrent должен эффективнее работать через UDP.
Впрочем пользуйся UDP если тебе так охота, в конце концов все популярные клиенты, да и многие трекеры поддерживают эту возможность.Ну пока не все: тот же μTorrent качать до последнего времени через UDP не умел… Но да — возможность хорошая…
> но мне бы хотелось доказательств этого бредового утверждения.
Вот наконец-то здравая мысль. Если мне не на словах, а опытом докажут, что в моём медленном глючащем соединении UDP окажется быстрее, то я соглашусь, особенно если не возникнет проблем с NAT (пока то у меня с UDP вообще ничего не работает, ну да не в этом суть).
В адресах некоторых трекеров уже давно всё прописано (для примера):
tracker.thepiratebay.org/announce
udp://tracker.thepiratebay.org:80/announce
>Потому что разрабатывавшие их специалисты по сетям — идиоты? И потому что сотни и тысячи людей за многие годы этого не заметили? Согласитесь — притянутое за уши объяснение…
Вот и объясни, почему по твоему мнению используют TCP/IP, хотя могли бы использовать UDP/IP. Единственное, что мне приходит в голову по поводу UDP и его быстроты, так это возможность отправлять широковещательные сообщения, что естественно гораздо быстрее, но крайне ненадёжно, да и провайдер может зарезать эту инициативу.
>Я не знаю кто это придумал и что он при этом курил,
Специалисты из майкрософт, что ни там курили я не знаю, тема построения кластерных баз данных, то есть сверхмощных систем для обработки информации.
Вот наконец-то здравая мысль. Если мне не на словах, а опытом докажут, что в моём медленном глючащем соединении UDP окажется быстрее, то я соглашусь, особенно если не возникнет проблем с NAT (пока то у меня с UDP вообще ничего не работает, ну да не в этом суть).
В адресах некоторых трекеров уже давно всё прописано (для примера):
tracker.thepiratebay.org/announce
udp://tracker.thepiratebay.org:80/announce
>Потому что разрабатывавшие их специалисты по сетям — идиоты? И потому что сотни и тысячи людей за многие годы этого не заметили? Согласитесь — притянутое за уши объяснение…
Вот и объясни, почему по твоему мнению используют TCP/IP, хотя могли бы использовать UDP/IP. Единственное, что мне приходит в голову по поводу UDP и его быстроты, так это возможность отправлять широковещательные сообщения, что естественно гораздо быстрее, но крайне ненадёжно, да и провайдер может зарезать эту инициативу.
>Я не знаю кто это придумал и что он при этом курил,
Специалисты из майкрософт, что ни там курили я не знаю, тема построения кластерных баз данных, то есть сверхмощных систем для обработки информации.
Если мне не на словах, а опытом докажут, что в моём медленном глючащем соединении UDP окажется быстрее, то я соглашусь, особенно если не возникнет проблем с NAT (пока то у меня с UDP вообще ничего не работает, ну да не в этом суть).А то, что феррари быстрее запорожца вы признаете только тогда, когда он это продемонстрирует на бездорожье возде села Криводановка? Сети бывают разные и есть сети где вообще UDP не проходит. Простую потерю пакетов переживает легче чем TCP, но если, например, UDP-пакеты не доходят вообще, то о какой скорости может идти речь?
Вот и объясни, почему по твоему мнению используют TCP/IP, хотя могли бы использовать UDP/IP.Обисняю для идиотов: нельзя использовать то, чего нет. TCP/IP — собирательное название для сетевых протоколов разных уровней, используемых в сетях. Туда входят десятки протоколов: ARP, IP, TCP, UDP, ICMP. Без многих из них сеть работать в принципе не сможет (скажем без ARP и ICMP не будет работать вообще ничего). Протокол IP — это база, на нём построено всё остальное. Почему протокол номер шесть (а вовсе не протокол номер один) попал в название системы, а протокол номер семнадцать не попал — нужно разыскивать в анналах usenet'а.
Специалисты из майкрософт, что ни там курили я не знаю, тема построения кластерных баз данных, то есть сверхмощных систем для обработки информации.Ну значит разработанный ими протокол плохо работает через UDP если много пакетов теряется. При чём тут Bittorrent?
Гениально! А вы сами вообще читаете иногда что пишете или нет? Я вам даже специально выделю:
Причём время отклика для торрент сетей не играет никакой роли. Для них последовательная скачка зло и лишь тормозит систему, и пока весь файл не скачаешь все равно не посмотришь.
Собственно говоря TCP и решает эту проблему, это и есть его отличие от UDP, т.е. пакет будет доставлен в той же последовательности и без потерь.То есть вы сами объяснили почему TCP хуже UDP для Bittorrent'а — и даже не заметили этого! Вот это — настоящая гениальность…
А теперь представим, что мы используем UDP, значит сам программный клиент будет требовать доставить ему данные, что является лишней нагрузкой на CPU, да и зачем, когда TCP все равно для этих целей окажется эффективнее.Откуда взялась лишняя нагрузка на CPU? UDP и TCP используют одну и ту же процедуру для обеспечения целостности пакетов (почитайте RFC768), но TCP ещё дополнительно имеет хитрый и сложный протокол, который предоставляет программе гарантии, которые BitTorrent'у ни разу не интересны! Какие образом отказ от части работы может повысить нагрузку на CPU???
Обработку ошибок придётся вести BitTorrent, вот и всё. Да, может это смешно, когда в очереди стоит пару десяток закачек, но если их десятки тысяч. Впрочем почитай ка вот это — lurkmore.ru/Небыдло.
Обработку ошибок придётся вести BitTorrent, вот и всё.Обработкой ошибок в обоих случаях занимается сетевуха. Обработкой потерянных пакетов в обоих случаях занимаетеся CPU — только протокол в случае с UDP попроще. Откуда возьмётся дополнительная нагрузка?
Впрочем почитай ка вот это — lurkmore.ru/Небыдло.А вы сами там были? Читали? Может теперь (в виде исключения) наконец приведёте аргументы в пользу своей точки зрения? Hint: впрочем я говорил не столько про это, сколько про то, что программная реализация TCP будет эффективнее проверки того же самого средствами различных битторрент клиентов — аргументом не является. Потому что протокол, который нам нужно реализовать устроен гораздо проще, чем TCP.
P.S. О сетевых карточках с аппаратным TCP говорить не стоит — они и на серверах-то используются редко, а уж на домашние компьютеры (где μTorrent и используется) их и совсем не ставят.
>А вы сами там были? Читали? Может теперь (в виде исключения) наконец приведёте аргументы в пользу своей точки зрения?
Если UDP эффективнее, коррекция ошибок проходит в нём налету, тогда простой вопрос, почему по твоему мнению предпочитают использовать TCP и не только в битторрентах, ведь и то и другое существует очень давно?
Как бы слушать о том, что я не понимаю, что говорю мне не интересно, аргументируй лучше свою точку зрения, только постарайся без традиционного «ты быдло», иначе это будет последнее сообщение тебе.
Если UDP эффективнее, коррекция ошибок проходит в нём налету, тогда простой вопрос, почему по твоему мнению предпочитают использовать TCP и не только в битторрентах, ведь и то и другое существует очень давно?
Как бы слушать о том, что я не понимаю, что говорю мне не интересно, аргументируй лучше свою точку зрения, только постарайся без традиционного «ты быдло», иначе это будет последнее сообщение тебе.
Если UDP эффективнее, коррекция ошибок проходит в нём налету, тогда простой вопрос, почему по твоему мнению предпочитают использовать TCP и не только в битторрентах, ведь и то и другое существует очень давно?Несколько причин:
1. Использование UDP усложняет код приложения.
2. В современном Internet'е UDP ненадёжен из-за повсеместного использования NAT'а.
3. Если приложение действительно требует гарантий, предоставляемых TCP, то реализовывать их у себя в приложении попросту глупо.
Вы лучше скажите почему VoIP и MMORPG завязаны на UDP (та же ситуация что и в DNS: основа — это UDP, а TCP — это резервный вариант, который не всегда даже поддерживается) — ведь по вашей теории UDP хорош только для локалок, а VoIP и MMORPG в локалках не работают.
Как бы слушать о том, что я не понимаю, что говорю мне не интересно, аргументируй лучше свою точку зрения, только постарайся без традиционного «ты быдло», иначе это будет последнее сообщение тебе.Вообще-то слово быдло в беседу привнёс не я и свои слова я стараюсь аргументировать ссылками на сайты с полезной информацией, а не с потоком сознания на философские темы.
>Вы лучше скажите почему VoIP и MMORPG завязаны на UDP
VoIP это голос, не важно услышит пользователь, что-то или нет. Широкополосные сети позволяет при минимальной нагрузке организовать массовую рассылку данных. Да и телевидение или радио, достраивая над UDP ещё протколы.
Отправляем один раз, получаем хоть тысячу и нет необходимости увеличивать ширину канала. Проверка дошли данные или нет отдаётся на откуп приложениям. Что там MMORPG делают не смотрел, но принцип наверное тот же. Хотя если с такой позиции рассматривать скорости, то мне на глючном соединении их не видать, так что о UDP можно забыть.
VoIP это голос, не важно услышит пользователь, что-то или нет. Широкополосные сети позволяет при минимальной нагрузке организовать массовую рассылку данных. Да и телевидение или радио, достраивая над UDP ещё протколы.
Отправляем один раз, получаем хоть тысячу и нет необходимости увеличивать ширину канала. Проверка дошли данные или нет отдаётся на откуп приложениям. Что там MMORPG делают не смотрел, но принцип наверное тот же. Хотя если с такой позиции рассматривать скорости, то мне на глючном соединении их не видать, так что о UDP можно забыть.
хм, на сколько часто Вы видели VoIP + широковещание?
мне видится смысл в UDP в VoIP/MMORPG — исключение встречного потока подтверждающих пакетов и перепосылок сообщений, которые в рамках реального времени уже устареют.
кстати, не понимаю, почему shoutcast использует TCP как транспорт для аудиопотока… разве что из-за NAT'ов
мне видится смысл в UDP в VoIP/MMORPG — исключение встречного потока подтверждающих пакетов и перепосылок сообщений, которые в рамках реального времени уже устареют.
кстати, не понимаю, почему shoutcast использует TCP как транспорт для аудиопотока… разве что из-за NAT'ов
Про последовательную скачку вы, наверное, не так поняли.
Последовательная скачка [кусочков / pieces] в торрентах — зло. Она мешает равномерно распределять имеющиеся кусочки между качающими, что сказывается на распределении нагрузки на участников файлообмена.
Последовательная доставка пакетов (которую гарантирует TCP) помогает собрать кусочек из полученных пакетов силами стека TCP/IP. Точнее, позволяет получить поток из последовательности «заголовок-данные-заголовок-данные-...», откуда данные без труда получаются клиентом. Но не стоит забывать, что для передачи по сети кусочек бьется на блоки, которые уже в свою очередь помещаются в пакеты. А вот с блоками начинается самое интересное. Размер блока передается в параметрах битторрент-запроса request, и по поводу размера блока возникает немало споров, например, есть мнение, что «Согласно официальной спецификации, все текущие реализации [протокола] используют [размер блока] 2^15 (32КБ) и закрывают все соединения, запрашивающие больше 2^17 (128КБ)» Подробнее на англ.
Т.е. в цитируемых вами фрагментах говорится о последовательностях на разных уровнях. О совершенно разных последовательностях.
ЗЫ: Кстати, не стоит забывать, что полезная нагрузка UDP-пакета меньше 64КБ. Получается, что максимальный «круглый» размер блока, который можно запросить — 32КБ. На быстрых каналах и больших раздачах накладные расходы будут впечатляющими.
Последовательная скачка [кусочков / pieces] в торрентах — зло. Она мешает равномерно распределять имеющиеся кусочки между качающими, что сказывается на распределении нагрузки на участников файлообмена.
Последовательная доставка пакетов (которую гарантирует TCP) помогает собрать кусочек из полученных пакетов силами стека TCP/IP. Точнее, позволяет получить поток из последовательности «заголовок-данные-заголовок-данные-...», откуда данные без труда получаются клиентом. Но не стоит забывать, что для передачи по сети кусочек бьется на блоки, которые уже в свою очередь помещаются в пакеты. А вот с блоками начинается самое интересное. Размер блока передается в параметрах битторрент-запроса request, и по поводу размера блока возникает немало споров, например, есть мнение, что «Согласно официальной спецификации, все текущие реализации [протокола] используют [размер блока] 2^15 (32КБ) и закрывают все соединения, запрашивающие больше 2^17 (128КБ)» Подробнее на англ.
Т.е. в цитируемых вами фрагментах говорится о последовательностях на разных уровнях. О совершенно разных последовательностях.
ЗЫ: Кстати, не стоит забывать, что полезная нагрузка UDP-пакета меньше 64КБ. Получается, что максимальный «круглый» размер блока, который можно запросить — 32КБ. На быстрых каналах и больших раздачах накладные расходы будут впечатляющими.
Но не стоит забывать, что для передачи по сети кусочек бьется на блоки, которые уже в свою очередь помещаются в пакеты.Не стоит забывать о том, что в случае UDP этого не происходит.
ЗЫ: Кстати, не стоит забывать, что полезная нагрузка UDP-пакета меньше 64КБ. Получается, что максимальный «круглый» размер блока, который можно запросить — 32КБ. На быстрых каналах и больших раздачах накладные расходы будут впечатляющими.На большинстве линков пакеты больше 1500 байт не отсылаются, а пакеты больше 9KB (так называемы jumbogram'мы) — вообще экзотика, так что практически ограничение в 32KiB — не ограничение.
Не стоит забывать о том, что в случае UDP этого не происходит.
А можно цитату из документации протокола Bittorrent, где говорится, что в случае работы по UDP клиент пытается запихнуть кусок в UPD-пакет целиком? Давайте вспомним, что у нас есть раздачи с размером куска в 4МБ.
Я понял, что вы имели в виду тот факт, что данные перед отправкой по UDP не разбиваются. Но вы не поняли, что когда я говорил о блоках, то имел в виду блоки в терминологии спецификации протокола Bittorrent.
На большинстве линков пакеты больше 1500 байт не отсылаются, а пакеты больше 9KB (так называемы jumbogram'мы) — вообще экзотика, так что практически ограничение в 32KiB — не ограничение.
Тогда давайте просто посчитаем. Возьмем для удобства расчетов размер блока в 30000 байт, а размер пакета — 1500 байт.
Если у нас обмен производится по TCP/IP, тогда есть 20 пронумерованных пакетов с данными, накладные расходы протокола Bittorrent — 13 байт (1 байт — id команды, 4 байта — idx кусочка, 4 байта — стартовое смещение данных блока в кусочке, 4 байта — длина блока).
Теперь давайте попробуем отправить тот же самый блок по UDP. Если мы записываем все в один пакет, тогда у нас будет jumbogram'ма и всего лишь 13 байт накладных расходов. А если писать в пакет не более 1500 байт, то у нас 260 байт накладных расходов. Естественно, вычисления приблизительные, т.к. полезная нагрузка протокола Bittorrent, как и его накладные расходы, являются полезной нагрузкой протоколов TCP/IP или UDP.
Опять же, повторяю, это расчеты с точки зрения протокола Bittorrent.
Но это уже серьезное ответвление от основной темы нашего треда.
Что же касается того вашего высказывания, с которого начался наш тред, то UDP лучше TCP не потому, что «Для них последовательная скачка зло и лишь тормозит систему, и пока весь файл не скачаешь все равно не посмотришь.» и «Собственно говоря TCP и решает эту проблему, это и есть его отличие от UDP, т.е. пакет будет доставлен в той же последовательности и без потерь.», а потому, что у UDP при прочих равных накладных расходов на транспортном уровне меньше (пусть и на уровне протокола Bittorrent больше).
Теперь давайте попробуем отправить тот же самый блок по UDP. Если мы записываем все в один пакет, тогда у нас будет jumbogram'ма и всего лишь 13 байт накладных расходов. А если писать в пакет не более 1500 байт, то у нас 260 байт накладных расходов. Естественно, вычисления приблизительные, т.к. полезная нагрузка протокола Bittorrent, как и его накладные расходы, являются полезной нагрузкой протоколов TCP/IP или UDP.
Что вы насчитали тут мне? Размер заголовка Bittorrent — 13 байт (это вы правильно посчитали). Но! Размер заголовка TCP — 24 байта, размер заголовка UDP — 8 байт! То есть весь заголовок Bittorrent'а укладывается в место освобождённое в пакете при переходе от TCP к UDP! Там самым при использовании UDP данных по проводам передаётся меньше! Всегда!
Что же касается того вашего высказывания, с которого начался наш тред, то UDP лучше TCP не потому, что «Для них последовательная скачка зло и лишь тормозит систему, и пока весь файл не скачаешь все равно не посмотришь.» и «Собственно говоря TCP и решает эту проблему, это и есть его отличие от UDP, т.е. пакет будет доставлен в той же последовательности и без потерь.», а потому, что у UDP при прочих равных накладных расходов на транспортном уровне меньше (пусть и на уровне протокола Bittorrent больше).Ну ёлки ж палки. Кто вас теории вероятностей учил? Вот тут я написал подробнее. TCP проигрывает именно потому что пытается гарантировать то, что "пакет будет доставлен в той же последовательности и без потерь"! А экономия на транспортном уровне — это копейки. На 9000 байт экономия составит 73 байта. Меньше одного процента! Стоили ли огород городить ради таких крох?
а в torrent целостность передачи контроллируется клиентами можно сказать на уровне собственного протокола, так что tcp для него избыточен и даже хуже ибо создаёт лишний оверхед
так что UDP лучший выбор
так что UDP лучший выбор
если будут большие потери пакетов, то на TCP быстрее будет работать. Чев выше происходит проверка, тем больше служебного трафика в случае ошибки. Не все так однозначно, как кажется на первый взгляд
На UDP нету служебного трафика.
Сервер послал пакет и забыл о нём, если клиент сам не попросит передать повторно другим путём. В TCP так называемый «служебный трафик» на уровне протокола, а не на уровне клинт-серверного обмена.
Торрент-сеть на основе UDP, да ещё с поддержкой броадкастинга, — это великая вещь, которая в разы ускорит распространение контента.
Сервер послал пакет и забыл о нём, если клиент сам не попросит передать повторно другим путём. В TCP так называемый «служебный трафик» на уровне протокола, а не на уровне клинт-серверного обмена.
Торрент-сеть на основе UDP, да ещё с поддержкой броадкастинга, — это великая вещь, которая в разы ускорит распространение контента.
я вкурсе. Если большое количетсво ошибок происходит именно на уровне udp, то именно на этом уровне их и надо исправлять. Т.к. если делать тоже самое уровнем выше, то это влечет при определенном проценте потерь только к увеличению трафика, а не его снижению
Отнюдь не обязательно. Зависит от того как это будет сделано в µTorrent-е. Вполне возможно это сделать с накладными расходами не более чем у TCP, а может быть и менее.
любопытно, как Вы это видите?
В смысле какой именно способ по-Вашему может иметь меньшие накладные расходы, чем уведомление о получении а-ля TCP.
В смысле какой именно способ по-Вашему может иметь меньшие накладные расходы, чем уведомление о получении а-ля TCP.
Ну, это специфический случай торрентов, тут можно много чего придумать.
Например, можно не требовать подтверждения прихода данных вообще, а клиент просто будет периодически запрашивать куски торрента, которых у него нет, пока не получит их корректно. Можно у тех пиров, от которых запрошенные куски приходят поврежденными или вообще не приходят (что свидетельствует о плохом канале) вообще ничего не запрашивать, т.е. соединятся только с теми, с кем коннект хороший. Ну и так далее, использование UDP означает просто, что все функции проверки на ошибочность, контроля трафика и т.п. можно реализовать самому, причем оптимизировать их для конкретного случая передачи торрентов, что в среднем будет лучше, чем использование универсального TCP, которому пофиг, что через него передается, торренты, веб-странички или что-то другое.
Например, можно не требовать подтверждения прихода данных вообще, а клиент просто будет периодически запрашивать куски торрента, которых у него нет, пока не получит их корректно. Можно у тех пиров, от которых запрошенные куски приходят поврежденными или вообще не приходят (что свидетельствует о плохом канале) вообще ничего не запрашивать, т.е. соединятся только с теми, с кем коннект хороший. Ну и так далее, использование UDP означает просто, что все функции проверки на ошибочность, контроля трафика и т.п. можно реализовать самому, причем оптимизировать их для конкретного случая передачи торрентов, что в среднем будет лучше, чем использование универсального TCP, которому пофиг, что через него передается, торренты, веб-странички или что-то другое.
В смысле какой именно способ по-Вашему может иметь меньшие накладные расходы, чем уведомление о получении а-ля TCP.Самый простой и тупой, какой только можно придумать. Нам заранее известно что пакетов, которые нам нужны — конечное число. Ну скажем миллион. Мы знаем какие пакеты у нас есть, каких — нет. Нам всего-навсего нужно запрашивать пакеты, которых у нас нет и повторять запрос если ответа долго (скажем секунд пять) нет. Протокол — на порядок проще чем в TCP. Никаких пересылок данных туда/сюда/обратно. Вообще никакой синхронизации между пакетами. И никаких подтверждений вообще! Чистый протокол класса «запос — ответ»!
Если вам кажется что TCP может хоть как-то с этим состязаться… И по скорости и по ресурсам TCP-Bittorrent и UDP-Bittorrent и близко не лежали…
для этого все пакеты нужно
1) нумеровать (или нумеровать не пакеты, то части данных)
2) в случае недоставки — сообщать номера
В любом случае, определенная дополнительная информация нужна.
1) нумеровать (или нумеровать не пакеты, то части данных)
2) в случае недоставки — сообщать номера
В любом случае, определенная дополнительная информация нужна.
нумеровать
А так и есть, по крайней мере в торрентах.
А так и есть, по крайней мере в торрентах.
нумеровать — т.е. вводить дополнительный протокол поверх UDP. А это дополительные накладные расходы. Которые могут оказаться больше, чем расходы TCP.
нумеровать — т.е. вводить дополнительный протокол поверх UDP.Ну да, разумеется.
А это дополительные накладные расходы. Которые могут оказаться больше, чем расходы TCP.Ни в коем случае. TCP решает очень сложную задачу: подать в программу байты в том порядке в каком они были высланы. Нам же нужно решить гораздо более простую задачу — получить все байты когда-нибудь. Простой протокого «вопрос-ответ» с перезапросом «потерянных» пакетов вполне может с этим справиться. Мы можем даже плюнуть и после двух-трёх попыток запросить определённый пакет обратится к другому клиенту — чего TCP аж никак сделать не сможет: если случится затык в каком-нибудь тысячном пакете, то TCP будет пересылать его снова и снова, и все будут ждать пока этот пакет наконец дойдёт — ничем больше в этот момент канал будет занять нельзя.
1) нумеровать (или нумеровать не пакеты, то части данных)Не нужно нам нумеровать пакеты! Ни разу не нужно! Нам нужно написать что унутри у этого пакета: скажем пакет с байтами 1'500'000..1'501'500. Принимающая сторона хватает пакет и радостно его пристраивает в свой файл. Всё. Ах, да — когда мы собрали очередной кусок в несколько мег — нужно проверить сошлась ли контрольная сумма и если нет — выкинуть все пакеты, запросить их по новой.
2) в случае недоставки — сообщать номераОпять-таки: не нужно! Нужно сообщить диапазон байт, которые нас интересуют — и всё.
В любом случае, определенная дополнительная информация нужна.Нужна масса информации! Нужно помнить какие пакеты мы запросили и у кого, нужно следить за тем, чтобы не запрашивать пакеты слишком часто, нужно делать вообще много разных вещей (потому это пока beta и ещё долго будет отлаживаться). Но цимес в чём: вся эта информация волнует только систему, которая скачивает файл. И её не нужно никуда пересылать!
Да, это получается реализация своего протокола (аналог TCP) поверх UDP. Для этого мы должны иметь возможность вручную составлять каждый UDP пакет. А это Win системы делать не позволяют, соответственно кореекция будет происходить на более высоком уровне, следовательно habrahabr.ru/blogs/p2p/45989/#comment_1169083
Для этого мы должны иметь возможность вручную составлять каждый UDP пакет. А это Win системы делать не позволяют.Вы чего? Совсем с ума сошли? Если я не могу отослать UDP пакет с тем содержимым, какое мне нужно, то что я вообще могу? Разумеется Windows позволяет отсылать пакеты с любым содержимым. Мы не можем влиять на служебные поля — но это нам и не нужно.
Как уже было сказано, можно много чего придумать, просто потому что TCP не налагает своих ограничений, да и при получении торрентов не надо заботиться о порядке получения пакетов, а это большие накладные расходы для всей сети.
о, уже набежали, заминусовали.
Речь идет именно о той ситуации, когда клиент попросил переслать пакет повторно.
В случае, если одни и те же пакеты нужно будет отправлять по несколько раз — выигрыша от UDP по сравнению с TCP не будет.
Сервер послал пакет и забыл о нём, если клиент сам не попросит передать повторно другим путём.
Речь идет именно о той ситуации, когда клиент попросил переслать пакет повторно.
В случае, если одни и те же пакеты нужно будет отправлять по несколько раз — выигрыша от UDP по сравнению с TCP не будет.
Это не такая частая ситуация.
Ситуация недостаточно редкая, чтобы ею пренебрегать при передаче файлов.
Это в случае с голосом и видео кадрами можно плюнуть на кривой фрейм и показывать следующий, поэтому и переспрашивать не надо, и второй раз битый фрейм отправлять незачем.
Это в случае с голосом и видео кадрами можно плюнуть на кривой фрейм и показывать следующий, поэтому и переспрашивать не надо, и второй раз битый фрейм отправлять незачем.
В торренте уже есть система проверки данных на аутентичность. Гораздо более серьезная чем CRC16 в TCP. Просто будут использоваться более другие механизмы, гибче и надежнее.
на совершенно более высоком уровне! И, соответсвенно, больше объемов данных, которые нужно передать в случае ошибки. При маленьком проценте потерь (суммарная выгода от отказа от TCP больше, чем данные. которые необходимо переслать для коррекции куска перемылаемых данных) выгодно использовать UDP, при большом — TCP
При маленьком проценте потерь (суммарная выгода от отказа от TCP больше, чем данные. которые необходимо переслать для коррекции куска перемылаемых данных) выгодно использовать UDP, при большом — TCP.Большей чуши представить себе просто невозможно. Рассмотрите крайний случай: 90% потерь пакетов. TCP в этом случае просто загнётся. UDP (по описанной схеме) будет работать и просто перепошлёт все пакеты в среднем по 10 раз. Это как раз когда потери невелики неважно что использовать — TCP или UDP.
В случае, если одни и те же пакеты нужно будет отправлять по несколько раз — выигрыша от UDP по сравнению с TCP не будет.Либо вы не понимаете как работает TCP, либо одно из двух. Как вообще TCP обеспечивает целостность передачи данных? Чудес на свете не бывает: он ждёт некоторое время прихода пакета, потом просит его передать. Пока «отсутствующий» пакет не доставят — программа ждёт. Как работает BitTorrent через UDP? Ну нет у нас пакета — и чёрт с ним. Подождём секунд пять-десять — заново запросим. А пока давайте попросим какой-нибудь другой пакет их нужных нам. У нас есть выбор из как минимум нескольких сот тысяч (а скорее миллионов) вариантов! Что это значит? Если пакеты теряются — TCP начинает тормозить. Если теряется, скажем, 75% пакетов, то скорость падает катастрофически. В случае UDP — у нас всё время есть чем занять канал! Даже если будет теряться 90% пакетов — мы выберем всю пропускную способность канала и скачаем весь файл (хотя для этого нам придётся послать в 10 раз больше данных чем размер файла).
а как вы сообщите, какие udp пакеты не доставлены?
А зачем мне это сообщать? Мне нужно сообщить только какие пакеты меня интересуют. А уж почему они меня интересуют (потому что они ещё ни разу не запрашивались или потому что они были запрошены, но не были доставлены) передающей стороне знать ни разу не нужно. И почему я ответа не получил (есть три варианта: был потерян запрос, был потерян ответ или глюки на той стороне) — меня тоже ни разу не волнует. Мне важно знать только факт: был получен запрошенный мною пакет или не был.
Параллельно идёт обмен сообщениями, которые сообщают о том, что у меня повился кусочек файла (чтобы другие клиенты могли у меня его запрашивать), но этот траффик столь ничтожен что его можно и по TCP пустить.
Параллельно идёт обмен сообщениями, которые сообщают о том, что у меня повился кусочек файла (чтобы другие клиенты могли у меня его запрашивать), но этот траффик столь ничтожен что его можно и по TCP пустить.
Если пакеты теряются — TCP начинает тормозить.
суть тормозов TCP как раз и заключается в ожидании подтверждения получения пакетов и повторной их пересылке
Если теряется, скажем, 75% пакетов, то скорость падает катастрофически. В случае UDP — у нас всё время есть чем занять канал! Даже если будет теряться 90% пакетов — мы выберем всю пропускную способность канала и скачаем весь файл (хотя для этого нам придётся послать в 10 раз больше данных чем размер файла).
Данные не берутся ниоткуда и нам все равно нужно будет их повторно запросить и повторно получить в случае, если мы хотим получить файл. Если в случае с потоковым видео мы просто забываем про бракованные кадры, и не нагружаем сеть повторной пересылкой данных, в чем и состоит выигрышь от использвания UDP, то в случае с файлом — переспрашивать таки придется и выгоды от использования UDP нет.
Поправьте меня, если я ошибаюсь, но пересылая без толку 10 раз пакет по UDP и видя скорость приблизительно равную пропускной способности канала мы и получаем в результате ту же самую эффективную скорость (количество правильно доставленных пакетов: затраченное время) как и в случае использования TCP.
Поправьте меня, если я ошибаюсь, но пересылая без толку 10 раз пакет по UDP и видя скорость приблизительно равную пропускной способности канала мы и получаем в результате ту же самую эффективную скорость (количество правильно доставленных пакетов: затраченное время) как и в случае использования TCP.Нет, нет и нет. Да, мы в обоих случаях запрашиваем пакеты повторно, но вопрос в том как мы это делаем. Рассмотрите простой случай: 50% вероятностная потеря пакетов (считать легче, а результат тот же). Вначале события развиваются одинаково: мы запрашиваем 64 пакета (в реальной жизни цифры колеблются, но это типичное количество). Получаем 32. Что происходит потом? А потом судьба TCP и UDP сильно разнится. TCP застревает в вреднем на втором пакете, отдаёт в программу один и перезапрашивает 33 пакета. UDP заносит 64 полученных в базу и перезапрашивает снова 64 пакета! Дальше TCP получает свои 17 пакетов, сдвигается в среднем на два и запрашивает повторно 18 пакетов, получает 9 пакетов, сдвигается на 4 и запрашивает 13 пакетов, сдвигается на 8 и запрашивает 16 — в общем стабилизируется это дело примерно на уровне «сдвига окна» в 16 пакетов и запроса «недостающих» 32х пакетов. А UDP всё время запрашивает по 64 пакета! Но это ещё цветочки. Если бы дело было только в этом, то мы потеряли бы«всего» 50% пропускной способности канала. На самом деле обнаружив такую потерю пакетов TCP немедленно решит что канал у нас перегружен и уменьшит окно! Так что если у нас просто сеть с допольно большим количеством потерь пакетов, то UDP гораздо более эффективен. Другое дело что UDP могут идти с низшим приоритетом или вообще не идти — но это уже от ISP зависит.
К тому же можно реализовать не только контроль но и нормальную коррекцию ошибок.
Контролировать целостность можно на каком угодно уровне — суть в другом. Допустим после проверки целостности на уровне приложения стало понятно, что файл принят неверно и в нем есть части с ошибками. Что делать — вариантов два.
1) давайте еще раз качнем битые фрагменты.
в этом случае у нас не будет выигрыша от использования UDP.
2) давайте добавлять такую избыточную информацию в пакеты, чтобы она не только проверяла целостность, но и позволяла восстановить битые куски. (а-ля rar recovery record или par2)
Но тогда канал будет загружен еще больше, чем в случае с простым подтверждение о приеме отдельного пакета, как в TCP.
1) давайте еще раз качнем битые фрагменты.
в этом случае у нас не будет выигрыша от использования UDP.
2) давайте добавлять такую избыточную информацию в пакеты, чтобы она не только проверяла целостность, но и позволяла восстановить битые куски. (а-ля rar recovery record или par2)
Но тогда канал будет загружен еще больше, чем в случае с простым подтверждение о приеме отдельного пакета, как в TCP.
Коррекция путем повтора потеряных пакетов самый промитивный способ. К тому же можно реазовать туже самую схему и получить сравнимую загрузку интернено.
Но существуют более эффективные способы коррекции, возможно их и реализуют. Выйдет даже экономия трафика.
Но существуют более эффективные способы коррекции, возможно их и реализуют. Выйдет даже экономия трафика.
Овчинка не стоит выделки. В конце-концов TCP перепосылает битые пакеты — и ничего. Кто нам мешает делать то же самое с UDP? Заметим что «отбраковку» битых пакетов и в случае TCP и в случае UDP делает сетевая карта — до операционной системы они в любом случае не доходят.
не придётся ли для этого менять всех торрент-клиентов и все торрент-сервера?
да, это кажется разумным — пересылать не весь битый пакет, а только запись для восстановления.
если пакет не удалось восстановить с помощью этой записи — тогда уже пересылать весь пакет заново.
если пакет не удалось восстановить с помощью этой записи — тогда уже пересылать весь пакет заново.
Выдержит ли UDP такие объёмы траффика?
как в анекдоте: «…а заодно и проверим!»
почему нет?
При чём здесь вообще протокол к объёму трафика? Выдеражть или нет может только оборудование. А при том том, что использование UDP приводит к тому, что избыточных данных становится меньше, почему бы ему не выдержать? :)
Да выдержит ваше оборудование, выдержит. Вопрос в другом: будет ли через этот канал проходить что-либо ещё или там будет жить только Bittorrent? Как оборудование справляется с перегрузкой? Как правило алгоритм простой: выкидываем каждый пакет из 10. Или каждый второй пакет — в зависимости от степени перегрузки. Если большинство клиентов используют TCP, то они в конце-концовсами подстроятся под канал и потерь пакетов будет немного. А если разработчики μTorrent'а не рассчитают и перегрузят канал? Bittorrent будет работать — он будет работать и при 90% потерь пакетов. А вот будет ли там работать что-либо ещё? TCP при таких потерях не работает, к примеру…
При том, что сейчас по этому протоколу работают приложения, где важен минимальный пинг. Так не затруднит передаваемый торрент-трафик, работу интернет-телефонии и всего того, что сейчас работает по протоколу UDP, это имелось ввиду.
Да.
UDP пакеты легче, теоретически, при правильном выборе протокола конечным пользователем, нагрузка на сеть, наоборот, должна упасть.
Скачивать с сайта, где вылетает разная реклама — не лучший выбор, если можно скачать с офф. сайта
forum.utorrent.com/viewtopic.php?id=49813
Ссылка побилась
Ссылка побилась
Я просто сам с этого сайта качал, а копировал ссылку на оффициальный. Просто вышло что-то не так.
P.S. А карму минусовать зачем?
P.S. А карму минусовать зачем?
А нафиг пиарить помоечный варезник, забитый рекламой и кряками, вы же в приличной компании вообще-то находитесь, а не на каком нибудь убогом блоге! Фу, как мерзко((
Ну раз мы с Вами в приличной компании, могли бы дочитать мой комментарий. Что же, опишу весь процесс этого недоразумения еще раз подробно.
1. Прочитал в RSS о выходе новой версии µTorrent;
2. Зашел на упомянутый выше сайт и скачал программу;
3. Через некоторое время увидел на хабре об этом статью;
4. Заметил что нет ссылки на скачивание и решил ней поделиться с сообществом;
5. Зашел еще раз на тот_самый_сайт;
6. Чтобы не писать вручную скопировал текст ссылки и адрес (как выдите, на главной ссылка, которая название, не совсем та, а той оказалась ссылка немного правее);
Как видите, банальная механическая ошибка вылилась не одним минусом, что само по себе мне очень неприятно. Это послужило мне уроком и впредь буду проверять комментарии перед публикацией
1. Прочитал в RSS о выходе новой версии µTorrent;
2. Зашел на упомянутый выше сайт и скачал программу;
3. Через некоторое время увидел на хабре об этом статью;
4. Заметил что нет ссылки на скачивание и решил ней поделиться с сообществом;
5. Зашел еще раз на тот_самый_сайт;
6. Чтобы не писать вручную скопировал текст ссылки и адрес (как выдите, на главной ссылка, которая название, не совсем та, а той оказалась ссылка немного правее);
Как видите, банальная механическая ошибка вылилась не одним минусом, что само по себе мне очень неприятно. Это послужило мне уроком и впредь буду проверять комментарии перед публикацией
Ну замечательно, если вы выводы сделали, а минусы по моему не стоят того, чтобы о них переживать))
Просто как вы видите, на Хабре очень не любят неуклюжий пиар всяких помоечных сайтиков (и правильно), а ваша ссылка слишком уж на них походила(( А разбираться, что кто имел в виду)) по каждому случаю просто некогда.
p.s. Как вы наверно, заметили, также на Хабре не любят вопросы «за что мне минусы?», или «прекратите минусовать», и тоже справедливо, иначе так бы мог выглядеть каждый второй комментарий. В таких ситуациях лучше просто исправить свою ошибку, а вопросов про карму не задавать, по крайней мере публично.
Просто как вы видите, на Хабре очень не любят неуклюжий пиар всяких помоечных сайтиков (и правильно), а ваша ссылка слишком уж на них походила(( А разбираться, что кто имел в виду)) по каждому случаю просто некогда.
p.s. Как вы наверно, заметили, также на Хабре не любят вопросы «за что мне минусы?», или «прекратите минусовать», и тоже справедливо, иначе так бы мог выглядеть каждый второй комментарий. В таких ситуациях лучше просто исправить свою ошибку, а вопросов про карму не задавать, по крайней мере публично.
ога, спасибо, и мешок троянов в придачу, да?
install udp-utorrent
?????
PROFIT
?????
PROFIT
шейпинг P2P, как мне кажется, очень даже полезен
и если вскоре он будет неэффективен, то это весьма плохая новость
>грозит для качества работы VoIP, многопользовательских игр и других приложений, которые используют UDP для передачи данных
а разве на TCP это скажется в меньшей степени? по-моему «обход» шейпинга скажется на всем сразу
и если вскоре он будет неэффективен, то это весьма плохая новость
>грозит для качества работы VoIP, многопользовательских игр и других приложений, которые используют UDP для передачи данных
а разве на TCP это скажется в меньшей степени? по-моему «обход» шейпинга скажется на всем сразу
Да, это проблемы провайдера. Но ни один провайдер не обладает бесконечными каналами. Уж лучше немного придержать P2P, чтобы остальное, более критичное к скорости и задержке, смогло нормально работать. Торренты не умрут, если скорость упадет даже на, скажем, четверть. А на VoIP, играх и прочем сильно скажется, если P2P забьет весь канал.
>В 1880 году Академия наук Британской империи решила спрогнозировать, что будет с Лондоном через 100 лет… миллиона лошадей, навоз от этих лошадей
Британские учёные позапрошлого века, а я смотрю они совсем не изменились.
Британские учёные позапрошлого века, а я смотрю они совсем не изменились.
Вы забываете что огромная часть p2p трафика останется внутри провайдера. Если целенаправленной оптимизации со стороны p2p клиентов до сих пор нет, то она обязательно должна появиться в недалеком будущем.
Пользователь имеет право только на то, что сказано (не запрещено) в контракте.
Повальное увлечение торрентами может привести к тому, что провайдеры открытым текстом начнут их запрещать, или иным образом регулировать траффик.
В одном из моих контрактов, если не ошибаюсь, запрещено использование VoIP (и, возможно, Instant Messaging), но пока за полгода никаких санкций не последовало.
Повальное увлечение торрентами может привести к тому, что провайдеры открытым текстом начнут их запрещать, или иным образом регулировать траффик.
В одном из моих контрактов, если не ошибаюсь, запрещено использование VoIP (и, возможно, Instant Messaging), но пока за полгода никаких санкций не последовало.
Только каналы не резиновые.
Вы готовы платить на пару порядков больше за реальную полосу? :)
Думаю, что провайдеры потому могут предоставить вам широкий канал за копейки, что большинство пользователей использует канал не полностью, и большую часть времени ничего не качают (у меня канал 6 МБит/сек с неограниченным трафиком, я пользуюсь интернетом 3-4 часа в сутки для сёрфинга, чата и чтения статей на хабре, иногда слушаю онлайн-радио, в таком режиме у меня выходит меньше 1 ГБ в месяц). За счёт таких клиентов другие могут беспрестанно забивать свой канал полностью, качая фильмы из торрент-сетей.
При честной оплате трафика и канала «качальщики» должны были бы платить в сто раз больше меня :)
Видимо, на данный момент процент экстремальных пользователей не высок, так что мой провайдер может себе позволить их обслуживать по общим тарифам.
Но если вдруг все разом начнут качать на всю ширину канала, провайдер загнётся :) и начнёт вводить санкции, вплоть до урезания канала и разрыва контракта или повышения тарифов.
Имхо, конечно, я не провайдер.
Думаю, что провайдеры потому могут предоставить вам широкий канал за копейки, что большинство пользователей использует канал не полностью, и большую часть времени ничего не качают (у меня канал 6 МБит/сек с неограниченным трафиком, я пользуюсь интернетом 3-4 часа в сутки для сёрфинга, чата и чтения статей на хабре, иногда слушаю онлайн-радио, в таком режиме у меня выходит меньше 1 ГБ в месяц). За счёт таких клиентов другие могут беспрестанно забивать свой канал полностью, качая фильмы из торрент-сетей.
При честной оплате трафика и канала «качальщики» должны были бы платить в сто раз больше меня :)
Видимо, на данный момент процент экстремальных пользователей не высок, так что мой провайдер может себе позволить их обслуживать по общим тарифам.
Но если вдруг все разом начнут качать на всю ширину канала, провайдер загнётся :) и начнёт вводить санкции, вплоть до урезания канала и разрыва контракта или повышения тарифов.
Имхо, конечно, я не провайдер.
А кеширование как-то реально настроить? С другой стороны, с торрента в основном качают нелицензированный контент, поэтому провайдеры вряд ли станут размещать у себя «опасные» файлы.
Либо можно как во времена ФИДО. Несколько качают и раздают на всю подсеть. Это можно и в торрент-клиенте реализовать.
Либо можно как во времена ФИДО. Несколько качают и раздают на всю подсеть. Это можно и в торрент-клиенте реализовать.
… Провайдер может устанавливать ограничения для «супер-мега-качальщиков», поскольку его конечная цель не великое счастье абонентов, а экономическая эффективность бизнеса.
Это я Вам (по секрету) как сотрудник компании-провайдера говорю.
P.S. «Взгляд, конечно, варварский, но верный!» (с) И. Бродский
Это я Вам (по секрету) как сотрудник компании-провайдера говорю.
P.S. «Взгляд, конечно, варварский, но верный!» (с) И. Бродский
Этот вариант пожалуй только больше нагрузит сеть в начале месяца, а потом все будут бродить по сайтам и копить ссылки, утрирую конечно, но проблему это не решит.
Привер spb.tvoe.tv. При увеличении скоростей на тарифах происходит смена тарифного плана(если нужно абоненту), и на тарифном плане с поднятой скоростью(за те же деньги) вводится ограничение в 100Гб/мес, с урезанием скорости в два раза после превышения и до конца месяца. Простое и красивое решение по моему. =)
По мне так если уж я плачу за сеть, так и юзаю ее по полной, хоть трава не расти! И если от этого кто-то пострадает — пусть с судится с брехливым провайдером, я Интернетом пользуюсь на законных основаниях!
А вообще да, по ходу массовый анлим (и до провинции дошел, радость то какая!) основывается на большом количестиве не «качающих» массово пользователей.
А вообще да, по ходу массовый анлим (и до провинции дошел, радость то какая!) основывается на большом количестиве не «качающих» массово пользователей.
>Для торрентов пинг снижается с 2000 мс до 50-100 мс
Эээээ!!! Вы статью то читали по вашей же ссылке?
Пинг снижается не для торрентов, а как раз для «VoIP, многопользовательских игр и других приложений»!
А у вас написано так, что эти приложения вообще чуть ли не перестанут работать, хотя в действительности ради их качественной работы новый протокол и был создан.
Эээээ!!! Вы статью то читали по вашей же ссылке?
Пинг снижается не для торрентов, а как раз для «VoIP, многопользовательских игр и других приложений»!
А у вас написано так, что эти приложения вообще чуть ли не перестанут работать, хотя в действительности ради их качественной работы новый протокол и был создан.
Я тоже понял, что при использовании UDP вместо TCP в торрентах, пинг в играх снижается с 2000 до 50-100:
In one example, BitTorrent DNA was used to download and seed game updates while an
online multiplayer game was being played. With TCP used for transport the way it is usually
used in BitTorrent, ping times shot up to 2000 milliseconds and beyond and stayed there
while seeding. With the novel congestion control, ping times were in the 50-100
millisecond range, while the upload rate remained essentially unchanged and, therefore,
close to the uplink capacity minus game traffic. This is an improvement from a network
nonfunctional by modern standard where users expect interactive apps to work, to a
network essentially undistinguishable from absence of P2P.
In one example, BitTorrent DNA was used to download and seed game updates while an
online multiplayer game was being played. With TCP used for transport the way it is usually
used in BitTorrent, ping times shot up to 2000 milliseconds and beyond and stayed there
while seeding. With the novel congestion control, ping times were in the 50-100
millisecond range, while the upload rate remained essentially unchanged and, therefore,
close to the uplink capacity minus game traffic. This is an improvement from a network
nonfunctional by modern standard where users expect interactive apps to work, to a
network essentially undistinguishable from absence of P2P.
Люди не только в шутеры онлайн играют. Например в point&click вариантах MMORPG спокойно можно даже сражатся с большим пингом. Гонки, где не предусмотрено взаимодействие с оппенентами тоже не страдают — едете себе и едете, трасса то у вас на компьютере лежит, а не на сервере.
И это только два небольших примера.
И это только два небольших примера.
Неужели смогу нормально качать…
Как говорит мой провайдер: «256 кбит это остальной интернет, закачка только 128»
Как говорит мой провайдер: «256 кбит это остальной интернет, закачка только 128»
UDP в основом используется в приложениях реального времени для обеспечения быстрого обмена пакетами.
В частности в играх. И я думаю что UDP траффик в основном генерируется как раз играми.
Интересно, это повлияет на популярные онлайновые игры, такие как WoW?
В частности в играх. И я думаю что UDP траффик в основном генерируется как раз играми.
Интересно, это повлияет на популярные онлайновые игры, такие как WoW?
Меня больше всего беспокоит, как будут обстоять дела с различными конфигурациями NAT'а и UDP. Ведь TCP в случае NAT'а имеет дополнительные преимущества.
Спасибо, видел, что в новой версии добавили поддержку этого протокола, но небыло времени разобраться для чего это нужно.
У меня такой вопрос, если я включу в настройках использование только этого протокола, то он будет соединяться только с теми у кого стоит версия 1.9?
У меня такой вопрос, если я включу в настройках использование только этого протокола, то он будет соединяться только с теми у кого стоит версия 1.9?
УЖС! Просто ужас! Это я говорю как админ провайдера.
Если раньше мы ставили приоретет на UDP траффик, чтобы нашим VoIP клиентам, да геймерам было полегче, то теперь придётся чтото новое придумывать, а пока геймеры станут лучшими друзьями нашего тех. саппорта
Если раньше мы ставили приоретет на UDP траффик, чтобы нашим VoIP клиентам, да геймерам было полегче, то теперь придётся чтото новое придумывать, а пока геймеры станут лучшими друзьями нашего тех. саппорта
Ну, придется использовать более интеллектуальное железо/софт для DPI (Deep Packet Inspection).
Хотя, я думаю, сейчас в DPI нет сигнатур и шаблонов на uTP. Но, думаю, появится.
Хотя, я думаю, сейчас в DPI нет сигнатур и шаблонов на uTP. Но, думаю, появится.
Дада, над этим уже думали. Слава богу времени на размышление пока хватает.
Наши сетевики сказали, что ACLи под DLink 3028, 3526 которые пакетики торрента находить будут написать реально, но вот как это всё на практике будет — совсем другой вопрос(шифрованые пакеты вылавливаться будут навряд ли). В худшем случае придётся менять оборудование, а это не только много-много $$ на железо, так ещё и работа дополнительная на весь IT отдел, который тоже за хлеб и воду не работает.
Наши сетевики сказали, что ACLи под DLink 3028, 3526 которые пакетики торрента находить будут написать реально, но вот как это всё на практике будет — совсем другой вопрос(шифрованые пакеты вылавливаться будут навряд ли). В худшем случае придётся менять оборудование, а это не только много-много $$ на железо, так ещё и работа дополнительная на весь IT отдел, который тоже за хлеб и воду не работает.
Интересно, как его вылавливать? Потому что это будет обычный UDP протокол с работой по стандартным портам. Какие есть признаки, по которым можно на обычном маршрутизаторе отличить торрент трафик от того же, например, VoIP?
Выходом может, конечно, политика запрещения всего и разрешения отдельных портов и протоколов. Но это оттолкнет много клиентов.
Выходом может, конечно, политика запрещения всего и разрешения отдельных портов и протоколов. Но это оттолкнет много клиентов.
Насколько я понимаю(я не очень болшой спец в p2p) у торрент-клиентов есть свой протокол общения между собой. Раз есть протокол(стандартизация), то по нему можно и идентифицировать пакеты, а вот что делать с шифроваными пакетами — это другой уже вопрос…
Насколько я знаю, слишком много вычислительных ресурсов должно быть задействовано, чтобы рыться внутри ip пакета и проверять байтики внутри payload-а. Теоретически и алгоритмически сделать это нетрудно, но железяки должны быть специальные с NPU процессорами всякими.
>у торрент-клиентов есть свой протокол общения между собой
Нет там ничего, трекер просто говорит с кем соединятся и всё, а дальше клиентские проги по TCP/IP или UDP/IP подключаются. Проверка идёт по кусочкам, вот если 1 бит пришёл с ошибкой, а кусочек, к примеру, 4 мб, то и перекачивать нужно эти самые 4 мб, хотя может и меньше, если этот кусок дал не один участник, или если реализовать множественную проверку хеша, в любом случае это плохо.
Другое дело, что по TCP/IP такой лажи не будет и поддержка как правило на аппаратном, а не программном уровне (это намёк на пока что любую реализацию битторрента). В свете нынешних обсуждений битторрент можно рассматривать как BitTorent/TCP/IP или BitTorent/UDP/IP.
И ограничения соотвественно точно такие же как у семейства протоколов TCP/IP. То есть переписывать, что-то наподобие TCP/IP или UDP/IP это полный анрил, особенно почасти бессмысленности, а вот создать создать программы круче битторента вполне возможно даже программисту одиночке.
Нет там ничего, трекер просто говорит с кем соединятся и всё, а дальше клиентские проги по TCP/IP или UDP/IP подключаются. Проверка идёт по кусочкам, вот если 1 бит пришёл с ошибкой, а кусочек, к примеру, 4 мб, то и перекачивать нужно эти самые 4 мб, хотя может и меньше, если этот кусок дал не один участник, или если реализовать множественную проверку хеша, в любом случае это плохо.
Другое дело, что по TCP/IP такой лажи не будет и поддержка как правило на аппаратном, а не программном уровне (это намёк на пока что любую реализацию битторрента). В свете нынешних обсуждений битторрент можно рассматривать как BitTorent/TCP/IP или BitTorent/UDP/IP.
И ограничения соотвественно точно такие же как у семейства протоколов TCP/IP. То есть переписывать, что-то наподобие TCP/IP или UDP/IP это полный анрил, особенно почасти бессмысленности, а вот создать создать программы круче битторента вполне возможно даже программисту одиночке.
Один клиент должен сообщить другому какой чанк какойго куска какого торрента он хочет у него получить и какие части имеются у него для отдачи. Это и есть протокол.
Chunk это и есть кусок, буквально дословный перевод, разделение на куски в битторренте это часть протокола битторрента, а закачка каждого кусочка по TCP/IP или UDP/IP это соотвественно эти протоколы, но не битторрент.
Куски, которые вы имеете в вашем понимании не являются монолитными, они качаются ещё меньшими, уже не фиксироваными частями.
Сделано для ускорения и повышиной безопасности, чтобы один кусок(в дословном переводе piece) никогда не качался с одного и тогоже пира. Ибо checksum у каждого куска очень маленький и подделать кусок под него не особая проблема для совсеменных компьютеров.
Протокол общения клинетов ожно найти тут
как видно один клиент запрашивает у другого часть куска, тот же в свою очередь в тойже сессии отдаёт ему етот кусок. Соответственно один клиент делает запрос request блаблабла, второй отвечает ему piece блаблабла и тут же данные. Тут мы можем идентифицировать ответ piece и резать на нём скорость.
Сделано для ускорения и повышиной безопасности, чтобы один кусок(в дословном переводе piece) никогда не качался с одного и тогоже пира. Ибо checksum у каждого куска очень маленький и подделать кусок под него не особая проблема для совсеменных компьютеров.
Протокол общения клинетов ожно найти тут
как видно один клиент запрашивает у другого часть куска, тот же в свою очередь в тойже сессии отдаёт ему етот кусок. Соответственно один клиент делает запрос request блаблабла, второй отвечает ему piece блаблабла и тут же данные. Тут мы можем идентифицировать ответ piece и резать на нём скорость.
Мне как бы это не нужно, так как я программировал всё это на .NET и естественно понимаю как работает пересылка. Про подделку данных уже писал в самом верху, а с программной реализацией битторрента знаком по битшарпу (http://ru.wikipedia.org/wiki/Bitsharp).
Всё таки не понимаю в какую сторону вы ведёте разговор.
Сначала вы говорите, что нет там никакого протокола.
«Нет там ничего, трекер просто говорит с кем соединятся и всё, а дальше клиентские проги по TCP/IP или UDP/IP подключаются», показывая тем самым полное незнание темы, потом утверждаете, что знаете всё и оказывается сами писали толиклиенттолисервер для торрента. В общем в этой теме лучше обращать внимание на более осмысленные высказывания.
Сначала вы говорите, что нет там никакого протокола.
«Нет там ничего, трекер просто говорит с кем соединятся и всё, а дальше клиентские проги по TCP/IP или UDP/IP подключаются», показывая тем самым полное незнание темы, потом утверждаете, что знаете всё и оказывается сами писали толиклиенттолисервер для торрента. В общем в этой теме лучше обращать внимание на более осмысленные высказывания.
Ты же абсолютно правильно сказал, что не являешься спецом в этой теме, но почему-то решил по трольски на меня наехать. Было сказано буквально следующее:
>Раз есть протокол(стандартизация), то по нему можно и идентифицировать пакеты, а вот что делать с шифроваными пакетами
Так вот идентифицировать можно лишь битторентовские куски по SHA-1. Пакеты это термин TCP/IP, там тебе и шифрованные каналы и всё прочее. Если смог установить соединение с другим пиром по защищённому каналу, то нет никаких проблем, всё стандартно.
Библиотеку битторента я не писал, использовал Bitsharp, её можно выкачать и скомпилировать. Можно смотреть код и узнавать как устроен протокол битторрент (клиентская и серверная части) на конкретном примере.
Если тебе интересно, не поленись зайди по ссылке, скачай код и изучи, или найди другую реализацию, на языке, на котором программируешь. Меряться же письками в такой манере «я умный ты дурак» не пристало нормальным людям.
>Раз есть протокол(стандартизация), то по нему можно и идентифицировать пакеты, а вот что делать с шифроваными пакетами
Так вот идентифицировать можно лишь битторентовские куски по SHA-1. Пакеты это термин TCP/IP, там тебе и шифрованные каналы и всё прочее. Если смог установить соединение с другим пиром по защищённому каналу, то нет никаких проблем, всё стандартно.
Библиотеку битторента я не писал, использовал Bitsharp, её можно выкачать и скомпилировать. Можно смотреть код и узнавать как устроен протокол битторрент (клиентская и серверная части) на конкретном примере.
Если тебе интересно, не поленись зайди по ссылке, скачай код и изучи, или найди другую реализацию, на языке, на котором программируешь. Меряться же письками в такой манере «я умный ты дурак» не пристало нормальным людям.
вообще, видео и аудио потоки могут использоваться метки приоритетов типа 802.1d и 802.1q
по крайней мере эти стандарты задумывались чтобы стало возможным отличать аудио и видео трафик от всего остального
правда оно не будет спасать, если файлообменная софтина будет тоже тегать свой трафик как аудио
по крайней мере эти стандарты задумывались чтобы стало возможным отличать аудио и видео трафик от всего остального
правда оно не будет спасать, если файлообменная софтина будет тоже тегать свой трафик как аудио
QoS начиная с «самых низов», с точек аггрегации. И layer7 filtering / NBAR на пограничниках.
Проблема не с QoS, проблема в том, что торрент трафик попадает в категорию обычного интернета и будет забивать Skype, YouTube и другие приятные глазу и уху сервисы, которые плавают в том же QoS классе. :(
Сразу вопрос: как можно отличить игровой трафф от торрента на уровне агрегации? Пока единственное, что пришло в голову это по размеру пакета.
Тоесть больший приоретет даём маленьким UDP под которые попадают DNS запросы и гейм траффик. А что тогда с VoIP?
Конечно можно ещё давать больше приоретета игровым портам, но я думаю торрентчики и на них тогда пересядут.
Тоесть больший приоретет даём маленьким UDP под которые попадают DNS запросы и гейм траффик. А что тогда с VoIP?
Конечно можно ещё давать больше приоретета игровым портам, но я думаю торрентчики и на них тогда пересядут.
Я не админ и имею только поверхностное представление о деталях протоколов передачи данных.
Пусть U = число юзеров, B = ширина канала.
Решение №1:
1. делим общий канал на индивидуальные, обладающие шириной B/U — это норма потребления, гарантированная каждому юзеру
2. если канал простаивает (= ничего не передаётся), то его ёмкость отдаётся одному из других канало, т.е. один из юзеров (у кого канал забит, трафик выше определённого порога) получает скорость 2 * B/U
ещё вариант:
1. дробим канал ещё сильнее: B / (10 * U)
2. если юзеру достаточно B / (10 * U) (icq например или простой сёрфинг), то его «излишки» раздаются другим
Тип трафика не важен.
Вопрос: почему так не делают?
Пусть U = число юзеров, B = ширина канала.
Решение №1:
1. делим общий канал на индивидуальные, обладающие шириной B/U — это норма потребления, гарантированная каждому юзеру
2. если канал простаивает (= ничего не передаётся), то его ёмкость отдаётся одному из других канало, т.е. один из юзеров (у кого канал забит, трафик выше определённого порога) получает скорость 2 * B/U
ещё вариант:
1. дробим канал ещё сильнее: B / (10 * U)
2. если юзеру достаточно B / (10 * U) (icq например или простой сёрфинг), то его «излишки» раздаются другим
Тип трафика не важен.
Вопрос: почему так не делают?
Так и делается, но в часы пик, когда канал забит под завязку, часть траффика можно притормозить (p2p) а то что критично к задержкам (VoIP / games) пускать вперёд всех
> но в часы пик, когда канал забит под завязку, часть траффика можно притормозить
зачем? почему?
у каждого юзера есть своя доля канала, пусть ею и довольствуется
а провайдер должен честно информировать о минимально гарантированной ширине канала
> а то что критично к задержкам (VoIP / games) пускать вперёд всех
может быть тогда делать разные тарифные планы?
типа
1. «халявный» — очень дёшево, при наличии излишков, они все ваши, но в случае необходимости ваш канал может быть урезан до нуля
2. «надёжный» — подороже, но вы всегда знаете, что вам хватит на VoIP/игрушки
просто со стороны вся эта делёжка трафика кажется несуразной
я же плачу деньги: дайте мне мою часть канала и всё, где проблема-то?
зачем? почему?
у каждого юзера есть своя доля канала, пусть ею и довольствуется
а провайдер должен честно информировать о минимально гарантированной ширине канала
> а то что критично к задержкам (VoIP / games) пускать вперёд всех
может быть тогда делать разные тарифные планы?
типа
1. «халявный» — очень дёшево, при наличии излишков, они все ваши, но в случае необходимости ваш канал может быть урезан до нуля
2. «надёжный» — подороже, но вы всегда знаете, что вам хватит на VoIP/игрушки
просто со стороны вся эта делёжка трафика кажется несуразной
я же плачу деньги: дайте мне мою часть канала и всё, где проблема-то?
Проблема в том что рыночная цена на интернет в Питере 1000-750р за мегабит(не считая стоимости прокладки арендованного канала). А ведь самой компании нужно ещё и работникам платить, и дивиденды выплачивать по возможности, да на развитие деньги и при этом всё ещё и в плюсе оставаться. Вы платите намного меньше, чем получаете канала.
В реальности получается, что на одном канале в предположим 100 мегабит висит 1000 клиентов с минимальны тарифом 2Мегабита за 500р. Вот так получается на практике. И это не числа с потолка — это реальные цифры! Ужс, да? =)
В реальности получается, что на одном канале в предположим 100 мегабит висит 1000 клиентов с минимальны тарифом 2Мегабита за 500р. Вот так получается на практике. И это не числа с потолка — это реальные цифры! Ужс, да? =)
Ну, может не стоит держать клиентов за идиотов?
> В реальности получается, что на одном канале в предположим 100 мегабит висит 1000 клиентов с минимальны тарифом 2Мегабита за 500р. Вот так получается на практике.
Сделайте два честных тарифа:
1. «халявный», 300 руб.: от 100 килобит до 100 мегабит в зависимости от загрузки канала
2. «надёжный», 1000 руб.: гарантированный 1 мегабит, до 100 мегабит при свободном канале.
На бумаге второй тариф менее выгоден, чем «2 мифических мегабита за 500 руб.», но зато более надёжен и предсказуем с точки зрения постоянства доходов и отсутствия претензий от клиентов.
> В реальности получается, что на одном канале в предположим 100 мегабит висит 1000 клиентов с минимальны тарифом 2Мегабита за 500р. Вот так получается на практике.
Сделайте два честных тарифа:
1. «халявный», 300 руб.: от 100 килобит до 100 мегабит в зависимости от загрузки канала
2. «надёжный», 1000 руб.: гарантированный 1 мегабит, до 100 мегабит при свободном канале.
На бумаге второй тариф менее выгоден, чем «2 мифических мегабита за 500 руб.», но зато более надёжен и предсказуем с точки зрения постоянства доходов и отсутствия претензий от клиентов.
Дык провайдеры так и делают: но только они ограничивают «халявный» сверху и продают за 500руб. Причём поскольку максимальная скорость занижена у всех, то TopSeeder'ы забить канал не могут и вы скорее получаете 1000килобит, чем 100…
> но только они ограничивают «халявный» сверху и продают за 500руб.
1) обычно всё же продают ограничение *снизу*
когда я покупаю канал 1024 кбит, я ожидаю, что скорость будет ОТ 1024, но никак не ДО
2) та цифра скорости, которая сегодня заявлена для «халявных» тарифов, не значит вообще ничего, т.к. при необходимости провайдер всё равно урезает канал
> Причём поскольку максимальная скорость занижена у всех
по-моему речь как раз о том, что как правило она У ВСЕХ *завышена*
1) обычно всё же продают ограничение *снизу*
когда я покупаю канал 1024 кбит, я ожидаю, что скорость будет ОТ 1024, но никак не ДО
2) та цифра скорости, которая сегодня заявлена для «халявных» тарифов, не значит вообще ничего, т.к. при необходимости провайдер всё равно урезает канал
> Причём поскольку максимальная скорость занижена у всех
по-моему речь как раз о том, что как правило она У ВСЕХ *завышена*
когда я покупаю канал 1024 кбит, я ожидаю, что скорость будет ОТ 1024, но никак не ДОВы можете ожидать что угодно, но получаете вы именно до 1024. Задача маркетинга — объяснить вам почему вы получили то, за что заплатили :-)
> Причём поскольку максимальная скорость занижена у всехНет. Она могла бы быть и 100Mbit, и 1Gbit, но тогда «Top Seeder'ы» заняли бы весь канал и «нормальные пользователи» получили бы 100kbit…
по-моему речь как раз о том, что как правило она У ВСЕХ *завышена*
Мдаа, с такими неутешительными прогнозами, можно начинать переносить дату «Конец Интернета» чуть ближе, чем намечали ранее (2012 г.)
P.S. «Спокойствие, только спокойствие» © Карлсон =)
P.S. «Спокойствие, только спокойствие» © Карлсон =)
Плюс уже в том что уменьшат нагрузку на TCP(Web-serfing и не только), и соответственно лучше будет разрабатываться взаимодействие с UDP, который torrent будет использовать как положенно программам инфраструктурного(Voip и проч.), личного(p2p) и по интересам направления(game и проч.). Не технический специалист, потому рассуждения более концептуальные, и могут содержать ошибки(*ntsbc4p).
Но чем это грозит для качества работы VoIP, многопользовательских игр и других приложений, которые используют UDP для передачи данных (и в данный момент потребляют не более 2% мирового трафика) — сложно даже предположить.
А каким они, собственно, тут боком? Неужели у вас UDP-шный траффик идет по отдельно выделенному оптоволоконному каналу? Совершенно непонятная фраза. Тем более что при переходе торрентовского траффика на UDP, загрузка магистральных каналов, скорее всего, уменьшится.
А каким они, собственно, тут боком? Неужели у вас UDP-шный траффик идет по отдельно выделенному оптоволоконному каналу? Совершенно непонятная фраза. Тем более что при переходе торрентовского траффика на UDP, загрузка магистральных каналов, скорее всего, уменьшится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
µTorrent переходит на UDP-протокол