uTorrent съест все каналы и нагрузит оборудование провайдеров

Внимательно читаем http://forum.nag.ru/forum/index.php?showtopic=55025&st=0 вот это обсуждение.

Коротко - будет "п...." каналам, будет "хорошо" оборудованию провайдеров, как итог будет "ну очень хорошо" пользователям (VoIP, онлайн игры) из за удвоения pps с пропорциональным уменьшением среднего packet size.

Краткие перспективы - большая вероятность traffic cap (месячный лимит) на всех ТП у ВСЕХ [с возможностью увеличения лимита за доп денежку].
(полумеры Билайна по ассиметрии канала к сожалению не панацея).

Bras'ов Дом.ру как ни странно это должно коснуться меньше всего, из за особенностей выбранной авторизации (PPPoE), но коснется тоже.

Больше всего "поплохеет" L2tp и PPtP'ной авторизации. (У кого не ASR Циски и ПС на агрегации).

Вероятнее всего расширение канала у Билайна "съестся" вот этой вещью (если Билайн не введет ограничение на UDP/pps с одного IP [технический возможно, 95% и не заметят если поставить pps посчитанный из расчета 2х G711 + 2х контерстрайк клиентов на порту коммутатора]). Именно так сейчас действуют при превышении на порту определенного порога pps по мультикасту.

В общем, разработчики uTorrent (в том числе там есть и русские программисты) хотели как лучше, а получилось как всегда (при вводе в full-scale эксплуатацию (включение по умолчанию этого (uTP) режима в uTorrent 2.x.x).

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

(все вышесказанное - IMHO)

 

Знают, скорее всего так: (взято для примера из ветки упомянутой в первом посте)

-A p2p -m udp -p udp -m string --hex-string "|7F FF FF FF AB|" --algo kmp --from 40 --to 44 -m statictic --mode random --probability 0.90 -j DROP

Т.е. если увидели такой трафик, то убить пакет с вероятностью 90% именно вероятностью, а не полностью, т.е. вроде и работает, но фигово, и без признания провайдера в фильтрации не разберешся, т.к. 10% все же проходят.

 

Угу:
Changelog - жирным выделенно то, на что хотелось бы обратить внимание

-- 2010-02-18: Version 2.0.1 Beta (build 18284)
- Fix: high CPU bug due to TCP and uTP connection race condition fix
- Fix: issue where we would incorrectly report being as seed when using magnet links
- Feature: Add option to render the legend as solid instead of transparent

-- 2010-02-18: Version 2.0.1 Beta (build 18244)
- Fix: Make toolbar icons render nice on vista+
- Feature: Add option to not report problems
- Change: Make uTP packet size depend on global uTP rate instead of the rate of each individual connection
- Feature: add detailed network overhead breakdown graph
- Fix: UDP tracker peer list parsing
- Change: increase allowed max packet size (fixes issue with torrents with more than 131000 pieces)
- Change: increase the max number of AddTorrent windows from 5 to 20
- Fix: BEP 22 would sometimes not kick in for new torrents
- Feature: make initial uTP packet size configurable
- Fix: Close download bar with hotkey
- Feature: display overhead at status bar
- Change: Do not count local overhead if local peers are not limited
- Change: Count overhead for transfer caps
- Feature: added legend to graphs
- Feature: it's now possible to graph the tcp_rate_control rates
- Fix: potential buffer overrun with mismatched langpack
- Fix: enable apply button if changing scheduler
- Change: Do not stop torrents when automatically shutdown
- Fix: DHT would store duplicate peers for torrents
- Feature: Added support for suggest piece messages (part of FAST extensions)
- Fix: Potential bug when accessing the root directory of a URL
- Fix: 'Cookie' setting in WebUI add-torrent-by-url works again
- Fix: simultaneous uTP and TCP connection race condition


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