Сегодня состоялся релиз TorrentPier Cattle.
Думаю многие знакомы с порталами Rutracker, NNMClub и т.п., которые оперируют на данном движке, хоть они и давно не обновлялись.
Спустя несколько месяцев разработки, рады вам сообщить о переходе на PHP 8.1, поддержке BitTorrent v2, исправленных уязвимостях, и других новых функциях, которые последуют в этой статье.
Начнём с BitTorrent v2 (статья на русском). Это следующая версия протокола BitTorrent, которая имеет ряд улучшений:
Так как хеш каждого файла вшит в торрент файл, клиенты не тратят трафик на скачивание дубликатов.
Хеш дерево Меркля и вложенность структуры папок, позволяет сократить размер торрент файлов.
Благодаря хеш дереву, для проверки на битость части файла, необходимо скачать лишь 16Кб листа, раньше приходилось скачивать вcю часть.
За счёт выравнивания частей (BEP-47), данные каждого файла начинаются на новой части, таким образом при скачивании отдельных файлов, пользователям не приходится скачивать и хранить часть других файлов, это файлы ."parts", ".dat" и т.д.
Можно скачивать раздачу без дубликатов файлов (станет возможным на следующей версии торрент-библиотеки libtorrent).
В движке реализована отдельная страница для показа информации о содержимом v2 поддерживаемых торрент файлов, таких как клиент, дата создания, имена файлов, их хеши. Это позволяет поисковикам кешировать эту информацию, как в DHT индексаторах, что поможет вашим пользователям находить отдельные файлы по их хешу, имени файла, направляясь на ваш ресурс.
Из улучшений анонсера:
Поддержка IPv6 (по стандарту BEP 7), форум его тоже теперь поддерживает.
Переработанная система кеша (анонсер+скрейп), для значительного снижения нагрузки на трекер.
Multi-scrape (BEP 48), позволяет торрент-клиентам узнавать количество раздающих/скачивающих без обращения к анонсеру. Скрейп не затратен как анонсер, так как не записывает в базу данные и даёт возможность торрент-клиентам показывать реальную статистику, помогать в раздаче, если соотношение раздающих/скачивающих требует этого.
Показ полных скачиваний (сколько раз этот торрент скачали, со всеми файлами).
Показ торрент-клиентов пользователей на статистиках раздач.
Показ последнего раздающего бывшего на раздаче.
Показ числа торрент-клиентов в статистике трекера администраторской панели, также возможность гибкой корелляции версий этих клиентов.
В анонсере список пиров сортируется с приоритетом на скачивающих, что позволяет улучшить связность роя.
Из других улучшений (некоторые из этих функций были модификациями, которые переработаны и включены в движок по умолчанию):
Закрыты две критические уязвимости.
Инвайт коды по событиям.
Кнопка "Спасибо".
Поддержка .webp изображений.
Поддержка IDN доменов.
Бан торрент-клиентов или их версий.
Увеличена длина passkey (предыдущие будут работать).
Раздачи можно просматривать и скачивать напрямую с Atom (настраиваемо в config.php).
Инфо-хеши замороженных раздач теперь не показываются, их нельзя скачать, даже через dl.php.
Показ информации о бан-статусе пользователя в теме и профиле.
Флаги стран в профиле.
-
И многое другое.
Установка движка теперь очень простая, он поддерживает composer и нетребователен к ресурсам, любой желающий может создать свой публичный/приватный торрент-трекер.
TorrentPier — первый торрент-движок, который поддерживает BitTorrent v2 из коробки.
Мы не пошли по общему методу "и так работает".
Я также надеюсь, что эти несколько месяцев баг фиксов и улучшений кода будут полезны администраторам ресурсов.
Комментарии (64)
NeoCode
31.12.2023 19:41+11Отличная новость, надеюсь рутрекер и прочие перейдут на новый протокол.
Из разряда мыслей на тему: хорошо бы еще в торрент-файлы вставляли человекоориентированную метаинформацию о самой раздаче (все то что на рутрекере и прочих трекерах требуется так старательно заполнять при создании раздачи). Название, автор, год издания, жанр и прочее. Это же словарь "ключ-значение", а формат Bencode как раз предназначен для такой информации (но нужен общепринятый список ключей). Был бы неплохой задел на децентрализованную сеть будущего.
ohno1052
31.12.2023 19:41+3В чём смысл бана определённых торрент-клиентов? И как это в общих чертах реализовано, ведь наверняка подменить название клиента для трекера довольно просто.
dartraiden
31.12.2023 19:41+8Некоторые трекеры включают в URL анонсера пасскей пользователя.
В свою очередь в некоторых клиентах по умолчанию включён обмен этими анонсерами между пользователями. Таким образом, другие пользователи могут получить ваш пасскей и дальше, например, качать торренты, тратя ваш рейтинг на трекере, а не свой.
Именно поэтому на рутрекере запрещено использовать некоторые клиенты, например, Deluge, разработчики которого отказались по умолчанию отключать обмен анонсерами, аргументировав это тем, что "если какие-то русские трекеры делают такую глупость, то это не наши проблемы".
Вообще, для этого в торрент-файле есть специальный флаг "приватный торрент", видя который, клиенты отключают всякий обмен данными о торренте с другими пользователями. Но, когда проблему осознали, было уже поздно: годами торренты создавались без этого флажка, а изменить торрент задним числом не вариант - тогда у него поменяется хэш и все, кто его раздавал, отвалятся (соответственно, сидеров на старых раздачах станет ещё меньше, а их и так не хватает).
наверняка подменить название клиента для трекера довольно просто
Бан клиента нужен, чтобы пользователи, которые не знают о том, что с настройками по умолчанию, их пасскей утекает, не протекали, а не для того, чтобы любой ценой заблокировать использование конкретного клиента. Это просто заборчик для защиты неопытных пользователей.
LF69ssop
31.12.2023 19:41+1Именно поэтому на рутрекере запрещено использовать некоторые клиенты, например, Deluge,
Интересно, как же это я пользуюсь тогда.
Или запрещено но можно?
dartraiden
31.12.2023 19:41+2Изначальный ответ разработчиков - "Если из-за этого на «некоторых крупных российских трекерах» происходят утечки данных, то это результат того, что они не понимают разницу между общедоступным и частным торрент-файлом" (собственно, о чём я и говорил - изначально неудачное решение помещать в торрент конфиденциальные данные, но не помечать его приватным)
Изменение в версии 1.3.12, отключающее обмен анонсерами. Версии, древнее, чем эта, скорее всего, до сих пор забанены.
vdudouyt
31.12.2023 19:41Но, когда проблему осознали, было уже поздно: годами торренты создавались без этого флажка, а изменить торрент задним числом не вариант - тогда у него поменяется хэш и все, кто его раздавал, отвалятся (соответственно, сидеров на старых раздачах станет ещё меньше, а их и так не хватает).
Разве? Насколько я помню, info_hash торрента считается из Bencode-представления ассоциативного массива info. Соответственно все, что в него не входит - включая флаг private и строку announce (URL до трекера) при своем изменении info_hash никак не затрагивает. В противном случае смена вшитого в announce URL пасскея пользователя бы тоже приводила к смене info_hash и невозможности связаться с остальными пирами - однако, как мы все знаем, этого не происходит.
kovalensky Автор
31.12.2023 19:41+1Ключ private хранится в info секции, BEP 27:
When generating a metainfo file, users denote a torrent as private by including the key-value pair "private=1" in the "info" dict of the torrent's metainfo file.
kush07
31.12.2023 19:41а на ннмклаб как с этим обстоят дела ? тоже делятся по умолчанию ?
dartraiden
31.12.2023 19:41+2Откройте .torrent текстовым редактором и поищите
private. Но на nnmclub в урле анонсера нет пасскея, так что обмен анонсерами ничем не вредит.
Hannnn
31.12.2023 19:41И как это в общих чертах реализовано
При обращении из торрент клиента к анонсеру трекера, трекер тупо проверяет строчку клиента из http запроса и если не валидный, то реджектят запрос. В свое время был активным девелопером модов под tbdev... вот тут можно чекнуть для tbdev:
https://github.com/yunasc/tbdev/blob/7f757ec5c65b258db54ccaecb92c98d073cc4931/announce.php#L88C1-L88C1ведь наверняка подменить название клиента для трекера довольно просто.
По факту ничего не мешает. Люди пересобирают торрент клиенты без логики учета скаченного/отданого, заменяют имя агента итд. Проверка от лукавого.dartraiden
31.12.2023 19:41+2Люди пересобирают торрент клиенты без логики учета скаченного/отданого
Это работает только на мусорных трекерах, на серьёзных таких ушлых пользователей вычисляют и изгоняют. В ту же копилку "патч DHT", большинство пользователей которого вообще не представляют, как он работает и почему он либо бесполезен, либо вреден.
belomaxorka
31.12.2023 19:41+1Торрент клиент отправляет аннонсеру peer_id который содержит название клиента и его версию. В движке лишь проверяется с чего начинается строка и на основе этого определяется клиент. Вот пример peer_id для qBitTorrent 3.1.3 -
-qB3130-kwsSnUYwydys
Kasyan666
31.12.2023 19:41Скажите пожалуйста, какие torrent-клиенты поддерживают ваши фичи "из коробки"?
NeoCode
31.12.2023 19:41+3qBittorrent поддерживает v2, но нужно скачивать не то что предлагается по умолчанию, а то в названии которого есть "_lt20_" . Вроде есть еще несколько клиентов.
Kasyan666
31.12.2023 19:41+1А есть ли способ конвертации сотен старых torrent-файлов в новый формат? Ручная замена займёт... месяцы.
dartraiden
31.12.2023 19:41Емнип, при изменении торрент-файла, у него поменяется хэш, что фактически его убьёт, т.к. трекер будет считать, что это совсем другой торрент и отдавать ошибку "торрент не зарегистрирован на трекере".
Kasyan666
31.12.2023 19:41+1Т.е., другими словами, нужно перекачать 1000 файлов. А есть ли у вас какое-либо API, которое позволило бы по ссылке на веб-страницу раздачи (из torrent-файла) получить файл v2?
kovalensky Автор
31.12.2023 19:41Встречал функцию конвертации торрентов в BiglyBT, но сам не пользовался, не знаю подойдёт ли для вашего случая.
VADemon
31.12.2023 19:41Автоматическая конвертация не имеет смысла, так как никто не удосужился стандартизовать алгоритм конвертации. Так бы хоть гарантированно v2 торрент происходил от v1 и был одинаков у всех, а так он не только отличаться будет, но может быть разным с после каждой конвертации.
Shado_vi
31.12.2023 19:41+1https://www.tixati.com/news/#:~:text=New BitTorrent v2 Support
22 год.
более сложный вопрос, какие трекеры поддерживают v2?
в частности есть поддержка комбинирования версий 1+2 https://www.tixati.com/news/#:~:text=Combined version 1%2B2 torrents are also fully supported.
radioxoma
31.12.2023 19:41Все, которые используют libtorrent-rasterbar 2. Клиенты можно посмотреть в секции Required by. На данный момент это как минимум btfs, deluge, qbittorrent. Напомню, что libtorrent-rasterbar поддерживает последовательное скачивание для просмотра фильмов.
sim2q
31.12.2023 19:41+13Так как хеш каждого файла вшит в торрент файл, клиенты не тратят трафик на скачивание дубликатов.
Если можно было бы брать файлы с таким же hash, но из других раздач найденных по DHT - это была бы киллер-фича!
Можно было смержить тыщи раздач которые дополняются время от времени, музыкальные сборники итдNeoCode
31.12.2023 19:41+6Совершенно верно. Можно было бы просто указать торрент-клиенту некий путь к "файлопомойке" и сказать: вот тебе место где хранятся всякие скачанные отовсюду файлы, проиндексируй и раздавай оттуда все что запросят по хешам". Преимущество - можно было бы не заботиться о постоянном размещении раздачи после скачивания, свободно перемещать ее по файловой системе, сортировать раздачи по смыслу и т.п., и торрент-клиент все равно бы их автоматически находил и раздавал.
Следующий шаг - это просто децентрализованный доступ к файловой системе, как (наверное) в RetroShare.
ritorichesky_echpochmak
31.12.2023 19:41И микснуть это с ipfs)
NeoCode
31.12.2023 19:41+2Есть минимум несколько десятков децентрализованных файлообменных сетей. Само собой напрашивается мысль их все микснуть, причем на разных уровнях(к примеру обмен не только файлами но и пирами). Дальше возникает мысль о декомпозиции децентрализованных протоколов таким образом, чтобы любая сеть представлялась чем-то вроде множества "компонентов" разного уровня (сетевые, криптографические, прикладные...) со своими правилами и настройками. Между компонентами должны быть некие универсальные интерфейсы взаимодействия. Т.е. это серьезная работа по стандартизации самих концепций децентрализованных сетей, с тем чтобы любую сеть можно было разложить на простые унифицированные составляющие.
ganzmavag
31.12.2023 19:41+3Вроде DC++ делал похожее. Ты открываешь у пользователя расшаренную папку, начинаешь качать оттуда какой-нибудь фильм - и клиент подтягивает его части не только у этого пользователя, а у кого-нибудь ещё в локалке.
MaxSoniX
31.12.2023 19:41Звучит как переизобретение DC++
NeoCode
31.12.2023 19:41+1Я не сомневаюсь что все уже давно придумано:) И вряд ли именно в торрентах будут такое делать. А вот если начнут появляться универсальные клиенты, объединяющие несколько (в идеале как можно больше) p2p сетей, то torrent v2 с его хешами к каждому файлу очень неплохо впишется в эту концепцию, гораздо лучше чем v1.
Metotron0
31.12.2023 19:41Так работает eMule. Я его иногда запускаю, там бывает активность даже на фильмах с русской озвучкой и на книгах на русском.
314159abc
31.12.2023 19:41А не подскажете какой-нибудь инструмент для поиска по dht, чтобы как-нибудь не очень сложно на windows 10 запускался?
kovalensky Автор
31.12.2023 19:41Поиск по GitHub выдаст много результатов на инструменты DHT индексатора.
BitMagnet к примеру.
kovalensky Автор
31.12.2023 19:41Такая функция есть в BiglyBT, недавно добавили поддержку btmr хешей для точного поиска.
stalinets
31.12.2023 19:41+1Есть одна задача, которая периодически возникает: передать от одного человека другому большой файл или папку. Использовать облака, файлообменники - это всё не то. Торрент как раз в теории отлично подходит. Но на практике вечно начинаются танцы с бубнами: клиенты не видят друг друга, передача не хочет стартовать, мешают NAT и фиг знает что ещё. Начинается прописывание айпи, игры с трекерами, с настройками клиентов, прописывание портов в роутерах и прочее, и в итоге не факт что будет толк. Хотелось бы, чтоб новые версии протокола и клиентов решали эту проблему, чтобы "частная" передача файла/папки по торренту делалась просто и стартовала надёжно и быстро. И желательно секьюрно.
blind_oracle
31.12.2023 19:41+3Syncthing делает это всё и даже больше
NeoCode
31.12.2023 19:41У меня обе версии (x32 и x64) упали сразу при запуске :)
blind_oracle
31.12.2023 19:41+1Очевидно что у вас в королевстве что-то не так. У меня работает на Windows (Synctrayzor), MacOS, Linux и Android одновременно в данный момент.
kovalensky Автор
31.12.2023 19:41И ещё BitTorrent Sync, но он не opensource.
Проблему с NAT решут в будущем Websocket трекеры, где обновления о пирах приходят мгновенно и используется stun.
Они планируются в библиотеке libtorrent вместе с WebTorrent, а значит будут в qBittorrent.
MaxSoniX
31.12.2023 19:41Если у обоих пиров IPv6, то данная проблема на личном опыте быстро решалась открытием порта торрент-клиенту. Другая проблема, что не каждый провайдер/оператор выдаёт IPv6 префикс абоненту, но если есть то чего не воспользоваться)
P.S. одному товарищу помогал настраивать IPv6-туннель для связанности.
Javian
31.12.2023 19:41+1поможет вашим пользователям находить отдельные файлы по их хешу, имени файла, направляясь на ваш ресурс.
Копирайтеру в помощь :)
kovalensky Автор
31.12.2023 19:41Им в помощь DHT индексаторы)
Да и если администратор установил настройку приватности, то эта функция автоматом отключается.
MaxSoniX
31.12.2023 19:41+1Вот это новогодний подарок под ёлочкой)
P.S. Благодарю за добротную статью и освещение Bittorrent v2 & IPv6 в p2p лично автора)
mikegordan
"Благодаря хеш дереву, для проверки на битость части файла, необходимо скачать лишь 16Кб листа, раньше приходилось скачивать вcю часть."
Не очень понял этот механизм, допустим у меня фильм 40гб.
Я открыл его в хэщ редакторе и в разных его частях удалили байты.
Какой алгоритм будет по шагам для того чтобы ваш "торент v2" его восстановил?
acc0unt
Торрент делит этот 40гб файл на логические блоки по 16кб. При верификации файла для каждого блока считается и сверяется хэш. Если хэш блока не совпал с искомым, блок перекачивается от других пиров.
Если байты были именно удалены, с уменьшением размера файла, то все последующие байты сдвинутся. Файл провалит валидацию начиная с первого удаления и далее до конца файла.
Если байты были повреждены - например, затёрты 00 или FF - то валидация провалится только для повреждённых блоков, и перекачаны будут только они.
mikegordan
16кб вроде в v1 так и было, ну тоесть из нового добавили сдвиг (в случаи удаления) который вносит еще более не ясности, чем сдвиг поможет в этом?
Тоесть дошло до места удаления, берутся следующие 16кб , они не равняются, качается новый сегмент, вставляется в это место, а всё что справа "сдвигается", потом опять берутся этоже 16кб , они опять не равны и всё по кругу.
Да это будет работать если я удалил чётко 16кб от границы до границы.
(красные полоски места удаления)
kovalensky Автор
Из статьи:
The leaves of the hash trees are always 16 kiB (the block size), regardless of the piece size. The concept of piece size still exists and is still used in the peer-wire protocol as it is today. e.g. in HAVE and REQUEST messages. However, instead of piece hashes actually being the hash of the content of the piece, it’s the root of the hash tree of the piece. i.e. a sub-tree of the full merkle tree.
Т.е. теперь мы имеем хеш листов всего дерева, каждый хеш листа основан на предыдущем, и меняется, если он битый. В подробностях я это объяснить не смогу, нужен человек с тщательным знанием хеш деревьев.
Если вы меняете торрент файл, то он не откроется, потому что количество хешей не будет четным. Если вы замените некоторые байты, то в случае v1 поменяется хеш раздачи (так как ключ pieces в разделе info), в случае v2 клиент не сможет скачать нужные данные с пиров и пожалуется, что "Рой пиров выслал неверные данные" в случае с qBittorrent.
lealxe
А, т.е. под "нужно скачать только 16кб", чтобы найти ошибку, имелось в виду, что только 16кб самого битого блока? ОК, так не противоречит здравому смыслу.
kovalensky Автор
Из статьи "необходимо скачать лишь 16Кб листа"
ritorichesky_echpochmak
А что там в новых версиях торрента для хеширования? Просто вот эти 40Гб перечекать (в каждом из которых возмоооожно байтик повреждённый)... адище и с точки зрения нагрузки и на ФС и на проц. Может уже какие весёлые штуки типа blake3 завезли?
kovalensky Автор
Используется sha2, когда разрабатывали v2 не было blake. Поврежденный порядок байтов приходит когда:
А) Нестабильная связь, тогда ничего не скачается
Б) Вредоносный пир, который блокируется
ritorichesky_echpochmak
Какой-то прогресс в этом плане планируется?
Когда старый диск на качалке просто медленно умирает, пир будет забанен? Если хард поменяли и нужно чекнуть целостность и перекачать битые файлы, есть какая-то штатная механика?
kovalensky Автор
Как я знаю, пир банится на длительность сессии (она обычно начинается со стартом торрента, или самого клиента, зависит от кода).
Если удалённый пир восстановил данные и перехешировал данные, то скачка у локального пойдёт.
MountainGoat
Зачем? скорость хеширования любом алгоритмом на любом процессоре всё равно упрётся в скорость чтения с диска.
BugM
Не скажите. Торренты регулярно запускают на роутерах и подобном железе. Диски там обычные, а вот процессоры максимально энергоэффективные. Со скоростями хеширования бывает всякое.
ritorichesky_echpochmak
У меня на ноуте с NVMe blake3 более чем в 2 раза быстрее чем sha256, и кажется он не такой требовательный к прочим ресурсам, иначе б я не спрашивал. Но вы лучше сами гляньте
VADemon
Sha1 и Sha2 имеют аппаратное ускорение в современных процессорах. Надавите на библиотеки, чтобы ими воспользовались или взяли OpenSSL.