[weldpua2008]

Я хочу что бы Вы все вдумалось в эти цыфры - UA-IX и MSK-IX на 20 и 16 месте в рейтенге top80 точек обмена траффика...

А что в этом удивительного, если народу стали массово раздавать доступ в Internet со скоростью 10Мбит/с и выше?

You can't get very high packet-per-second upload rates with max packet sizes on typical ADSL2, because they don't have more than 1 megabit/sec upload. And with many people unable even to GET those speeds due to poor quality lines and distance from the DSLAM, this is even less of an issue.

Вспомним популярные broadcast чат и другие программы в локалках - лет 10 назад? Они работали нормально? Да, Но как только скорость подключения в локалку стала 100Мбит и количество людей >1000 многие стали резать вин-локалку, поставили ДС++ хабы, или торрент-трекеры или порезали локалку на сегменты - но что-то всё равно делали так как прога и локалка были несовместимы....

 

Еще мысль не понятна?

Изменено 25 мая, 2010 пользователем weldpua2008

[hiller]

Да любую хрень при желании можно отфильтровать. И нужно это делать. Если не получится технически, применять юридические инструменты.

 

ps Иван, как я понимаю, Вы пользователь, зачем Вы здесь? Пугать нас супер-возможностями программеров из команды uTorrent?

Да кому вы нахрен нужны без торрентов!

В одноглазниках можно и через свисток мегафон/мтс/билайн посидеть.

 

Одного желания мало.

Тут даже с не шифрованным многие справится не могут. Просто сидят и ждут у нага погоды :)

А никто не говорит про torrent'ы в целом. Говорят про uTP и uTorrent. Их фильтровать можно и нужно. Не обязательно по сигнатурам, есть и другие способы.

Договориться можно попробовать, но не факт, что это получится. Если не получится, зафильтровав определенного клиента и подав всем остальным пример,

как это правильно сделать, может заставить этих разработчиков задуматься. Договориться с трекерами, чтобы фильтровали неугодных клиентов. Подать в

суд на разработчиков. Более сложный, но эффективный вариант. Все перечисленные методы оправданы. Заняться стоит.

 

Иван, мне кажется, что Вы немного однобоко мыслите.

Изменено 25 мая, 2010 пользователем hiller

[marikoda]

А никто не говорит про torrent'ы в целом. Говорят про uTP и uTorrent. Их фильтровать можно и нужно. Не обязательно по сигнатурам, есть и другие способы.

Договориться можно попробовать, но не факт, что это получится. Если не получится, зафильтровав определенного клиента и подав всем остальным пример,

как это правильно сделать, может заставить этих разработчиков задуматься. Договориться с трекерами, чтобы фильтровали неугодных клиентов. Подать в

суд на разработчиков. Более сложный, но эффективный вариант. Все перечисленные методы оправданы. Заняться стоит.

 

Иван, мне кажется, что Вы немного однобоко мыслите.

Получим в итоге arms race.

На форуме utorrent пробегала правильная идея насчет выключения uTP путём внесения определенной записи в ДНС, т.е. чтобы этот вопрос решался конкретным сетевым администратором.

UPD. поднял там опять эту идею.

Изменено 25 мая, 2010 пользователем marikoda

[SokolovS]

Получим в итоге arms race.

На форуме utorrent пробегала правильная идея насчет выключения uTP путём внесения определенной записи в ДНС, т.е. чтобы этот вопрос решался конкретным сетевым администратором.

UPD. поднял там опять эту идею.

Здравая мысль, поддерживаю. Я тоже задал там вопросик, на что получил странный ответ. Есть ли у нас на посмотреть стату пров с ~20к абонентов 10 Мбит/c в среднем на абонента и 20Г каналом. Я думаю только в Мск.

[_INF_]

Компания-разработчик технологии BitTorrent открыла транспортный протокол uTP, изначально использовавшегося только в официальном bittorrent-клиенте uTorrent. Готовый к использованию исходный код протокола, написанный на языке C++, доступен в виде библиотеки libutp на сайте GitHub под лицензией MIT.

[marikoda]

Подскажите, как в Linux и FreeBSD сделать шейперы не по килобитам в секунду, а по пакетам в секунду?

[f13]

http://pda.opennet.ru/opennews/art.shtml?num=26725

[vitalyb]

Товарищи просто жгут

 

actually we tend to get very favorable feedback from most ISPs who understand both the intent and the implementation of uTP.

 

Its true that many ISPs face challenges in meeting the incredible surging demand for their services, but its also true that many ISPs interpret demand growth as a positive thing to be embraced and served, rather than an evil that should somehow be fought. But even in this light, uTP behaves in a far more manageable way than TCP-based BitTorrent, and although it may lead to some adjustments in network management practices, the end-result should be a better network experience for consumers delivered at lower cost to ISPs.

Так что вы все ничего не понимаете, да прибудут с нами пилинг и откатинг 8)

 

зы. demand growth - это, безусловно, хорошо, но не такими же методами...

[hiller]

А никто не говорит про torrent'ы в целом. Говорят про uTP и uTorrent. Их фильтровать можно и нужно. Не обязательно по сигнатурам, есть и другие способы.

Договориться можно попробовать, но не факт, что это получится. Если не получится, зафильтровав определенного клиента и подав всем остальным пример,

как это правильно сделать, может заставить этих разработчиков задуматься. Договориться с трекерами, чтобы фильтровали неугодных клиентов. Подать в

суд на разработчиков. Более сложный, но эффективный вариант. Все перечисленные методы оправданы. Заняться стоит.

 

Иван, мне кажется, что Вы немного однобоко мыслите.

Получим в итоге arms race.

На форуме utorrent пробегала правильная идея насчет выключения uTP путём внесения определенной записи в ДНС, т.е. чтобы этот вопрос решался конкретным сетевым администратором.

UPD. поднял там опять эту идею.

Отличная мысль!

 

Компания-разработчик технологии BitTorrent открыла транспортный протокол uTP, изначально использовавшегося только в официальном bittorrent-клиенте uTorrent. Готовый к использованию исходный код протокола, написанный на языке C++, доступен в виде библиотеки libutp на сайте GitHub под лицензией MIT.

Жестоко. Сейчас эта дрянь появится во всех клиентах :(

[woddy]

перед смертью апгрейдом не надышишься :)

[NiTr0]

перед смертью апгрейдом не надышишься :)

Апгрейд-апгрейдом, но порой проблема вылазит также и у топ-провайдера - который ну никак за неделю не сможет достать оборудование, чтобы переварить выросший на % 50 pps.. Нашего топ-провайдера (или кого-то за его пределами) пучило где-то до апреля...

Да и если верить этому отчету, апгрейд далеко не всегда решит проблему.

[woddy]

который ну никак за неделю не сможет достать оборудование, чтобы переварить выросший на % 50 pps..

на дату создания топа посмотрите :)

Да и если верить этому отчету, апгрейд далеко не всегда решит проблему.

этот отчет говорит о неумении настраивать оборудование.

[disappointed]

http://github.com/bittorrent/libutp/blob/master/utp.cpp

Интересно.

Научимся слать ST_RESET с верным Sequence number? :))))

Изменено 26 мая, 2010 пользователем disappointed

[Ivan_83]

На форуме utorrent пробегала правильная идея насчет выключения uTP путём внесения определенной записи в ДНС, т.е. чтобы этот вопрос решался конкретным сетевым администратором.

UPD. поднял там опять эту идею.

Это не сработает с теми, кто прописывает ДНС не от прова.

С другой стороны 99.5% это затронет.

 

 

[Ivan_83]

http://github.com/bittorrent/libutp/blob/master/utp.cpp

Интересно.

Научимся слать ST_RESET с верным Sequence number? :))))

Это вам не DNS какой нибудь :)

Хакеры когда DNS портили (в самом начале), просто слали id:0-65535 кучу пакетов на 53 порт (он раньше и для отправки запросов использовался тоже) и не парились %)

 

uint16_big connid;
...
// Sequence number
uint16_big seq_nr;
// Acknowledgment number
uint16_big ack_nr;

в другой версии формата коннид 32 бита.

 

см UTPSocket::send_rst

На входе, по идее ещё и IP можно контролировать, который должен быть сопоставлен с connid.

 

 

Но пока:

if (flags == ST_RESET && (conn->conn_id_send == id || conn->conn_id_recv == id))

можно попробовать тупо слать PacketFormatV1 с connid 0 до 65535 и type= ST_RESET; на адрес/порт жертвы.

по идее это оторвёт все коннекты на uTP, только адрес/порт узнать сначало нужно.

 

Можно написать в фаере заворот (зеркалирование) всего UDP на отдельную машину на один порт, которая будет проверять пакет uTP или нет, если да то слать пачку/несколько ресетов юзеру, можно даже заспуфить IP отправителя (если работать на машине-фаере его можно получить из pf/ipfw). Если даже будет ложный детек-маловеротно что ресет пакеты uTP другие проги воспримут/пострадают.

 

 

PS: просмотр чужого кода почти всегда отбивает желание этим пользоваться :(

 

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

 

PPPS: UDP для торрента хорошо, реализация та ещё - бррр - уже костыли торчат v, v1 и по мелочам.

 

 

 

А как во фре отзеркалить весь юдп на определённый хост:порт?

(желательно средствами пф)

Изменено 26 мая, 2010 пользователем Ivan_83

[photon]

PPPS: UDP для торрента хорошо, реализация та ещё - бррр - уже костыли торчат v, v1 и по мелочам.

Умные люди все эти проблемы с перегрузками и избыточным пакетрейтом уже проходили в 80-х и начале 90-х, когда обкатывался TCP. Когда разрабы uTorrent просят что-то там "доказать" по поводу проблем uTP, надо сразу и без разговоров отсылать их к работам Van Jacobson по алгоритмам предотвращения перегрузок. Чтобы UDP-based протокол стал юзабелен, неизбежно придется дописать к нему некоторые возможности, которые есть в TCP, прежде всего congestion control и flow control. Иначе это будет не транспортный протокол, а одно горе.

Изменено 26 мая, 2010 пользователем photon

[Abram]

по идее это оторвёт все коннекты на uTP, только адрес/порт узнать сначало нужно.

USE retracker;
SELECT ip, port
FROM  `tracker` 
GROUP BY ip

:]

Изменено 27 мая, 2010 пользователем Abram

[halver]

Да и если верить этому отчету, апгрейд далеко не всегда решит проблему.

этот отчет говорит о неумении настраивать оборудование.

 

Поделитесь, в чем же именно неумение проявляется?

[NiTr0]

на дату создания топа посмотрите :)

Дата - датой, но где гарантия, что очередной релиз uTP опять не пойдет "вразнос"?

[woddy]

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

в любом случае эти железки за пол года отобьются.

[NiTr0]

Апгрейд бордюра уже сделан давно, железка загружена % на 40 в час пик.

В феврале до активного внедрения uTP была загрузка где-то 75-80%, + еще было где развернуться по части оптимизации фильтров/шейперов (что и было сделано); и этот запас сожрался данным чудо-протоколом за 1.5 недели. И на сколько бы выросла нагрузка, если бы я не порезал эту гадость после апгрейда - я судить не берусь.

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

[SokolovS]

Как писали выше, как минимум нужно congestion control и flow control.

[Ivan_83]

Я тут поковырялся немного, из любопытства/спорт интереса...

 

1. Можно в ipfw через tee заворачивать копию UDP траффика на диверт сокет, где будет сидеть прога, которая шлёт uTP ST_RESET пакеты обоим хостам.

2. Можно тоже самое, но ничего не слать, просто не пересылать пакеты uTP, остальное пересылать обратно.

ИМХО это менее надёжно для не uTP трафика и ресурсов больше потребует.

 

Моё тестовое приложение пока только пересылать весь UDP траффик научено на адрес:порт.

На выходных может и до детекта uTP пакетов доберусь с генерацией uTP ST_RESET обоим хостам.

[hiller]

Я тут поковырялся немного, из любопытства/спорт интереса...

 

1. Можно в ipfw через tee заворачивать копию UDP траффика на диверт сокет, где будет сидеть прога, которая шлёт uTP ST_RESET пакеты обоим хостам.

2. Можно тоже самое, но ничего не слать, просто не пересылать пакеты uTP, остальное пересылать обратно.

ИМХО это менее надёжно для не uTP трафика и ресурсов больше потребует.

 

Моё тестовое приложение пока только пересылать весь UDP траффик научено на адрес:порт.

На выходных может и до детекта uTP пакетов доберусь с генерацией uTP ST_RESET обоим хостам.

Иван, наконец-то Вы стали применять свои знания во-благо человечества! Радует!

[gritzko]

Добрый день!

 

Извините за реанимацию темы. Тут Арвид Норберг (BitTorrent Inc) ищет добровольцев, чтобы потраблшутить этот косяк с мелкими пакетами.

Разыскивается: ISP, у которого оборудование просело от uTP, готовый немного поэкспериментировать на своих пользователях.

Предлагаемый сценарий, как я понял - накатывать автоапдейтом тестовые версии на конкретные сетки и смотреть, вылечилось или нет.

Добровольцев прошу в личку.