Открыты исходные коды протокола uTP
 

Разработчики BitTorrent открыли исходные коды протокола uTorrent Transport Protocol (uTP), используемого в клиенте uTorrent. Исходники доступны на C++ и распространяются под лицензией MIT.

Напомним, что с выходом второй версии uTorrent разработчики особо акцентировали внимание на том, что используемый в нем протокол uTP позволяет избавиться от пробок в сети.

Если торент-трафик занимает весь пропускной канал и uTorrent обнаружит активность других сетевых программ, то интенсивность передачи данных в p2p-сетях временно будет снижена, и это позволит более комфортно работать с другими приложениями. Такой подход к управлению трафиком одновременно снижает загрузку как локально, так и для провайдера.

Опционально можно настраивать время суток, когда будет действовать ограничение. uTP позволяет более эффективно справляться с перегрузками в сети, чем блокирование или урезание трафика провайдером. Не стоит, однако, думать, что протокол каким-либо образом снижает общую скорость обмена информацией в p2p-сетях. Как только сеть не загружена другим трафиком, uTP использует ее на 100%.

Источник R2B.ru

ps: а качнуть исходники можно на гитхабе..

Забавно, жаль для PHP трекера ценность ноль, а так можно было бы много чего узнать о клиенте.

Веселее всего другое - uTP рекомендуется к немедленному отключению сразу после установки клиента, ибо, как показала практика, провайдерское оборудование (конкретнее - промежуточные роутеры) грузятся просто вау ... ибо клиент начинает люто бешено уменьшать размер пакета и отсылать их БОЛЬШЕ, в итоге умный провайдерский свич вас просто блочит за флуд.

Это у кривых провайдеров только.

А еще у всех обладателей домашних роутеров-мыльниц. Которые тоже плохо переносят большой поток мелких udp пакетов - ввиду адаптированности ихнего довольно чахлого мозга к большим сегментированным tcp пакетам ;)
А профита от этого uTP - полный ноль, если не минус - ввиду крайней сырости... Ну разве что на ADSL (для которых он разрабатывался) что-то можно будет выжать...

Адаптированность к большим пакетам не делает их неадаптированными к куче маленьких, в отличии от них для мелких пакетов ничего делать не надо кроме мощности процессора достаточной при большой скорости, но при равных фрагментация TCP жрёт куда больше.

Делает. Роутеры адаптировались к обработке больших, фрагментированных tcp пакетов средствами довольно хилого проца. Тут и куча всяких оффлоадов, заточенных в первую очередь под tcp (в т.ч. и полуаппаратный NAT), и весьма хилый мозг для уменьшения нагрева (от 100МГц в самом хилом роутере до 300-400 в последних - ессно, имею ввиду 100мбит SOHO по вменяемым ценам, которые стоят у большинства юзеров).
Основные ресурсы процессора роутера тратятся на маршрутизацию/нат/фильтрацию пакета согласно анализу заголовка, и затраты практически не зависят от размера пакета - т.е., что переслать 100 байт, что переслать 1500байт для роутера примерно равнозначно.


О tcp fragmentation offload к примеру что-то слышали? Или вы считаете, что поток пакетов 150-300 байт размером роутеру легче переварить, чем поток пакетов по 1500 байт с тем же траффиком? :)

Кстати, я лично наблюдал на нашем бордюре (линукс-роутер) удвоение нагрузки на проц за менее чем 2 недели при том же траффике - вследствие введения uTP в массы...

Это известно, а толку то. Не в этом нынче проблема в 90% ,а в тупо кривой реализации VPN, особенно при работе по PPTP. Без него даже хилые DIR-300 вполне живут с торрентами.

А tcp fragmentation - в udp такого быть не может в принципе при раскладе с mutp, там в протоколе фрагментация по n байт идёт, а потом уже по udp остатки мелочи только досылаются. То есть блок и пакет l5 всяко больше чем дефолт 1.5к l3 udp, это кстати весьма забавно, можно там же поправить всё и сделать чтобы все пакеты были >= ваш MTU и снять нагрузку по фрагментации в принципе.

P.S. Линукс-рутер это что? Все линуксовые длинки например говно по определению, а если удвоение CPU load на никсовом PC - у тебя просто кривые руки.

DIR-300 новый - там собссно Ralink MIPS ~400МГц стоит... И если уж он захлебывается - что говорить о более хилых. Те же DIR-100 к примеру убогие, и всякие линксисы с тплинками...


Может, может. Зарезано входящие icmp криворуким юзером с параноидальным файрволом - и пошел uTP слать пакеты по 1500 байт, которые роутером сегментируются на 14xx байт+"хвостик", увеличивая нагрузку на роутер вдвое...


А кого волнует что на l5 творится, если роутер на l3 все жует? Будь хоть мегабайт блок данных - если ущербный софт его будет слать пакетами по 150 байт, роутеру от этого не полегчает.


Железка-бордюр, прокачивающая через себя более 300 мбит траффика в каждую сторону. При возрастании pps на % 40 и при изменении типа траффика (значительный рост udp - со всеми вытекающими "особенностями") - неудивительно, что нагрузка возросла.


Да ну? И у моего апстрима (инфоком), которого после запуска uTP несколько месяцев иногда пучило (не смотря на то, что у него циски - порой в прайм-тайм аплоад/даунлоад шел "гребенкой") - тоже кривые руки? И у всех остальных провов - тоже? :) А на наге топик на 40 страниц, где обсуждается как рубить uTP - видать от скуки завели, и пишут модули к нетграфу для вырезания каки от скуки? :)

Если вы не знали, нагрузка на любой софтроутер зависит в первую очередь от кол-ва пакетов в секунду, и от типа траффика (вернее, возможностей оффлоада сетевух и поведения модуля conntrack для различных типов траффика - так, для udp понятие сессии отсутствует, и в conntrack такие "сессии" удаляются только по тайм-ауту - до того же висят, кушая ресурсы). Железные л3 свичи - не так критичны к ппс, но все же и у них есть ограничение в ппс.

Кстати, пока не замечено ни "уменьшения нагрузки каналов" от uTP, ни хоть сколь-нибудь заметной пользы для юзеров от него - а вот вред уже замечен и, что самое интересное, это признали даже разработчики :)

О том, что данный траффик весьма проблематично отделить от траффика, требующего минимальные задержки (VoIP, UDP игровой траффик) и, следовательно, проблематично обеспечить качество услуг в вечерний прайм-тайм для мультиплексированных каналов с негарантированной скоростью (типичный домашний интернет) - помолчу.