Comments 46
Хотя бы писали, за что минусуете, %хабралюди%, а то как то не конструктивно ))
разбить торрент на сущности
А chunk size узнать через libastral, да.
Я просто лишь хочу, что бы в указанной ему папке ему было совершенно до фени, как называется файл и переместил я его из внутренней папки или нет.
Такие вещи реально реализовать разве что в кооперации с файловой системой. Но незачем: есть симлинки. Даже на windows.
А chunk size узнать через libastral, да.
Протокол БитТоррента допускает передавать md5 файлов внутри торрент-файла. Вопрос в том, что при желании реализовать такую поддержку, например немного расширив протокол DHT можно.
акие вещи реально реализовать разве что в кооперации с файловой системой. Но незачем: есть симлинки. Даже на windows.
Т.е. вы считаете, что даже если реализовать методом:
— посчитали хеши файлов в указанной папке
— сопоставили с файлами что указаны в торрент-файле
— профит
И без всякого симлинка и привязки к оси не реально? При переименовании файла достаточно просто посмотреть, а какой файлик я (торрент-клиент) не учел и посчитать его хеш еще раз и сопоставить. Понятно, что симлинки лучше, но это требует лишних движений со стороны пользователя. А вот хеш пересчитывать можно и в тихоря в фоне и без лишнего дерганья юзверя.
Хм. У меня в одной директории могут валяться файлы от разных торрентов. Предположим, я переименовал один из них. Клиенту считать в реалтайме хэши когда пир спросит «где мой чанк»?
Кроме того, хэши практически всегда считаются не от файов а от кусков. Границы файлов и кусков не совпадают.
Кроме того, хэши практически всегда считаются не от файов а от кусков. Границы файлов и кусков не совпадают.
Кроме того, хэши практически всегда считаются не от файов а от кусков. Границы файлов и кусков не совпадают.
Торрент-файл допускает поле md5 файла, вопрос в том, кто мешает его заполнить.
Хм. У меня в одной директории могут валяться файлы от разных торрентов. Предположим, я переименовал один из них. Клиенту считать в реалтайме хэши когда пир спросит «где мой чанк»?
На пользу скорости и простоты можно использовать средства оси… в противном случае, пользователь должен быть готов к тому, что клиент временно перестанет раздавать/качать этот файл (ну либо качать/раздавать только его кеш).
Торрент-файл допускает поле md5 файла
Файлы никогда не могут скачиваться/раздаваться на основе этих данных. Прочитайте спецификацию.
Не поверите, читал. Я не спорю, что текущими методами протокола (хотя вот спецификацию конкретно DHT я не читал) это почти не реально. Но, никто же не мешает дописать. Или вы считаете, что обмен общими частями разных торрент-файлов не пойдет на пользу файлообмену? ИМХО, было бы желание реализовать, а уж методы найдутся.
Это будет сложно реализовать. Да и представляю себе торрент с парой миллионов мелких файлов.
Опять же шанс возникновения коллизии намного выше.
Вообще-то, я о том, что пользователи «классических» клиентов не поймут, когда им попытаются вместо chunk впарить файл.
Опять же шанс возникновения коллизии намного выше.
Вообще-то, я о том, что пользователи «классических» клиентов не поймут, когда им попытаются вместо chunk впарить файл.
Вообще-то, я о том, что пользователи «классических» клиентов не поймут, когда им попытаются вместо chunk впарить файл.
Это уже другая история… ни кто же не заставляет называть файл чунком? Назовите его файлом, напишите расширение протокола и вперед. Вот всякие uTP, DHT же тоже не всеми поддерживаются… и ничего так, живут же старые и новые клиенты вместе (тот же Азарус помнится пару расширений имел, не совсем стандартных)
И мы возвращаемся к началу разговора.
Переименование файла сломает совместимость с прочими клиентами. Они не хотят md5 и файл. А у «расширенного» клиента не будет возможности быстро сделать chunk.
Переименование файла сломает совместимость с прочими клиентами. Они не хотят md5 и файл. А у «расширенного» клиента не будет возможности быстро сделать chunk.
Переименование файла сломает совместимость с прочими клиентами. Они не хотят md5 и файл.
Я не понимаю, почему же сломает то. Проверить мой ли это файл — легко, да и на чанки это никак не повлияет… если я буду знать точно, что этот файл изначально назывался так и располагается в указанном месте в торренте.
А у «расширенного» клиента не будет возможности быстро сделать chunk.
Хм… подсмотрев ветку обсуждения чуть ниже, с реализацией в greylinkdc станет понятно, что не нужно долго перехешировать файл, на это может уйти всего долю секунды и без потери совместимости в принципе.
Опять же шанс возникновения коллизии намного выше.
Интересно… для галочки… а какой шанс коллизий в других p2p сетях? В тех же DC++ или eDonkey. Живут же как то.
UFO just landed and posted this here
Хм… вроде в семерке с последним ntfs они создаются не сложнее, чем в *nix (хотя могу ошибаться, знаю только на уровне чтения какой то статьи где-то)
Уж не знаю, на сколько это проще/сложнее:
en.wikipedia.org/wiki/NTFS_symbolic_link
en.wikipedia.org/wiki/NTFS_symbolic_link
Был древний костыль к TC, тогда ещё под XP и с маунтпойнтами вместо симлинков. Относительно удобен.
По первому пункту не согласен, реализация этого метода мало того, что нетривиальная, да и еще бесполезная. Таким образом можно легко захламлять нормальные торренты, всяким мусором. Хорошо когда это субтитры, а если это будет троянчик, или фейковые файлы от RIAA?
По второму пункту тоже не согласен, разные торренты могут содержать идентичные файлы, переместив которые вы убьете связь этих файлов с конкретным торрентом. А потом когда захотите удалить, или переместить, то могут возникнуть коллизии (переместиться и удалится может совсем не то).
По второму пункту тоже не согласен, разные торренты могут содержать идентичные файлы, переместив которые вы убьете связь этих файлов с конкретным торрентом. А потом когда захотите удалить, или переместить, то могут возникнуть коллизии (переместиться и удалится может совсем не то).
По первому пункту не согласен, реализация этого метода мало того, что нетривиальная, да и еще бесполезная. Таким образом можно легко захламлять нормальные торренты, всяким мусором. Хорошо когда это субтитры, а если это будет троянчик, или фейковые файлы от RIAA?
Наверное вы чуток не поняли идею. Не предлагается объединять торренты, а предлагается выкачивать общие части торрентов оттуда, где они есть. Т.е. в примере люди с трекера А не получат субтитры в торрент файле, они просто получат больше пиров, у которых есть серии сериала.
По второму пункту тоже не согласен, разные торренты могут содержать идентичные файлы, переместив которые вы убьете связь этих файлов с конкретным торрентом. А потом когда захотите удалить, или переместить, то могут возникнуть коллизии (переместиться и удалится может совсем не то).
Для этого есть папка торрента (обычно в случае многофайловых торрентов) и перемещать (переименовывать) файл я предлагаю только в рамках неё. Т.е. субтитры переместить из вложенной папки к видеофайлу и переименовать — пожалуйста. Переместить видеофайл из папки одного торрента в папку другого — фигу.
По первому пункту, да, в принципе можно сделать такое, только тут обламывается система учета рейтинга.
На счет второго все же есть претензии, я вот специально поискал, и нашел в пределах одного торрента, дубликаты: фронт-кавер для компакта лежит в корне торрента и в папке Covers. Как поступать с такими?
На счет второго все же есть претензии, я вот специально поискал, и нашел в пределах одного торрента, дубликаты: фронт-кавер для компакта лежит в корне торрента и в папке Covers. Как поступать с такими?
тут обламывается система учета рейтинга.
Нет, она обламывается гораздо раньше. При разрешении DHT в торренте.
По первому пункту, да, в принципе можно сделать такое, только тут обламывается система учета рейтинга.
Ну с DHT она обламывается не хуже ))) ни кто же не говорит о том, что торрент-файл на разных трекерах может быть одинаковый, а значит и при работе DHT все рейтинги относительны.
На счет второго все же есть претензии, я вот специально поискал, и нашел в пределах одного торрента, дубликаты: фронт-кавер для компакта лежит в корне торрента и в папке Covers. Как поступать с такими?
Вообще — это вопрос хороший. По логике, такой файлик и качать дважды не надо ;-). Если он одинаковый, то привязал его к одной сущности (ну или как то так) и спокойненько адресуешь их обоих. Думаю, что найдется достаточно простое решение для этого.
В файле .torrent по спецификации получается, что все файлы как бы собраны в один и логически разбиты на части одинаковой длины, и для каждой части хранится шаодин хэш. Таким образом — это болезнь(похоже что неизлечимая) самого протокола. Можно конечно вставлять куски между файлами, для того чтобы файлы разбивались на части однообразно, но это утопия.
Что касается переименования файлов, то я для себя написал приблуду для юторрента, которая пытается сопоставить файлы в торренте и файлы на диске, в этом не ничего сложного. Но как-то руки не дошли до приведения такой приблуды в вид, который можно не стыдясь опубликовать :)
Что касается переименования файлов, то я для себя написал приблуду для юторрента, которая пытается сопоставить файлы в торренте и файлы на диске, в этом не ничего сложного. Но как-то руки не дошли до приведения такой приблуды в вид, который можно не стыдясь опубликовать :)
Всё намного проще… см.мой комментарий ниже:
mear.habrahabr.ru/blog/97737/#comment_3003812
mear.habrahabr.ru/blog/97737/#comment_3003812
в greylinkdc (клиент dc++) к прохешированым файлам в нтфс поток добавляется запись с хешем, если файл потом переименуют или переместят он не будет заново хешироватся
в битторент и мюторрент тоже неплохо бы добавить такую функцию чтобы для при скачивании сериалов по серии в неделю не надо было перехешировать каждую серию снова и снова
в битторент и мюторрент тоже неплохо бы добавить такую функцию чтобы для при скачивании сериалов по серии в неделю не надо было перехешировать каждую серию снова и снова
Смотрим спецификацию на тему chunk и почему их границы не совпадают с границами файла. Думаем куда запихивать хэш.
BitTorrent не работает с файлами. Если он начнёт работать на уровне файлов — это будет уже другой протокол.
BitTorrent не работает с файлами. Если он начнёт работать на уровне файлов — это будет уже другой протокол.
md5sum: (optional) a 32-character hexadecimal string corresponding to the MD5 sum of the file. This is not used by BitTorrent at all, but it is included by some programs for greater compatibility.
wiki.theory.org/BitTorrentSpecification#Info_in_Multiple_File_Mode
Как я уже писал выше, указать в торрент-файле md5 конкретного файла допускается (поле там такое даже есть), весь вопрос только в том, что бы его указать на момент создания файла и всё будет реально.
Как я только что написал выше, «непродвинутым» клиентам будет пофиг md5 и для совместимости с ними всё равно придётся хэшировать chunk'и. Либо сделать сеть на своих клиентах, но при чём тогда BitTorrent?
Ну так никто не предлагает заменять чанки md5. Вопрос только в том, что при расположении файла на винте в первую очередь ориентироваться по его md5, а уж потом по имени и т.д. В этом случае мы как greylinkdc будем спокойно переносить переименование файла, но при этом на будет совершенно пофигу на другие клиенты (ведь вряд ли из-за того, что я скачав файлик greylinkdc переименую его у остальных клиентов DC++ которые это не поддерживают, всё отвалиться). Создали торрент-файл, посчитали хеши файлов, собрали chunk'и пометили файлы их md5, как это делает greylinkdc. Начали раздавать… в тоге торрент-клиент пофигу, если я переименую файлик, он знает его md5 и по записи в потоке ntfs быстро его найдет. А остальные клиенты (не поддерживающие это) ничего не потеряют и не приобретут. Те кто не понимает md5 файла в торрент-клиенте, просто проигнорят это поля, а те кто понимает, возьмут его на заметку… например, тоже для возможности переименования файлов.
Хм. Тогда получается в целом работающее решение.
Ограничения: предполагается что аплоадер сделал «правильный» торрент и ни в коем случае не меняет размер chunk если не прописал md5; предполагается что поиск по потокам ntfs быстрый (при большом числе файлов это может быть не так). Ну и небольшое повышение нагрузки на DHT.
Ограничения: предполагается что аплоадер сделал «правильный» торрент и ни в коем случае не меняет размер chunk если не прописал md5; предполагается что поиск по потокам ntfs быстрый (при большом числе файлов это может быть не так). Ну и небольшое повышение нагрузки на DHT.
Я не вижу в реализации описанного в посте чего то невозможного. Понятно, что не всё сразу и возможно придется дописывать расширение протокола, которым будет пользоваться только один клиент и такое расширение будет работать только между этими клиентами (ну как тот же Азарус например делает (или делал)). Но по крайней мере такие вещи мне кажутся более полезными, чем тот же стримминг недокаченного видео.
Ладно как это будет на практике. Допустим у двух пиров есть наборы файлов, состоящие из частично одинаковых файлов (у которых совпадает MD5). Для того чтобы начать обмениваться файлами — нужно ещё будет обменяться информацией о чанках и перехэщировать эти чанки. А хэширование — процесс очень ресурсоемкий.
Существует радикально альтернативный вариант действий для файлообменщика с Вашими запросами и желаниями: сменить файлообменную сеть.
Перейти с μTorrent на eMule. Вместо сети BitTorrent использовать ed2k, вместо DHT — сеть Kad. Достоинство в том, что файлообмен единый (без разделения на трэкеры). Зато раздельными являются рейтинги (основаны на пропорции «ты мне / я тебе»). Гиперссылки «ed2k://…» работают без ограничений, в отличие от «magnet:…».
Одновременно можно приучиться вместо торрентов-папок использовать ed2k-коллекции (файлы с именами вида «*.emulecollection»). Достоинство в том, что каждая коллекция содержит все хэши всех файлов (соответственно, файлообмены одинаковых файлов из разных коллекций объединяются, даже если файлы переименованы); недостаток в том, что коллекция содержит имена файлов без путей.
Перейти с μTorrent на eMule. Вместо сети BitTorrent использовать ed2k, вместо DHT — сеть Kad. Достоинство в том, что файлообмен единый (без разделения на трэкеры). Зато раздельными являются рейтинги (основаны на пропорции «ты мне / я тебе»). Гиперссылки «ed2k://…» работают без ограничений, в отличие от «magnet:…».
Одновременно можно приучиться вместо торрентов-папок использовать ed2k-коллекции (файлы с именами вида «*.emulecollection»). Достоинство в том, что каждая коллекция содержит все хэши всех файлов (соответственно, файлообмены одинаковых файлов из разных коллекций объединяются, даже если файлы переименованы); недостаток в том, что коллекция содержит имена файлов без путей.
Между прочим, этот вариант действий, несмотря на всю его радикальность, пользуется некоторой популярностью. В списке наипопулярнейших (по числу скачиваний) проектов SourceForge (прилагаю его peeep-слепок на случай хабраэффекта) лидирует eMule, он обгоняет по популярностью любой битторрентовый клиент (даже Azureus).
ed2k к сожалению не поддерживает раздачу кучки файлов одним паком
Что такое «раздача кучки файлов одним паком» и для чего она нужна — иными словами, каковы её достоинства по сравнению со следующими (противоположными друг другу) вариантами:
1) Раздача списка файлообменных гиперссылок на эти файлы («*.emulecollection»), из которого получатель сам может выбрать, какие качать, какие не качать.
2) Раздача обычного архива файлов («*.zip», «*.rar», и проч.), который получатель обязан выкачать целиком, без чего не сможет достать из него файлы.
1) Раздача списка файлообменных гиперссылок на эти файлы («*.emulecollection»), из которого получатель сам может выбрать, какие качать, какие не качать.
2) Раздача обычного архива файлов («*.zip», «*.rar», и проч.), который получатель обязан выкачать целиком, без чего не сможет достать из него файлы.
Второй пункт теоретически можно реализовать через WinAPI-хуки. Только вот нужно ли.
Если вопрос в самой цели, то:
Зачастую хочется переименовать субтитры под название видеофайла, но при этом не хочется делать беспорядок из копий этих же файлов. Или, если фильм поставляется с несколькими вариантами субтитров, а проименованы они по левому и лежат в подпапках, то можно оставить только понравившийся вариант сабов, переместить в папку с фильмом и переименовать под него. Так будет порядок и при этом торрент-клиент будет корректно раздавать имеющийся у вас контент.
Если вопрос с технической стороны, то:
Повесить обработку на событие изменения FS — это пожалуй самый быстрый способ понять, что и во что переименовали или куда переместили. Так даже хеши проверять не придется или делать какие то обходы в поиске нужного файла. Так что, хуки — это наиболее правильный, с точки зрения эффективности, способ.
Зачастую хочется переименовать субтитры под название видеофайла, но при этом не хочется делать беспорядок из копий этих же файлов. Или, если фильм поставляется с несколькими вариантами субтитров, а проименованы они по левому и лежат в подпапках, то можно оставить только понравившийся вариант сабов, переместить в папку с фильмом и переименовать под него. Так будет порядок и при этом торрент-клиент будет корректно раздавать имеющийся у вас контент.
Если вопрос с технической стороны, то:
Повесить обработку на событие изменения FS — это пожалуй самый быстрый способ понять, что и во что переименовали или куда переместили. Так даже хеши проверять не придется или делать какие то обходы в поиске нужного файла. Так что, хуки — это наиболее правильный, с точки зрения эффективности, способ.
Sign up to leave a comment.
Рассуждения на тему: что бы я хотел видеть в BitTorrent