Torrent: альтернативный способ детектирования

[nuclight]

Со времени событий вокруг uTP прошло более 4 месяцев, разработчики uTorrent на месте не стояли, в теме на nag.ru тоже накатали уже более сорока страниц. Придумал и я принципиально новый способ ловить соединения торрентов, но обо всём по порядку.

Comments

[dadv]

Спасибо, хорошая статья.

[redrat]

Хоть и не актуально пока, но буду иметь в виду.

[xirss]

ИМХО - более правильно было бы опять же держать таблицу линков в самом скрипте, и при добавлении/удалении (по таймауту) из нее элемента - собссно уже дергать ipfw. Но это уже детали реализации...

[nuclight]

Да, я об этом упоминал в итогах. Но такая версия не влезла бы в ограничения на объем поста в ЖЖ.

[l2tp]

Мне очень интересно, кто меня поминает

OMFG

[l2tp]

Я не хотела широкой известности, nuclight, а она подползает

[rc_conf]

Решил сегодня потестировать на 0day.kiev.ua.
Интересная картина:
Первый ответ почти всегда получается нормальный
d8:intervali1256e12:min intervali628e5:peers900

Но иногда проскакивает
d8:completei16e10:incompletei8e10:downloadedi40e8:intervali300e5:peers132
Соответственно матч не проходит

[nuclight]

Занятно, в официальной спецификации этого нет, нашлось на http://wiki.theory.org/BitTorrentSpecification - там еще некоторые ключи могут попадаться. Ну что ж, значит, надо модифицировать регэксп :)

[rc_conf]

У себя уже пофиксил. Интересно, сколько еще новых сюрпризов принесет данный протокол :)
А вообще, скриптик работает на ура - за вчера 25К уникальных хостов порезал.

[nuclight]

Ну, у них есть, например, драфт протокола трекера, работающего по UDP. Правда, номер порта я из него не понял.

> за вчера 25К уникальных хостов порезал.

А эффект по полосе есть? В смысле, что-нибудь явно лишнее просачивается, как признак неучтенного скриптом?