БерлuнгерУважаемые!

Я понимаю что вы первоклассные специалисты (один как минимум - много знает и теории и опыта, но молчит сцуко - не икак синдром вахтера). Но вы можете выдать мне нормальное простое решение ?
Наверное потому, что его нету? ;-)

БерлuнгерPA3YMпропущено...

Наверное потому, что его нету? ;-)
"интуиция - способность головы думать жопой"
моя жопа считает что оно есть!
Моя голова утверждает ;-) что, поскольку для торрента UDP транспорт был выбран именно за скорость доставки пакетов - проблема решается только на уровне приложения. Например KTorrent имеет в настройках как Maximum upload speed так и Maximum download speed. Понятно, что очередной чанк файла он забирает со скоростью отдающего, но за следующим он пойдет только через некоторый промежуток времени, так, чтобы в среднем не превысить лимит закачки.

БерлuнгерPA3YMМоя голова утверждает ;-) что, поскольку для торрента UDP транспорт был выбран именно за скорость доставки пакетов - проблема решается только на уровне приложения. Например KTorrent имеет в настройках как Maximum upload speed так и Maximum download speed. Понятно, что очередной чанк файла он забирает со скоростью отдающего, но за следующим он пойдет только через некоторый промежуток времени, так, чтобы в среднем не превысить лимит закачки.
это круто и понятно.

как это влияет на сервер ? сервер занимается шейпингом, а торрент висит на виртуалке на сервере...
eee-pc это тоже Вы?

БерлuнгерPA3YMпропущено...

eee-pc это тоже Вы?
да
Я правильно понимаю - виртуалка была установлена лишь потому, что не получилось классифицировать пакеты маркерами и возникла идея посадить торрент на отдельный IP таким макаром? Какой трафик мешает - тот, что вы скачиваете, тот, что на отдачу или оба?

ТехничкинPA3YMпропущено...

Моя голова утверждает ;-) что, поскольку для торрента UDP транспорт был выбран именно за скорость доставки пакетов - проблема решается только на уровне приложения. Например KTorrent имеет в настройках как Maximum upload speed так и Maximum download speed. Понятно, что очередной чанк файла он забирает со скоростью отдающего, но за следующим он пойдет только через некоторый промежуток времени, так, чтобы в среднем не превысить лимит закачки.

ЗачОтный бред. Пиши еще, далеко пойдешь.
Перечитал спецификацию протокола bittorrent и вынужден согласиться - клиенты обмениваются файлами по TCP а по UDP ходит DHT. Почему-то считал, что TCP для трекера и UDP для трансфера, каюсь.
P.S.
А вам бы только поржать ;-)

Техничкин,

Кстати. Несмотря на мою путаницу с протоколами наблюдение за трафиком показывает, что при скачивании 256К сегмента скачиваются 16К 'piece' со скоростью отдачи сида, после чего торрент клиент делает паузу тем больше, чем сильнее зажата скорость скачивания. Так что смысла вашей реплики я так и не понял (если вы не тролль и смысл имел место быть).
tshark

ТехничкинPA3YMТехничкин,

Кстати. Несмотря на мою путаницу с протоколами наблюдение за трафиком показывает, что при скачивании 256К сегмента скачиваются 16К 'piece' со скоростью отдачи сида, после чего торрент клиент делает паузу тем больше, чем сильнее зажата скорость скачивания. Так что смысла вашей реплики я так и не понял (если вы не тролль и смысл имел место быть).

Специально для тебя и того упоротого балбеса, который сегодня выступал о том, что управлять UTP трафиком ну никак нельзя (и UTP используется и для передачи данных, не только для поиска пиров по DHT).

Статья специально для колхозников: http://habrahabr.ru/blogs/p2p/68332/

авторЗамечу, что в uTP это делается всегда, даже в версии 1.8, а скорость TCP-трафика подстраивается под загрузку канала только в 2.0. В uTP постоянно меряется время отклика от пиров, с которыми происходит обмен данными. как только этот «пинг» начинает увеличиваться, задолго до начала потерь пакетов, µTorrent сбавляет скорость.
И что? Потоком данных управляет клиентское приложение и пофигу какой там у него протокол транспортного уровня. Админу, рулящему маршрутизатором, это никаких преимуществ не дает. А это новшество в торрент протоколе не более чем инкапсуляция хоть в TCP, хоть в UDP своего ( uTP хе-хе) протокола, именно который и содержит более удобный механизм обработки затыков в трафике. Так что почитай драфт на английском и угомонись.

netwindPA3YMПеречитал спецификацию протокола bittorrent и вынужден согласиться - клиенты обмениваются файлами по TCP а по UDP ходит DHT. Почему-то считал, что TCP для трекера и UDP для трансфера, каюсь.
вот почему :µTP - переимплементация TCP на основе протокола UDP с измененным контролем за переполнением, который реагирует раньше, чем соответствующий алгоритм в TCP. Таким образом, при увеличении загрузки канала µTP первым замедляется и отдает канал другим приложениям
Главный Пиратский Клиент ее поддерживает и активно развивает.
Почитал драфт протокола. Идея вроде неплохая. buffer delay based congestion control. Хотя и CUBIC вроде нормально заторы разгребает.

ТехничкинPA3YMИ что? Потоком данных управляет клиентское приложение и пофигу какой там у него протокол транспортного уровня. Админу, рулящему маршрутизатором, это никаких преимуществ не дает.

Какой запущенный случай. Итак, детишки.

Админ настроил ingress на 2 килобайта в секунду. Все, что выше - тупо дропается (в т.ч. TCP или UDP пакеты).
Внешний канал - 100 мегабит, внутренний - 100 мегабит.
Почему не происходит такого, что клиент, который сидит ПЕРЕД шейпером на 2к - забивает внутренний канал на все 100 мегабит (т.е. не доходя еще до шейпера)?

В utorrent не стоит стоит на скорость отправки . Т.е. должно слаться максимально быстро. И?

Кто там чем управляет?
Ты либо тупой, либо тролль, а скорее всего и то, и другое. Читай главу congestion control драфта.