Внимательно читаем 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)
нас-это кого? анжинеры на тамошнем форуме сами толком похоже не понимают что к чему. Абоненту глубоко фиолетово нюансы,ему скорость дай,и туда и обратно,тот же билайн глубоко облажался с урезанием обратного трафика.и теперь он претендент номер один на золотой унитаз... если выделенные провайдеры начнут резать качков,они потеряют своих основных абонентов,потому что кому действительно нужен интернет,вполне устраивают беспроводные провайдеры(может и не всех конечно...)
А мне как-то кажется (крестюсь, крестюсь), что ничего страшного не будет. По ссылке, что автор привёл, так и непонятно, насколько критично для их оборудования возрастание этого ппс? Ну возросло в 1,5 раза, дальше чего? Это очень много? Оно сломается, если будет продолжать в таком режиме работать?
аленький цветочек, Это надо было помещать в тему тут Новость прошлогодняя 02.12.2008 Уж не оттого ли Annex принял первую волну? Посмотрим, качество инета должно повыситься, либо провайдеры будут сливать.
Возрастает нагрузка на оборудование провайдера, как бороться с этой нагрузкой, чтобы не вкладываться в более мощное, они пока не знают. Или уже знают?
Знают, скорее всего так: (взято для примера из ветки упомянутой в первом посте) -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 еще долго будут отлаживать... на хомячках, а проввайдеры будут более внимательно смотреть на поведение/структуру трафика.
а причем тут способ авторизации? добавлено через 2 минуты На портах обычно стоит storm-control broadcast level 1.00 storm-control multicast level 1.00 storm-control unicast level 90.00 storm-control action trap Так что, все легко отслеживается и в случае чего можно и дропать. p.s. хотя мож я чего-то и путаю из-за непонимания работы нового протокола uTorrent...