[Ivan_83]

У меня получилось по 1 варианту сделать. %)

 

В IPFW

add tee 9999 udp from any to any

 

Прога на 9999 диверт сокете ловит копии пакетов.

Если видит что пакет uTP версии 0 или 1 или очень сильно на него похож то генерит uTP ST_RESET и отправляет по тому же адресу/порту, по которому ушёл оригинальный пакет (ip и порты остаются оригинальными, ip сервера где программа никуда не пишется).

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

 

С косяков:

- инженерный образец: почти все настройки через пересборку, не всё оптимизировано;

- выдаёт "Operation not permitted" при попытке послать пакет у которого src/dst IP принадлежат ng0 (pppoe client / mpd5);

- выглядит так, как будто при двух потоках на kqueue работает медленее, чем с одним и ошибки чтения "Resource temporarily unavailable" на это намекают

- наверно не очень производительно в итоге, как и natd - но и нагрузка меньше - только udp, и можно заворачивать только с внутреннего интерфейса траффик пришедший извне - тогда только в свою сеть будут уходить ресеты.

 

С плюсов:

- работает %)

- память/проц не жрёт

- не uTP вреда не будет: даже при ложном срабатывании прилетит дополнительно левый пакет uTP ST_RESET

 

 

В моём uTorrent 2.0.2 настроенном чтобы были только uTP пиры - все пиры исчезают оч шустро.

Если отключить - опять приконекчиваются.

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

[sdy_moscow]

Добрый день!

 

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

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

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

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

Посоветуйте Арвиду взять пошире канал в инет (мегабит 20) и 3-5 SOHO роутеров разных производителей....

Когда у него всё будет работать - пусть к нам приходит.

 

З.Ы. Не люблю я этих... - "Кипятите? Мы уже к вам идем!"

[Ivan_83]

одного длинк DI604 и точки типа длинк AP2100 / AP700 хватит чтобы прочувствовать суть на 10 мегабит канале то %)

[gritzko]

одного длинк DI604 и точки типа длинк AP2100 / AP700 хватит чтобы прочувствовать суть на 10 мегабит канале то %)

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

[photon]

Посоветуйте Арвиду взять пошире канал в инет (мегабит 20) и 3-5 SOHO роутеров разных производителей....

Когда у него всё будет работать - пусть к нам приходит.

 

З.Ы. Не люблю я этих... - "Кипятите? Мы уже к вам идем!"

Так open source же. Большинство таких программеров считает, что бета-тестированием должны заниматься пользователи.

[gritzko]

Посоветуйте Арвиду взять пошире канал в инет (мегабит 20) и 3-5 SOHO роутеров разных производителей....

Когда у него всё будет работать - пусть к нам приходит.

З.Ы. Не люблю я этих... - "Кипятите? Мы уже к вам идем!"

Так open source же. Большинство таких программеров считает, что бета-тестированием должны заниматься пользователи.

µTorrent - не open source, а freeware.

 

[gritzko]

Вы не поверите, но разработчики uTP стремились именно снизить overhead за счет того, что часть функций TCP уже реализована в протоколе BitTorrent (вычисление контрольных сумм, повторная передача частей с плохой суммой). Но они столкнулись с проблемой congestion control, которую до этого люди много лет решали для TCP, что и привело к увеличению нагрузки на сеть. Я вообще удивляюсь, что они не пригласили для разработки uTP ни одного ученого, специализирующегося на congestion control. Это очередное проявление инженерной самонадеянности, что дескать можно обойтись без научного подхода, которая привела к созданию таких уродов, как архитектура х86 и язык PHP.

Что Вы пылите, Фотон? Шалунов - учёный.

 

Просто на этом рынке есть своя специфика: клиент-торрентовод не платит за контент/программу в принципе. Провайдеру - платит, BitTorrent Inc - не платит. Поэтому возможности BT Inc довольно ограничены.

 

Так что я надеюсь, что кто-то из толковых ребят, вернувшись с КРОС, таки посотрудничает с BT Inc, чтобы выловить/вылечить багу.

[photon]

Что Вы пылите, Фотон? Шалунов - учёный.

На форуме uTorrent появилось сообщение, что алгоритм управления перегрузками в uTP оказывается уже есть, и он называется LEDBAT. Тут же возник другой вопрос: на основе чего было принято решение добавить в протокол возможность уменьшения размера передаваемых сегментов, от которой как раз все и плюются? В TCP такого нет, сегменты всегда имеют максимальный размер, и даже без этого congestion control там работает нормально.

 

µTorrent - не open source, а freeware.

Мы говорим скорее не о клиенте, а о транспортном протоколе uTP. Он реализован в виде библиотеки libutp ( http://github.com/bittorrent/libutp ), следовательно это уже open source.

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

[XeonVs]

У меня получилось по 1 варианту сделать. %)

 

С косяков:

- инженерный образец: почти все настройки через пересборку, не всё оптимизировано;

- выдаёт "Operation not permitted" при попытке послать пакет у которого src/dst IP принадлежат ng0 (pppoe client / mpd5);

- выглядит так, как будто при двух потоках на kqueue работает медленее, чем с одним и ошибки чтения "Resource temporarily unavailable" на это намекают

- наверно не очень производительно в итоге, как и natd - но и нагрузка меньше - только udp, и можно заворачивать только с внутреннего интерфейса траффик пришедший извне - тогда только в свою сеть будут уходить ресеты.

 

С плюсов:

- работает %)

- память/проц не жрёт

- не uTP вреда не будет: даже при ложном срабатывании прилетит дополнительно левый пакет uTP ST_RESET

Сурсы то где? Могу попробовать потестировать на людях. В идеале думается надо собрать ng-ноду под это безобразие.

Изменено 29 мая, 2010 пользователем XeonVs

[photon]

Кстати, я тут поискал информацию по людям, разрабатывающим uTP. Оказывается, у них есть далеко идущие планы: заменить TCP на свой дивный новый протокол не только в торрент-клиентах, но и во всех интернетах: http://www.internet2.edu/presentations/jts...rt-Shalunov.pdf. Это называется "проект Internet2". Т.е. uTorrent для них -- это всего лишь первый шаг к завоеванию Вселенной. В принципе, я не против того, чтобы сделать некий новый транспортный протокол, который будет эффективнее TCP. Но вот широкомасштабные внедрения, вроде недавних обновлений uTorrent, надо проводить только тогда, когда он действительно станет лучше TCP.

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

[Ivan_83]

Исходники будут под BSD лицензией.

Нужно ещё красоту/порядок навести, те же printы отладочные убрать.

И определится с опциями командной строки.

 

До ng я не дорос :)

Хотя, по обзорам, там должно быть ещё проще.

 

 

Ну нафик их, uTP то не очень красиво реализован (про структуры данных и их разбор).

Когда закончат делать свой мегапротокол получится нечто среднее между IPv4 и IPv6 :)

 

И если такие умные, пусть тогда в заголовке IP пакета будет номер их протокола (tcp/udp/gre/.../toorrent %) )

или вообще нафик IP и сделать всё своё с нуля!

чего право мелочится :)

[hiller]

И если такие умные, пусть тогда в заголовке IP пакета будет номер их протокола (tcp/udp/gre/.../toorrent %) )

Точно. Чтобы не париться с анализом всего udp, а спокойно вырезать весь говнопротокол.

 

Раньше многие провайдеры выставляли повышенные приоритеты udp-трафику т.к. по нему бегал голос, сетевые игры и т.п.

После появления горепрограммеров, пришлось приоритеты делать на определенный тип трафика, а не на весь udp.

Как всегда, пострадали пользователи.

[marikoda]

Кстати, я тут поискал информацию по людям, разрабатывающим uTP. Оказывается, у них есть далеко идущие планы: заменить TCP на свой дивный новый протокол не только в торрент-клиентах, но и во всех интернетах: http://www.internet2.edu/presentations/jts...rt-Shalunov.pdf. Это называется "проект Internet2". Т.е. uTorrent для них -- это всего лишь первый шаг к завоеванию Вселенной. В принципе, я не против того, чтобы сделать некий новый транспортный протокол, который будет эффективнее TCP. Но вот широкомасштабные внедрения, вроде недавних обновлений uTorrent, надо проводить только тогда, когда он действительно станет лучше TCP.

А чем им SCTP не понравился?

[NiTr0]

А чем им SCTP не понравился?

Очевидно - тем, что, во-первых, это не их изобретение, а во-вторых - в их любимой венде не стоит по дефолту... Вот и решили пилить костыли поверх существующего протокола вместо того, чтобы с инсталлером торрента ставить нормальный протокол...

[photon]

А чем им SCTP не понравился?

Очевидно - тем, что, во-первых, это не их изобретение, а во-вторых - в их любимой венде не стоит по дефолту... Вот и решили пилить костыли поверх существующего протокола вместо того, чтобы с инсталлером торрента ставить нормальный протокол...

Это да, но проблема скорее в том, что у них при разработке протокола была идея-фикс: во что бы то ни стало, избавиться от проблем с задержками в DSL. Ради этого и были затеяны все эти мелкие пакеты и измерения задержек. Отсюда и результат: то, что хорошо для медленных линий, оказалось крайне плохо для быстрых. Про то, что в некоторых странах одной из основных технологией для подключения абонентских окончаний является Ethernet, они видимо понятия не имели.

 

Насчет специального значения поля в IP-заголовке для протокола uTP -- мысль хорошая, надо бы на форуме uTorrent предложить. Но только по-хитрому, не подавая вида, что это нужно для того, чтобы было проще фильтровать.

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

[vitalyb]

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

ИМХО на это они не пойдут, в частности, из-за того, что это поломает на годы весь NAT и протокол умрет не родившись.

 

Но идея хорошая :) Можно развить в некий "Decentralized Bulk Transfer Internet Protocol"

 

[hiller]

А с чего оно поломает нат? Натят как правило весь IP.

[Abram]

А с чего оно поломает нат? Натят как правило весь IP.

За натом может сидеть несколько человек. Потому нужно анализировать входящие извне пакеты и как-то решать, кому из них они принадлежат. К примеру, для PPTP и SIP в Linux существуют модули ядра, которые это делают.

[martin74]

а нельзя хелпер написать ?

[Ivan_83]

PF во фре до сих пор gre натить не умеет сам.

А уж сколько лет прошло и востребованность вполне однозначная.

[photon]

PF во фре до сих пор gre натить не умеет сам.

А уж сколько лет прошло и востребованность вполне однозначная.

PF разрабатывается в рамках проекта OpenBSD. Во фрю его только портируют. Я как-то интересовался позицией разработчиков PF по поводу PPTP и прочих несовместимых с NAT вещей. Они считают, что такой трафик нужно проксировать через юзерлэнд-демоны. О производительности там думают в последнюю очередь, главное "безопасность" и вылизанные исходники.

 

ИМХО на это они не пойдут, в частности, из-за того, что это поломает на годы весь NAT и протокол умрет не родившись.

Что там сломается? Там вроде нет ничего такого, привязанного к юзерскому IP, как в GRE или active FTP.

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

[ichbinkubik]

Согласно uTorrent transport protocol, и протокольной части по полю type, version, размерам udp-части и размерам uTP-пакета, который должен быть в случае ST_SYN, при помощи tcpdump можно набрать пакеты установления соединения по uTP, которые можно придержать с отправкой, но не убивать, что лучше, чем вслепую убивать неизвестно что, а если это окажется ещё и пакет данных, то пойдут мелкие пакеты о неподтверждённых пакетах.

 

tcpdump -nnptx -s 72 udp[8] = 0x41 and udp[24:2] = 1 and udp[26:2] = 0 and \( \(udp[9] = 0 and udp[4:2] = 8+20\) or \(udp[9] != 0 and udp[4:2] = 8+20+2+udp[29]\)\)

 

udp[8] - поля version = 1 и type = 4 (абзац по ST_SYN и абзац по version), внимание на "0x"

udp[24:2] - seq_nr = 1 (абзацы по ST_SYN и примеру инициализации соединения)

udp[26:2] - ack_nr = 0 (абзац по ack_nr, а из "last received" следует 0)

udp[9] - extension (0 - в отсутствии расширения связным списком, и другие значения - иначе)

udp[4:2] - размер udp-части всего пакета

udp[29] - поле len (абзац по extension) - размер расширения при его наличии

когда udp[9] = 0, udp[4:2] - размер udp-части всего пакета, должен совпадать с 8+20, 8 - заголовок udp, 20 - пакет uTP

когда udp[9] != 0 (пока видел 0, 1 и 2), udp[4:2] -размер udp-части всего пакета, должен совпадать с 8+20+2+udp[29], 2 - размер полей расширения extension и len

Я так понял, что средствами POSIX Regexp данную сигнатуру никак не описать. Если пропускать нулевые байты, не описанные в позикс, то под зажим попадет множество нужных пакетов, а контроль дллинны кадра - это вообще за рамками возможностей этого стандарта.

 

[hiller]

А с чего оно поломает нат? Натят как правило весь IP.

За натом может сидеть несколько человек. Потому нужно анализировать входящие извне пакеты и как-то решать, кому из них они принадлежат. К примеру, для PPTP и SIP в Linux существуют модули ядра, которые это делают.

Для торрентов хэлпер не нужен.

[vitalyb]

Что там сломается? Там вроде нет ничего такого, привязанного к юзерскому IP, как в GRE или active FTP.

Как уже отмечалось, как определить кому из пользователей переправлять пакет пришедший из Интернета? Номеров портов нет, есть только IP адреса, это отдельный протокол. Разумеется, предполагаю, что в пуле IP адресов меньше, чем торрент-пользователей.

 

Или делать хелпер, который и будет по некому connection_id ориентироваться.

 

И это, кстати, еще один отдельный вопрос - сделать NAT-friendly протокол. Тоже надо сначала подумать, а потом сделать, а не наоборот :)

 

[sdy_moscow]

Установка жесткого признака протокола сильно бы помогла...

В первую очередь клиентам, т.к. операторы смогли бы разумно сбалансировать полосы и корректно дать приоритеты трафику.

Если операторы захотят порезать торент - порежут. Только от такого опреаторы клиенты убегут очень быстро. А офисному "плангтону" торент и так и так надо запрещать :-).

Выделение же Р2Р трафика в отдельную категорию несомненно значительно улучшило бы общие показатели качества услуг.

Причем протокол с маркированным Р2Р не обязательно должен быть единственным.

Скажем он может быть "по умолчанию". Все остальные - вторыми и третьими.

Изменено 31 мая, 2010 пользователем sdy_moscow