Комментарии 19
Мы можем стереть часть и раздавать дальшетого чего у нас нет?
Само по себе описанное — интересно. Но каково практическое применение?
Приходит на ум только на крутка раздач или доступности файла, но на трекерах счетчики остались для красоты, и былой функционал не выполняют.
Наоборот, теперь ценится наличие всех частей файла для резкого контента.
того чего у нас нет?
Остальная часть данных(не стёртая) будет раздаваться дальше.
Но каково практическое применение?
Поддержание раздачи. Естественно это нельзя делать создателю раздачи. На раздаче обязательно должны быть полные источники. В дополнение к ним частичные источники. За счёт большего количества источников будет больше скорость загрузки.
Такой метод поддержания раздачи становится более актуальном при росте размера раздач и ограниченном месте на диске.
Например BDRip может занимать до 25гигабайт при этом 20 из них это один цельный файл. Это проблема когда SSD всего на 60ГБ.
Так мы можем высвободить пару гигов и раздавать дальше.
С ходу вопрос: а торрент-клиент отследит, что вы так поступили с файлом? Или с точки зрения трекера вы останетесь seed-ом, и только когда у вас попросят фрагмент файла — дадите отлуп ("ну нет его у меня!") или, того хуже, перешлёте другому клиенту пачку нулей, от которой он посчитает хэш, отбросит и начнёт качать заново из другого источника?
Упс, перечитал пост, увидел ответ на свой вопрос. Т.е. только руками, только хардкор… Нет, такой хоккей нам не нужен. Лучше стереть одну из раздач целиком (посмотрев, по какой есть больше сидов).
Ну я надеюсь что после моего поста программисты клиентов осознают нужность данной фишки и реализуют интерфейс на пару кликов в клиенте.
Ещё можно доработать скрипт. Научить его автоматически работать с клиентом. В статье Proof of concept.
Потому, что если на раздаче уже не сильно популярного файла будет 2 десятка с фрагментами, полный файл уже не скачать.
И решить эту проблему можно будет только дополнительным протоколом между сидами, которые будут договариваться, какие части «нулить», что б при этом файл все еще можно было скачать.
PS: Что-то подобное я где-то уже встречал. Вот только где?
Можно не договариваться. Клиент видит доступность частей в рое и может стирать только самые распространённые части.
Простой пример время 10-18 доступность одна — много рабочих машин, закончилась работа, тысячи машин выключены и фрагменты недоступны.
Тут выбор между полностью уйти с раздачи удалив торрент или остаться на ней не полным источником. С этой точки зрения уход других источников не имеет значения. Поддерживаем как можем.
Есть другая проблема. Рой поддельных пиров при строгом алгоритме может заставить остальных проредить одни и теже части. Поэтому прореживание должно быть с примесью рандома.
А не просто глянет чего больше и удалит у себя.
Так поддельные пиры тоже будут участвовать в этом и смогут стереть всё. Нельзя доверять никому. Рандом наше всё))
Мы уже пришли к разработке протокола? :)
Я не против. Разрабатывайте.
С моей стороны единственное что можно добавить в протоколе BitTorrent это сообщение lost которое будет сообщать что у пира больше нет этого куска или участка. Тогда не прийдётся переподключаться после перепроверки.
Можно сделать отложенное стирание. Клиент помечает выбранные куски как удалённые и наблюдает некоторое время за роем. Если выбранные куски не стали редкими то стирает их окончательно. Иначе выбирает другие заместо редких и повторяет процедуру для них.
Есть такая штука, PAR2, думаю, как раз для таких случаев подойдёт, когда не хватает небольшого кусочка. Если сами куски стирать случайно у всех клиентов, то вероятность полного отсутствия фрагмента будет невелика, и её можно будет скомпенсировать этой информацией для восстановления.
- В qBittorent переключаемся на вкладку содержимое
- И снимаем галочку рядом с файлом чтобы он после проверки не начал загружаться заново
- Правой кнопкой мыши на раздаче вызываем контекстное меню и нажимаем пункт "Проверить принудительно"
...- Таким образом мы остались на раздаче и высвободили немного места на диске
Пришлось убрать спойлер.
Пример с фильмом не влезающим на ssd тоже выглядит неудачным. Если я хочу смотреть кино при недостатке места, я выберу стриминг. И клиент будет просто подтирать старые блоки при последовательной загрузке по мере просмотра. Точно также оставаясь на раздаче пока я смотрю. Для лучшей «поддержки» раздачи в таком случае достаточно увеличить размер буферизации поближе к свободному пространству, и бонусом — не требуется ручного шаманства с командами.
Еще наверно следует упомянуть что при недостатке места на ssd это плохо сказывается на его здоровье из-за ограниченого маневра для wear leveling, и использовать его в таких режимах не рекомендуется.
Делаем дырки в торрентах освобождая место и оставаясь на раздаче (часть 1)