Comments 108
>uTorrent
я конечно ничего против него не имею, да и у меня он стоит, но как же линуксоиды?
я конечно ничего против него не имею, да и у меня он стоит, но как же линуксоиды?
Линуксоиды, как обычно, сами что-то смастерят!
Вот-вот. Сам линуксоид. В последнее время торренты создаю исключительно в uTorrent под вайном, потому что в азуреусе никаких опций создания торрентов по очистке от «мусора» просто не нашел.
Deluge?
И проблема «мусора» в торрент-файлах надумана, кмк.
И проблема «мусора» в торрент-файлах надумана, кмк.
а что с KTorrent?
Хм. Я всегда торенты собираю с помощью btmakemetafile.
Кстати а чем так структуру файла то смотреть как на скринах?
Кстати а чем так структуру файла то смотреть как на скринах?
Можно использовать BEncode Editor.
Ниже найден ответ: «TorrentSpy (в убунте под вайном)))».
ну вы конечно мудрите с utorrent'ом под вайном (-: в линуксах соих клиентов огого
тот же qBittorrent (-:
с версии v2.1.0rc1 у них появились такие штуки относящиеся к uTorrent:
FEATURE: uTorrent compatible tracker list support (use torrentz.com url as a default)
FEATURE: qBittorrent can identify itself as uTorrent, Vuze or KTorrent (Any stable version)
выглядит все это дело от так: rghost.ru/788201/image.png
кстати, в qBittorrent лично для меня есть одна киллерфича, он умеет качать файл «ровно», т.е. ставлю на закачку фильм и тут же начинаю и его смотреть (скорость интернетов позволяет)
тот же qBittorrent (-:
с версии v2.1.0rc1 у них появились такие штуки относящиеся к uTorrent:
FEATURE: uTorrent compatible tracker list support (use torrentz.com url as a default)
FEATURE: qBittorrent can identify itself as uTorrent, Vuze or KTorrent (Any stable version)
выглядит все это дело от так: rghost.ru/788201/image.png
кстати, в qBittorrent лично для меня есть одна киллерфича, он умеет качать файл «ровно», т.е. ставлю на закачку фильм и тут же начинаю и его смотреть (скорость интернетов позволяет)
кстати, в qBittorrent лично для меня есть одна киллерфича, он умеет качать файл «ровно», т.е. ставлю на закачку фильм и тут же начинаю и его смотреть (скорость интернетов позволяет)Это не уникальная фича. Ряд других BT-клиентов тоже поддерживают последовательную смотрибельную закачку. Вот статья на Хабре про такую фичу, появившуюся в uTorrent.
Видели бы вы, что творит Transmission под MacOS…
Там только для имени 3 поля.
Там только для имени 3 поля.
UFO just landed and posted this here
Вот косяк! Кто же это придумал то а! Всегда считал что хеш у торентов это хеш сумма от самого файла! А тут выходит, что ошибался, что от инфо-данных в торент-файле. Понятное дело, что тогда добиться одинаковых хешей на разных трекерах практически не реально.
Да, битторренту еще есть, куда расти. Очевидно, что хэширование по контенту, а не по названию и размеру файла было бы куда правильней.
Более того, бывает, что файлы идентичны не на 100%. Такой случай, думаю, вполне можно было бы реализовать на уровне протокола, но это уже довольно революционные нововведения, время которых еще наверно не пришло.
Более того, бывает, что файлы идентичны не на 100%. Такой случай, думаю, вполне можно было бы реализовать на уровне протокола, но это уже довольно революционные нововведения, время которых еще наверно не пришло.
Вообще-то именно это и стало причиной большей популярности торрентов перед e2k, благодаря тому, что трекеры смогли «приватизировать» раздачи. Ну и хэши от частей файлов в битторренте тоже считаются.
Автор, с каких пор метаданные хэшируются? Что за бред? Обратите внимание на Pieces Length у uTorrent'a, потом на Pieces Length у Azureus'a, а теперь читаем выкладку из библии «pieces: string consisting of the concatenation of all 20-byte SHA1 hash values, one per piece (byte string, i.e. not urlencoded)». Соответственно и хэши будут разные, т.к. первый же кусок (в силу разницы длины) уже имеет иную контрольную сумму.
Собственно тут и собака зарыта, имхо.
Я с торрентами слабо связан, но чую, что не дебилы в BitComet'e надо спецификацией работали.
Собственно тут и собака зарыта, имхо.
Я с торрентами слабо связан, но чую, что не дебилы в BitComet'e надо спецификацией работали.
А метаданные кто хочет так и накручивает — на то они и метаданные.
Если вдруг не прав — ткните меня носом, где вообще говориться о калькуляции контрольной суммы метаданных внутри .torrent файла и как это влияет на потерю.
Отличия Azureus/uTorrent приведены (pieces lengths), они, вероятно, могут влиять не в лучшую сторону на ситуацию с дубликатами.
Если вдруг не прав — ткните меня носом, где вообще говориться о калькуляции контрольной суммы метаданных внутри .torrent файла и как это влияет на потерю.
Отличия Azureus/uTorrent приведены (pieces lengths), они, вероятно, могут влиять не в лучшую сторону на ситуацию с дубликатами.
Я говорю глупости, а вы меня плюсуете. Перечитал трижды автора, речь идет об info_hash, который «urlencoded 20-byte SHA1 hash of the value of the info key from the Metainfo file.»
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
…
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
Я больше не буду влазить с «умными» мыслями в тему, в которой не шарю.
…
Уж, к сожалению, далеко не меньшинство подобных ситуаций на Хабре!..
Отчасти хотя был прав, это уже радует, т.к. указанные особенности (pieces length) создания торрент-файлов тоже будут влиять на хэш, т.к. входят в Info Directory. Просто не обратил внимание на то, что речь идет о info_hash со всеми вытекающими и накричал на автора, за что стыдно. Приношу свои извинения.
а еще вы зря считаете, что «там» далеко не «дебилы» сидят. Это глупо считать, что любая западная/азиатская компания защищена от дебилов и идиотов.
Перенес в Peer-to-Peer.
А что размер кусков уже нельзя задать при создании торрента?
Варианты решения — почти утопические.
1. Вариант возможен, но для его достижения нужен стандарт, которого нет (см. п2)
2. Каждый разработчик торрент клиента видит по своему структуру торрент файла, ибо этот файл мини БД, в которую можно поместить много нужной и ненужной информации. Стандартизация в наш век открытого ПО с уклоном на конкуренцию маловероятна. Например для меня очень удобно видеть в инфе о торренте комментарий с адресом раздачи (как на torrents.ru), ибо быстрее скопировать ссылку, чем найти в поиске.
3. uTorrent пока только для Windows, для макоси в бете. Для линукса его вообще нет (только в wine). А т.к. пользователей noWin систем не мало, то и этот вариант неподходит.
Если бы все было стандартизировано, то мы не увидели бы большого количества замечательных программ, которые появились на свет благодаря тому, хотят отличаться от тех программ, которые уже есть.
1. Вариант возможен, но для его достижения нужен стандарт, которого нет (см. п2)
2. Каждый разработчик торрент клиента видит по своему структуру торрент файла, ибо этот файл мини БД, в которую можно поместить много нужной и ненужной информации. Стандартизация в наш век открытого ПО с уклоном на конкуренцию маловероятна. Например для меня очень удобно видеть в инфе о торренте комментарий с адресом раздачи (как на torrents.ru), ибо быстрее скопировать ссылку, чем найти в поиске.
3. uTorrent пока только для Windows, для макоси в бете. Для линукса его вообще нет (только в wine). А т.к. пользователей noWin систем не мало, то и этот вариант неподходит.
Если бы все было стандартизировано, то мы не увидели бы большого количества замечательных программ, которые появились на свет благодаря тому, хотят отличаться от тех программ, которые уже есть.
Позвольте с вами не согласиться.
1) Кто знает, может разрабы-таки придут к единому мнению и стандарту.
2) Вне секции info можно безболезнено пихать хоть «Войну и мир», хоть линк на топик раздачи (как это обычно делается), а вот содержание info желательно держать в чистоте.
3) Ну здесь выходов много: от принудительной чистки info трекерами до создания онлайн-сервиса, занимающегося этим, и создания кроссплатформанного генератора торрент-файлов. Думаю, это несложно.
Стандартизация внутреннего механизма отнюдь не лишает разрабов возможности улучшать «внешние» фичи.
1) Кто знает, может разрабы-таки придут к единому мнению и стандарту.
2) Вне секции info можно безболезнено пихать хоть «Войну и мир», хоть линк на топик раздачи (как это обычно делается), а вот содержание info желательно держать в чистоте.
3) Ну здесь выходов много: от принудительной чистки info трекерами до создания онлайн-сервиса, занимающегося этим, и создания кроссплатформанного генератора торрент-файлов. Думаю, это несложно.
Стандартизация внутреннего механизма отнюдь не лишает разрабов возможности улучшать «внешние» фичи.
Что делать?
4. Использовать ed2k. Да, там нет такой удобной фишки, как раздача каталогов, но проблем с отличием хеша в метаданных тоже нет :)
4. Использовать ed2k. Да, там нет такой удобной фишки, как раздача каталогов, но проблем с отличием хеша в метаданных тоже нет :)
Всецело согласен с Вами, тем более что серьёзные сайты раздачи телесериалов одновременно предоставляют читателям и ed2k-гиперссылки, и торренты. Обратите внимание, скажем, на страницу сериала «Heroes» сайта TV Underground. Несомненное достоинство в том, что по гиперссылкам оттуда приводятся сразу два хэша (ed2k и AICH), что позволяет сделать ed2k-файлообмен ещё комфортнее.
Да, то что хеши одинаковые- большой плюс. Но вы посмотрите на ужасный механизм рейтинга и очередей в ed2k! В bittorrent'е мне больше всего нравится скорость, но есть причины по которым он мне не нравится: первая проблема была обозначена в статье: два одинаковых файла с разными именами или созданные разными клиентами имеют разные хеши, а вторая- это то, что хеши директорий счищаются для всего каталога, а не для отдельных файлов в нем.
Рейтинг в ed2k поддерживается только несколькими клиентами, на сколько я знаю. Проблем с очередями никогда не видел. Ну, лет 8 назад да, были. Но и то, на любой активной раздаче через полчаса-час появляется достаточно пиров. Главное что б клиент умел держать несколько тысяч коннектов.
Простите, если не прав, сужу по ощущениям: один и тот же файл с одинаковым кол-вом раздающих по bittorret'у скачается гараздо быстрее, причем всегда.
Таки да, я этого не отрицаю. Но вот если торрент вынесли с трекера и раздающих больше нет, то ed2k в этом случае быстрее в бесконечность раз :)
Почему-то мне кажется, что идентификатором одинаковых торрентов должен быть хеш от содержимого раздваемых файлов. Тогда можно будет решить несколько проблем:
— Одинаковые раздачи из разных клиентов.
— Одинаковые раздачи с разными именами и структурой папок и файлов.
— Одинаковые раздачи из разных клиентов.
— Одинаковые раздачи с разными именами и структурой папок и файлов.
Пусть вы качаете торрент с программой. Есть один торрент, где файлы программы разложены по папкам правильно и другой — где всё лежит неправильно (свалено в одну кучу и с левыми именами). Естественно, что программа из этого второго торрента будет неработоспособной. И с полезностью близкой к нулевой. А хэши-то у торрентов одинаковые, т.е. на уровне клиента и трекера — там одно и то же. Нехорошо? Думаю, да. Так что согласитесь, что использование для хэша ТОЛЬКО содержимого — не самая удачная идея.
Полезность такой раздачи будет не нулевая для тех, кто скачал торрент с нормальной структурой папок. Если я создам торрент-файл с неверной структурой и выложу его на раздачу на трекере, то эту раздачу скоро закроют.
Основная проблема в том, что в общем случае ни конечный пользователь, ни трекер не могут отличить правильную раздачу от неправильной.
Я согласен, что хорошо бы быть привязанным только к самим данным. Но одной такой привязки будет недостаточно для обеспечения «информационной целостности» раздачи. В идеале должен был бы быть хэш для структуры (имена файлов и папок) и хэш данных каждого отдельного файла (без учета имени). Но по понятным причинам это не используется — так как торренты для раздач с большим количеством мелких файлов сами по себе были бы слишком большими.
Поэтому как простой компромисс мы получили то, что сейчас имеем — тот самый info_hash, учитывающий и данные, и структуру.
Я согласен, что хорошо бы быть привязанным только к самим данным. Но одной такой привязки будет недостаточно для обеспечения «информационной целостности» раздачи. В идеале должен был бы быть хэш для структуры (имена файлов и папок) и хэш данных каждого отдельного файла (без учета имени). Но по понятным причинам это не используется — так как торренты для раздач с большим количеством мелких файлов сами по себе были бы слишком большими.
Поэтому как простой компромисс мы получили то, что сейчас имеем — тот самый info_hash, учитывающий и данные, и структуру.
Если ограничиться передачей одного файла — а папки представлять, например, tar-ом, то во втором описанном Вами случае будет другой файл, и соответственно другой хэш.
автор не понимает смысла private, ни трекеров, ни смысла добавления этого флажка. весь смысл закрытого трекера в том, чтобы быть закрытым, чтобы пользователи качали только с других пользователей этого же трекера, и раздавали только пользователям этого трекера. чтобы трафик учитывался только внутри-трекерный. правила многих закрытых трекеров явно запрещают мульти-трекерные раздачи.
Зачем же тогда было создавать флаг private, если можно было просто мусорить хэш? Private запрещает DHT, этого и желают владельцы трекеров, а не запрета использования их раздач как мультитрекерных. От мультитрекерности, по-моему, еще никто не страдал — ни владельцы трекеров, ни конечные пользователи.
Все достаточно просто, возьмем например клиент uTorrent, и 2 закрытых трекера А и Б со своим рейтингом и особенностями
На обоих трекерах есть 1 и тот же торрент с одной и той же хеш суммой и с флагом private=1
Пользователь качает раздачу с трекера А, и после того как скачал например хочет поддерхать ее на трекере Б
При скачиваннии торрент файла с трекера Б и добавлении его в клиент — Клиент скажет, что торрент с таким хешом уже существует и просто предложит добавить УРЛ трекера к списку трекеров
В итоге: вся суммарная статистика (не важно с какого трекера были получены пиры) о всем трафике будет отослана и на оба трекера и получится вышеупомянутая мульти-трекерная раздача
На обоих трекерах есть 1 и тот же торрент с одной и той же хеш суммой и с флагом private=1
Пользователь качает раздачу с трекера А, и после того как скачал например хочет поддерхать ее на трекере Б
При скачиваннии торрент файла с трекера Б и добавлении его в клиент — Клиент скажет, что торрент с таким хешом уже существует и просто предложит добавить УРЛ трекера к списку трекеров
В итоге: вся суммарная статистика (не важно с какого трекера были получены пиры) о всем трафике будет отослана и на оба трекера и получится вышеупомянутая мульти-трекерная раздача
Ну тогда private=1 и в Азуреус и в мюТоррент. Вопрос в том, зачем добавлять строчку, которая дублирует значение по умолчанию? Она ведь меняет хэш и всё. Больше ничего не затрагивает.
Впрочем, я не критикую закрытые трекеры. Их право быть отрезанными от мира. Я говорю в целом о проблеме в глобальном масштабе.
угу, отрезанные и от DHT, и от PEX. локальные ретркеры — отдельный вопрос, считается что пользы от них больше чем вреда.
проблема мультитрекерности в том, что торрент-клиент каждому трекеру отправляет суммарную статистику. допустим, он нашёл одного пира с трекера А, двух с трекера Б, и ещё трёх через DHT и PEX. каждому отдал по мегабайту. трекеру А рапортует, что с последнего анонса отдал 6 мегабайт. тот пир, которого он нашёл через трекер А, говорит что он суммарно скачал мегабайт. и в результате дебет с кредитом не сходится, 6 отдали, 1 получили. что делать? банить за читерство?
проблема мультитрекерности в том, что торрент-клиент каждому трекеру отправляет суммарную статистику. допустим, он нашёл одного пира с трекера А, двух с трекера Б, и ещё трёх через DHT и PEX. каждому отдал по мегабайту. трекеру А рапортует, что с последнего анонса отдал 6 мегабайт. тот пир, которого он нашёл через трекер А, говорит что он суммарно скачал мегабайт. и в результате дебет с кредитом не сходится, 6 отдали, 1 получили. что делать? банить за читерство?
на сколько я помню, в мю 1.8 уже нельзя на приватном торренте включить pex, dht и даже заставить работать второй трекер. Будет выбираться всегда первый из списка и на него всё анонсится.
включить DHT никогда и не было возможности, есть только патчи от народных умельцев, которые это позволяют на private-торрентах делать.
а вот список трекеров редактировать можно абсолютно без проблем во всех версиях. только начиная с версии 1.7, емнип, при этом стал сбрасываться список пиров, раньше даже этого не было.
все трекеры из списка всегда работают, всем вся статистика посылается. точнее как, там есть 2 варианта, если в интерфейсе уТ то если трекеры идут подряд, без пустой строки между ними, то да, из них выбирается только один. если через пустую строку — то все.
а вот список трекеров редактировать можно абсолютно без проблем во всех версиях. только начиная с версии 1.7, емнип, при этом стал сбрасываться список пиров, раньше даже этого не было.
все трекеры из списка всегда работают, всем вся статистика посылается. точнее как, там есть 2 варианта, если в интерфейсе уТ то если трекеры идут подряд, без пустой строки между ними, то да, из них выбирается только один. если через пустую строку — то все.
на какой-то из версий можно было добавлять трекеры в список, но уТ показывал, что работает только с одним.
Отправлял ли он статистику на оба я не знаю, может быть. Но статус и время анонса второго трекера на приватных торрентах не показывал.
Отправлял ли он статистику на оба я не знаю, может быть. Но статус и время анонса второго трекера на приватных торрентах не показывал.
Для примера — при добавлении торрент файла с уже существующим в клиенте хешом и согласия добавить список трекеров — utorrent добавляет точно с пустой строкой
P.S. PEX работает даже при private=1
Заметил еще один интересный момент: (DHT disabled, насчет private=1 точно сейчас не скажу)
Есть трекер, на нем есть например 2 раздачи
пользователь скачал первую — получил список пиров… качает
трекер падает
пользователь качает вторую раздачу
от трекера получает постоянно timed out, при этом для раздачи 2 начинает подтягивать пиров из раздачи 1 у которых есть раздача 2
P.S. PEX работает даже при private=1
Заметил еще один интересный момент: (DHT disabled, насчет private=1 точно сейчас не скажу)
Есть трекер, на нем есть например 2 раздачи
пользователь скачал первую — получил список пиров… качает
трекер падает
пользователь качает вторую раздачу
от трекера получает постоянно timed out, при этом для раздачи 2 начинает подтягивать пиров из раздачи 1 у которых есть раздача 2
нет, если стоит private то через PEX, по кр. мере уТоррент, обменивается только своими адресами. IPv4 и IPv6. мы столкнулись с этим когда пытались как одну из мер приватности и скрытия адресов пользователей дать возможность передавать через трекер только IPv6. к сожалению, другие клиенты v4 адрес тоже узнавали. возможно другие клиенты так не делают, надо будет попробовать со временем.
я к тому что адреса других пиров через PEX точно не передаются если флаг private стоит. посмотри, на загладке Peers буковка X — у меня стоит только на паре IPv6 адресов.
по поводу обмена «какие ещё раздачи я качаю», хм… это же не безопасно? в смысле если враг ко мне подключился, он узнает какие ещё торренты я качаю? хм… не знал. вообще PEX — это обмен адресами других пиров на той же самой раздаче, а не других моих раздач…
а там точно ретрекеров не было или ещё чего? как-то не верится, надо будет доки почитать…
я к тому что адреса других пиров через PEX точно не передаются если флаг private стоит. посмотри, на загладке Peers буковка X — у меня стоит только на паре IPv6 адресов.
по поводу обмена «какие ещё раздачи я качаю», хм… это же не безопасно? в смысле если враг ко мне подключился, он узнает какие ещё торренты я качаю? хм… не знал. вообще PEX — это обмен адресами других пиров на той же самой раздаче, а не других моих раздач…
а там точно ретрекеров не было или ещё чего? как-то не верится, надо будет доки почитать…
ретрекеров — точно не было, если интересно в аську или ЛС кину больше подробностей о трекере и т.д.
Мне почему-то кажется более вероятным вариант, что utorrent запрашивает у клиента раздачу по хешу, а не клиент отдает список своих раздач
Уточни, что ты имеешь ввиду под «обменивается только своими адресами», из контекста не совсем понятно…
Мне почему-то кажется более вероятным вариант, что utorrent запрашивает у клиента раздачу по хешу, а не клиент отдает список своих раздач
Уточни, что ты имеешь ввиду под «обменивается только своими адресами», из контекста не совсем понятно…
проблема известная — но пока по какой-то причине не решаемая со стороны разработчиков… присоединяюсь к автору +1
А кто сказал, что эти поля используються при хешировании.
Насколько мне известно методы hash() и equals() перекрываются на раз в Java.
Насколько мне известно методы hash() и equals() перекрываются на раз в Java.
бот, что ли? какая еще Java?
Сами вы — бот.
Какая есть Java, я думаю, вы и сами сможете найти.
А причем тут Java — читаем ru.wikipedia.org/wiki/Azureus.
Какая есть Java, я думаю, вы и сами сможете найти.
А причем тут Java — читаем ru.wikipedia.org/wiki/Azureus.
какая связь между хешем от торрент-раздачи и хешем от объекта в джаве?
Автор топика нашел в torrent файле сформированном программой Azureus «лишние поля», которые как он предположил могут влиять на хеш.
(т.к. хэш явно будет другим только от того, что появились эти поля).
Я же в свою очередь предположил, что далеко не факт, что все поля указанные в торрент-фалей будут влиять на подсчет его хэша и в качестве примера привел один из самых простых способов реализации этого, используя технологии на которых написан Azureus.
Ещё вопросы?
(т.к. хэш явно будет другим только от того, что появились эти поля).
Я же в свою очередь предположил, что далеко не факт, что все поля указанные в торрент-фалей будут влиять на подсчет его хэша и в качестве примера привел один из самых простых способов реализации этого, используя технологии на которых написан Azureus.
Ещё вопросы?
На подсчет хэша влияет все, что находится внутри секции info, потому и называется info_hash. Эти новые поля как раз в эту секцию входят, так что хэш меняется с вероятностью в 100%.
если только чудом при создании хэша не будет создаваться временная ветка info куда попадают нужны нам поля (считай по стандарту) и от нее уже брать кэш.
А кто сказал, что эти поля используються при хешировании?
Насколько мне известно методы hash() и equals() перекрываются на раз в Java.
Насколько мне известно методы hash() и equals() перекрываются на раз в Java.
А можно вопрос не по теме? Какой программой вы так красиво info-секцию развернули? Заранее спасибо :)
Я может не очень разбираюсь в таких тонкостях битторрент процесса, но если посмотреть масштабнее, то именно то что один и тот же контент раздается под разным так сказать соусом (битторрент файлами), позволяет безконтрольно раздавать их, а если представить, к пример, есть iso-образ игры который раздается везде с помощью одного торрент файла, тогда правообладатель без проблем прикроет лавку.
Поправьте меня если я не прав.
Поправьте меня если я не прав.
Как можно прикрыть раздачу через DHT???
ru.wikipedia.org/wiki/DHT
ru.wikipedia.org/wiki/DHT
описанное не баг, а фича.
треккеры врятли заинтересованны в большом распространении контента вне самого треккера. ну вы поняли, да?
треккеры врятли заинтересованны в большом распространении контента вне самого треккера. ну вы поняли, да?
закрытые — да. открытые — нет, наоборот они заинтересованы в как можно более широком распространении. чем больше пиров — тем лучше. для этого все DHT, PEX и придумывались, вслед за ними и magnet-ссылки.
вообще по поводу того что написано в посте, не помню с год назад или два создатели трекера ThePirateBay задумывали создание нового протокола, который будет лучше защищен от копирастов, и кроме этого там предлагалось кроме хэша инфо-блока добавлять хэши каждого файла, так чтобы если в двух разных торрентах раздавался один и тот же файл, его можно было «объединить» между ними
вообще по поводу того что написано в посте, не помню с год назад или два создатели трекера ThePirateBay задумывали создание нового протокола, который будет лучше защищен от копирастов, и кроме этого там предлагалось кроме хэша инфо-блока добавлять хэши каждого файла, так чтобы если в двух разных торрентах раздавался один и тот же файл, его можно было «объединить» между ними
У меня довольно шустрый инет, поэтому постоянно что-то раздаётся, не потому что я вынужден, а потому что не жалко и для меня ненапряжно.
Мне вообще кажется, что закрытые трекеры с рейтингами — это вынужденная мера, чтобы вынудить пользователей с медленным и недешёвым инетом оставаться на раздаче и поддерживать тем самым файлообмен. Ну а для коммерческих трекеров ещё выгодно приватизировать трекеры и замыкать пользователей на себя (чтобы стричь деньги с показов рекламы посетителям).
Но с развитием инфраструктуры и увеличением скорости инета у широкого круга пользователей (в частности в российской глубинке), я думаю, что мы постепенно вовсе уйдём от рейтинговой системы и приватных торрентов. В той же Европе уже сейчас больше пользуются открытыми трекерами вроде openbittorrent.com и publicbt.com (а ранее thepiratebay.org).
И мне идеология открытых трекеров нравится куда больше. Вот, например, сейчас кто-то не может из-за низкого рейтинга скачать что-то через трекер torrents.ru. А у меня на том же трекере терабайты раздач и рейтинг больше 10. Мне он такой нафиг не нужен, а кому-то не хватает. А на открытом трекере без рейтингов любой юзер сможет скачать, и мне не жалко с ним поделиться даже без отдачи с его стороны, и там я могу себе это позволить.
Мне вообще кажется, что закрытые трекеры с рейтингами — это вынужденная мера, чтобы вынудить пользователей с медленным и недешёвым инетом оставаться на раздаче и поддерживать тем самым файлообмен. Ну а для коммерческих трекеров ещё выгодно приватизировать трекеры и замыкать пользователей на себя (чтобы стричь деньги с показов рекламы посетителям).
Но с развитием инфраструктуры и увеличением скорости инета у широкого круга пользователей (в частности в российской глубинке), я думаю, что мы постепенно вовсе уйдём от рейтинговой системы и приватных торрентов. В той же Европе уже сейчас больше пользуются открытыми трекерами вроде openbittorrent.com и publicbt.com (а ранее thepiratebay.org).
И мне идеология открытых трекеров нравится куда больше. Вот, например, сейчас кто-то не может из-за низкого рейтинга скачать что-то через трекер torrents.ru. А у меня на том же трекере терабайты раздач и рейтинг больше 10. Мне он такой нафиг не нужен, а кому-то не хватает. А на открытом трекере без рейтингов любой юзер сможет скачать, и мне не жалко с ним поделиться даже без отдачи с его стороны, и там я могу себе это позволить.
Ну а прочие вопросы с унификацией хэшируемой информации, конечно, тоже нужно как-то решать.
рейтинги стимулируют пользователей отдавать еще и тем аспектом, что рейтингом можно померяться :)
В пользу открытости. Когда я качаю с открытых трекеров, скачанный материал раздаётся с меня многократно (в 5-10 раз больше, бывает) — даже при непопулярном/странном контенте. В то же время на торрнет.ру еле свожу концы с концами.
А если Azeurus или uTorrent поменяет алгоритм создания новых хэшей в клиенте — это может вызвать проблемы с уже существующими торрентами у людей?
Кстати, мне может кто-нибудь объяснить одну вещь? Я разбирался в разнице работы протоколов ed2k, gnutella и torrent, но так и не смог понять — почему торренты качаются НАСТОЛЬКО быстрее? Каждый из алгоритмов был продуман умными людьми и оптимизирован (в течение нескольких лет, Gnutella, скажем вообще однажды полностью поменяла алгоритм поиска). Почему в torrente не нужно по полчаса ждать своей очереди, практически независимо от твоей скорости и рейтинга. Да, в torrente мы раздаем только то, что сами выберем в списке, а в других файлообменных сетях мы расшариваем целые папки. Но не верю я, что дело в только в количестве раздаваемых файлов на каждого пользователя.
Есть большая разница между bittorrent и gnutella. gnutella — децентрализованная. а децентрализация всегда дается «не бесплатно». Зато gnutella будет работать даже если трекер в bittorrent'е «ляжет». Причем будет работать и скачивание и даже поиск новых фильмов. Централизованные системы всегда проще и эффективнее, но имеют Single Point of Failure.
в старых п2п системах чтобы начать раздавать надо было скачать весь файл, или всю пачку, весь релиз — целиком. ибо чтобы проверить целостность там была только хэш-сумма всего большого файла.
в торренте большой файл делится в среднем на тысячу мелких кусочков, в торрент-файле хранится хэш сумма каждого такого куска. в этом отличие — что нужен довольно большой торрент-файл с метаданными, а не крохотная ссылка.
в результате как только кто-то скачал один из крохотных кусков — он тут же может начинать раздавать этот кусок остальным. и получаешься дашь-на-дашь, я скачал один кусок, и обмениваюсь уже не только с главным источником, но и всеми остальными качающими
в торренте большой файл делится в среднем на тысячу мелких кусочков, в торрент-файле хранится хэш сумма каждого такого куска. в этом отличие — что нужен довольно большой торрент-файл с метаданными, а не крохотная ссылка.
в результате как только кто-то скачал один из крохотных кусков — он тут же может начинать раздавать этот кусок остальным. и получаешься дашь-на-дашь, я скачал один кусок, и обмениваюсь уже не только с главным источником, но и всеми остальными качающими
UFO just landed and posted this here
Sign up to leave a comment.
О хэшах и проблеме распространения в торрентах