Комментарии 68
"Благодаря хеш дереву, для проверки на битость части файла, необходимо скачать лишь 16Кб листа, раньше приходилось скачивать вcю часть."
Не очень понял этот механизм, допустим у меня фильм 40гб.
Я открыл его в хэщ редакторе и в разных его частях удалили байты.
Какой алгоритм будет по шагам для того чтобы ваш "торент v2" его восстановил?
Торрент делит этот 40гб файл на логические блоки по 16кб. При верификации файла для каждого блока считается и сверяется хэш. Если хэш блока не совпал с искомым, блок перекачивается от других пиров.
Если байты были именно удалены, с уменьшением размера файла, то все последующие байты сдвинутся. Файл провалит валидацию начиная с первого удаления и далее до конца файла.
Если байты были повреждены - например, затёрты 00 или FF - то валидация провалится только для повреждённых блоков, и перекачаны будут только они.
16кб вроде в v1 так и было, ну тоесть из нового добавили сдвиг (в случаи удаления) который вносит еще более не ясности, чем сдвиг поможет в этом?
Тоесть дошло до места удаления, берутся следующие 16кб , они не равняются, качается новый сегмент, вставляется в это место, а всё что справа "сдвигается", потом опять берутся этоже 16кб , они опять не равны и всё по кругу.
Да это будет работать если я удалил чётко 16кб от границы до границы.
(красные полоски места удаления)
Из статьи:
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.
А, т.е. под "нужно скачать только 16кб", чтобы найти ошибку, имелось в виду, что только 16кб самого битого блока? ОК, так не противоречит здравому смыслу.
А что там в новых версиях торрента для хеширования? Просто вот эти 40Гб перечекать (в каждом из которых возмоооожно байтик повреждённый)... адище и с точки зрения нагрузки и на ФС и на проц. Может уже какие весёлые штуки типа blake3 завезли?
Используется sha2, когда разрабатывали v2 не было blake. Поврежденный порядок байтов приходит когда:
А) Нестабильная связь, тогда ничего не скачается
Б) Вредоносный пир, который блокируется
Какой-то прогресс в этом плане планируется?
Когда старый диск на качалке просто медленно умирает, пир будет забанен? Если хард поменяли и нужно чекнуть целостность и перекачать битые файлы, есть какая-то штатная механика?
Как я знаю, пир банится на длительность сессии (она обычно начинается со стартом торрента, или самого клиента, зависит от кода).
Если удалённый пир восстановил данные и перехешировал данные, то скачка у локального пойдёт.
Зачем? скорость хеширования любом алгоритмом на любом процессоре всё равно упрётся в скорость чтения с диска.
Не скажите. Торренты регулярно запускают на роутерах и подобном железе. Диски там обычные, а вот процессоры максимально энергоэффективные. Со скоростями хеширования бывает всякое.
У меня на ноуте с NVMe blake3 более чем в 2 раза быстрее чем sha256, и кажется он не такой требовательный к прочим ресурсам, иначе б я не спрашивал. Но вы лучше сами гляньте
Sha1 и Sha2 имеют аппаратное ускорение в современных процессорах. Надавите на библиотеки, чтобы ими воспользовались или взяли OpenSSL.
Отличная новость, надеюсь рутрекер и прочие перейдут на новый протокол.
Из разряда мыслей на тему: хорошо бы еще в торрент-файлы вставляли человекоориентированную метаинформацию о самой раздаче (все то что на рутрекере и прочих трекерах требуется так старательно заполнять при создании раздачи). Название, автор, год издания, жанр и прочее. Это же словарь "ключ-значение", а формат Bencode как раз предназначен для такой информации (но нужен общепринятый список ключей). Был бы неплохой задел на децентрализованную сеть будущего.
Они там очень переживают за сидов которые держат на древних трансмишинах тысячи торрентов. И потому крайне не хотят переходить.
Можете ознакомиться рутрекер, на nnm +/- такая же петрушка, но хотя бы гибридные не запрещают (но меняют если находятся пользователи с жалобами). И там и там пеняют на "вот покажите крупные где пользуются".
В чём смысл бана определённых торрент-клиентов? И как это в общих чертах реализовано, ведь наверняка подменить название клиента для трекера довольно просто.
Некоторые трекеры включают в URL анонсера пасскей пользователя.
В свою очередь в некоторых клиентах по умолчанию включён обмен этими анонсерами между пользователями. Таким образом, другие пользователи могут получить ваш пасскей и дальше, например, качать торренты, тратя ваш рейтинг на трекере, а не свой.
Именно поэтому на рутрекере запрещено использовать некоторые клиенты, например, Deluge, разработчики которого отказались по умолчанию отключать обмен анонсерами, аргументировав это тем, что "если какие-то русские трекеры делают такую глупость, то это не наши проблемы".
Вообще, для этого в торрент-файле есть специальный флаг "приватный торрент", видя который, клиенты отключают всякий обмен данными о торренте с другими пользователями. Но, когда проблему осознали, было уже поздно: годами торренты создавались без этого флажка, а изменить торрент задним числом не вариант - тогда у него поменяется хэш и все, кто его раздавал, отвалятся (соответственно, сидеров на старых раздачах станет ещё меньше, а их и так не хватает).
наверняка подменить название клиента для трекера довольно просто
Бан клиента нужен, чтобы пользователи, которые не знают о том, что с настройками по умолчанию, их пасскей утекает, не протекали, а не для того, чтобы любой ценой заблокировать использование конкретного клиента. Это просто заборчик для защиты неопытных пользователей.
Именно поэтому на рутрекере запрещено использовать некоторые клиенты, например, Deluge,
Интересно, как же это я пользуюсь тогда.
Или запрещено но можно?
Вот аналогичный вопрос возник.
Раньше бана не было?
Изначальный ответ разработчиков - "Если из-за этого на «некоторых крупных российских трекерах» происходят утечки данных, то это результат того, что они не понимают разницу между общедоступным и частным торрент-файлом" (собственно, о чём я и говорил - изначально неудачное решение помещать в торрент конфиденциальные данные, но не помечать его приватным)
Изменение в версии 1.3.12, отключающее обмен анонсерами. Версии, древнее, чем эта, скорее всего, до сих пор забанены.
Но, когда проблему осознали, было уже поздно: годами торренты создавались без этого флажка, а изменить торрент задним числом не вариант - тогда у него поменяется хэш и все, кто его раздавал, отвалятся (соответственно, сидеров на старых раздачах станет ещё меньше, а их и так не хватает).
Разве? Насколько я помню, info_hash торрента считается из Bencode-представления ассоциативного массива info. Соответственно все, что в него не входит - включая флаг private и строку announce (URL до трекера) при своем изменении info_hash никак не затрагивает. В противном случае смена вшитого в announce URL пасскея пользователя бы тоже приводила к смене info_hash и невозможности связаться с остальными пирами - однако, как мы все знаем, этого не происходит.
а на ннмклаб как с этим обстоят дела ? тоже делятся по умолчанию ?
И как это в общих чертах реализовано
При обращении из торрент клиента к анонсеру трекера, трекер тупо проверяет строчку клиента из http запроса и если не валидный, то реджектят запрос. В свое время был активным девелопером модов под tbdev... вот тут можно чекнуть для tbdev:
https://github.com/yunasc/tbdev/blob/7f757ec5c65b258db54ccaecb92c98d073cc4931/announce.php#L88C1-L88C1ведь наверняка подменить название клиента для трекера довольно просто.
По факту ничего не мешает. Люди пересобирают торрент клиенты без логики учета скаченного/отданого, заменяют имя агента итд. Проверка от лукавого.
Люди пересобирают торрент клиенты без логики учета скаченного/отданого
Это работает только на мусорных трекерах, на серьёзных таких ушлых пользователей вычисляют и изгоняют. В ту же копилку "патч DHT", большинство пользователей которого вообще не представляют, как он работает и почему он либо бесполезен, либо вреден.
Торрент клиент отправляет аннонсеру peer_id который содержит название клиента и его версию. В движке лишь проверяется с чего начинается строка и на основе этого определяется клиент. Вот пример peer_id для qBitTorrent 3.1.3 - -qB3130-kwsSnUYwydys
Скажите пожалуйста, какие torrent-клиенты поддерживают ваши фичи "из коробки"?
qBittorrent поддерживает v2, но нужно скачивать не то что предлагается по умолчанию, а то в названии которого есть "_lt20_" . Вроде есть еще несколько клиентов.
А есть ли способ конвертации сотен старых torrent-файлов в новый формат? Ручная замена займёт... месяцы.
Емнип, при изменении торрент-файла, у него поменяется хэш, что фактически его убьёт, т.к. трекер будет считать, что это совсем другой торрент и отдавать ошибку "торрент не зарегистрирован на трекере".
Т.е., другими словами, нужно перекачать 1000 файлов. А есть ли у вас какое-либо API, которое позволило бы по ссылке на веб-страницу раздачи (из torrent-файла) получить файл v2?
Встречал функцию конвертации торрентов в BiglyBT, но сам не пользовался, не знаю подойдёт ли для вашего случая.
Автоматическая конвертация не имеет смысла, так как никто не удосужился стандартизовать алгоритм конвертации. Так бы хоть гарантированно v2 торрент происходил от v1 и был одинаков у всех, а так он не только отличаться будет, но может быть разным с после каждой конвертации.
https://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.
Все, которые используют libtorrent-rasterbar 2. Клиенты можно посмотреть в секции Required by. На данный момент это как минимум btfs, deluge, qbittorrent. Напомню, что libtorrent-rasterbar поддерживает последовательное скачивание для просмотра фильмов.
+Transmission 4.0
transmission не поддерживает v2. он поддерживает только гибридные торренты (где v1 хэш и v2 хэш), из которых берёт и использует v1 хэш
А написано и про hybrid и про v2
Support for using BitTorrent v2 torrents and hybrid torrents
Так как хеш каждого файла вшит в торрент файл, клиенты не тратят трафик на скачивание дубликатов.
Если можно было бы брать файлы с таким же hash, но из других раздач найденных по DHT - это была бы киллер-фича!
Можно было смержить тыщи раздач которые дополняются время от времени, музыкальные сборники итд
Совершенно верно. Можно было бы просто указать торрент-клиенту некий путь к "файлопомойке" и сказать: вот тебе место где хранятся всякие скачанные отовсюду файлы, проиндексируй и раздавай оттуда все что запросят по хешам". Преимущество - можно было бы не заботиться о постоянном размещении раздачи после скачивания, свободно перемещать ее по файловой системе, сортировать раздачи по смыслу и т.п., и торрент-клиент все равно бы их автоматически находил и раздавал.
Следующий шаг - это просто децентрализованный доступ к файловой системе, как (наверное) в RetroShare.
И микснуть это с ipfs)
Есть минимум несколько десятков децентрализованных файлообменных сетей. Само собой напрашивается мысль их все микснуть, причем на разных уровнях(к примеру обмен не только файлами но и пирами). Дальше возникает мысль о декомпозиции децентрализованных протоколов таким образом, чтобы любая сеть представлялась чем-то вроде множества "компонентов" разного уровня (сетевые, криптографические, прикладные...) со своими правилами и настройками. Между компонентами должны быть некие универсальные интерфейсы взаимодействия. Т.е. это серьезная работа по стандартизации самих концепций децентрализованных сетей, с тем чтобы любую сеть можно было разложить на простые унифицированные составляющие.
Вроде DC++ делал похожее. Ты открываешь у пользователя расшаренную папку, начинаешь качать оттуда какой-нибудь фильм - и клиент подтягивает его части не только у этого пользователя, а у кого-нибудь ещё в локалке.
Звучит как переизобретение DC++
Я не сомневаюсь что все уже давно придумано:) И вряд ли именно в торрентах будут такое делать. А вот если начнут появляться универсальные клиенты, объединяющие несколько (в идеале как можно больше) p2p сетей, то torrent v2 с его хешами к каждому файлу очень неплохо впишется в эту концепцию, гораздо лучше чем v1.
Так работает eMule. Я его иногда запускаю, там бывает активность даже на фильмах с русской озвучкой и на книгах на русском.
А не подскажете какой-нибудь инструмент для поиска по dht, чтобы как-нибудь не очень сложно на windows 10 запускался?
Поиск по GitHub выдаст много результатов на инструменты DHT индексатора.
BitMagnet к примеру.
Такая функция есть в BiglyBT, недавно добавили поддержку btmr хешей для точного поиска.
del
Есть одна задача, которая периодически возникает: передать от одного человека другому большой файл или папку. Использовать облака, файлообменники - это всё не то. Торрент как раз в теории отлично подходит. Но на практике вечно начинаются танцы с бубнами: клиенты не видят друг друга, передача не хочет стартовать, мешают NAT и фиг знает что ещё. Начинается прописывание айпи, игры с трекерами, с настройками клиентов, прописывание портов в роутерах и прочее, и в итоге не факт что будет толк. Хотелось бы, чтоб новые версии протокола и клиентов решали эту проблему, чтобы "частная" передача файла/папки по торренту делалась просто и стартовала надёжно и быстро. И желательно секьюрно.
Syncthing делает это всё и даже больше
И ещё BitTorrent Sync, но он не opensource.
Проблему с NAT решут в будущем Websocket трекеры, где обновления о пирах приходят мгновенно и используется stun.
Они планируются в библиотеке libtorrent вместе с WebTorrent, а значит будут в qBittorrent.
Если у обоих пиров IPv6, то данная проблема на личном опыте быстро решалась открытием порта торрент-клиенту. Другая проблема, что не каждый провайдер/оператор выдаёт IPv6 префикс абоненту, но если есть то чего не воспользоваться)
P.S. одному товарищу помогал настраивать IPv6-туннель для связанности.
Есть одна задача, которая периодически возникает: передать от одного
человека другому большой файл или папку. Использовать облака,
файлообменники - это всё не то.
Я IPFS для этих целей часто использую, причём получателю никакого софта устанавливать не обязательно, он может скачать через какой нибудь публичный web гейт. Собственно зачастую я сразу прямую https ссылку на файл или папку и отдаю. Но очень большие объёмы раздавать пока не приходилось, было где-то сотнями мегабайт. Публичные веб гейты обычно ограничены в ресурсах, даже cloudflare'вский https://developers.cloudflare.com/web3/how-to/use-ipfs-gateway/
Если ищете способ передать файлы вообще без установок программ на стороне отправителя, получателя, то для этого созданы p2p сайты на базе webrtc, поиск выдаёт много результатов, к примеру:
file.pizza
toffeeshare.com
У последнего есть также мобильное приложение, чтобы не было нужды держать браузер открытым.
поможет вашим пользователям находить отдельные файлы по их хешу, имени файла, направляясь на ваш ресурс.
Копирайтеру в помощь :)
Вот это новогодний подарок под ёлочкой)
P.S. Благодарю за добротную статью и освещение Bittorrent v2 & IPv6 в p2p лично автора)
TorrentPier — первый движок торрент-трекера с поддержкой BitTorrent v2