Несовременный BitTorrent

Длительное и достаточно активное использование файлообмена на основе протокола BitTorrent не может порой не вызывать некоторого недоумения на предмет его неудобства, непродуманности, стойкого дискомфорта при работе – особенно, когда дело касается раздачи материалов.

Исторически до выхода на большую сцену торрент-файлообмена существовали несколько файлообменных сетей, среди которых до наших дней дожили eDonkey и DC++. Однако в последних по причине централизованности установления контактов между участниками существовала серьёзная проблема очередей на доступ у раздаваемому материалу, что было неудобно. Кроме этого, в то время имели место быть невысокие скорости обмена данными – проблема, конечно, не имеющая отношения к протоколу, но в совокупности сказанное приводило к низкой интегральной эффективности существующих файлообменных сетей. В 2004-м году начал стремительно набирать обороты файлообмен на основе протокола BitTorrent, первая спецификация которого появилась тремя годами ранее. На ранних этапах это был полудецентрализованный сервис, также предполагавший обращение пользователя-получателя файла к определённым серверам – торрент-трекерам – с поисковыми запросами на наличие фрагментов принимаемого файла у других участников файлообмена. Вскоре, протокол был улучшен алгоритмами DHT (Kademlia), долгожданным PeX, превращающим протокол в по-настоящему децентрализованный, LSD и, наконец, uTP. В результате BitTorrent превратился в надёжное, стопроцентно работающее, стойкое к блокирующим действиям средство файлообмена но… суть осталась той же: BitTorrent неудобен. Протокол стал настолько популярен и широко распространён, что на фоне этой успешности пользователи перестали замечать его принципиальные недостатки, не позволящие считать его отличным средством файлообмена в современных вычислительных сетях. Итак, в чём здесь дело?

Протокол предполагает следующий подход (см. рисунок).

TorrentРисунок — Структура файлообмена в BitTorrent-сети

Обязательным является наличие файла-описателя – торрент-файла. Иногда его называют „метафайлом раздачи“. Количество информационных блоков, содержащихся в метафайле, в принципе, ничем не ограничено, но обязательным является указание:

  1. объёма и файловой структуры раздаваемого/принимаемого материала;
  2. размера и количества фрагментов раздаваемого/принимаемого материала;
  3. хеш-суммы каждого фрагмента раздаваемого/принимаемого материала.

Это так называемая „инфо-секция“ торрент файла, без знания которой нельзя начать файлообмен. Дополнительные секции могут содержать ссылки на торрент-трекеры, комментарии и пр.

Изъяны реализации протокола

1. Для отдачи/скачивания контента требуется дополнительный файл-описатель раздачи. Даже если для скачивания контента используются магнет-ссылки, всё равно они указывают не на контент, а лишь на торрент-файл.

Сказанное требует наличия некоторого централизованного сервиса, хранящего торрент-файлы всех раздач. С появлением магнет-ссылок указанный недостаток несколько сгладился, но проблема централизации осталась. Магнет-ссылки более компактны и удобны, но плохо, что это лишь ущё одно звено в цепи между получателем контента и его источником. Исключением в контексте проблем, связанных с централизацией, на данный момент является разве что Tribler.

2. Торрент-файл содержит не хеш(-и) всего файла (группы файлов), а хеши фрагментов раздаваемого материала.

Причина такой ситуации ясна: BitTorrent-протокол в целях децентрализации файлообмена предполагает раздачу материала небольшими кусочками. Но почему бы в торрент-файле не сделать обязательным ещё одно поле, содержащее хеш-сумму цельного файла или хеш-суммы всех раздаваемых файлов? Как результат: пользователь не имеет возможности быстро определить, что же реально раздаётся через данный конкретный торрент, пока не скачает материал. В данном случае остаётся лишь довериться тому централизованному сервису, с которого взят торрент-файл. Хеш-сумма, содержащаяся в магнет-ссылке в этом нисколько не помогает, так как она является результатом хеширования инфо-секции торрент-файла, но не самого раздаваемого материала.

3. Размер фрагментов раздачи могут быть произвольными и, чаще всего, находятся в пределах от 64 кБ до 16 МБ.

Как результат: для одной и ой же раздачи торрент-файлы могут быть совершенно различными, следовательно, и магнет-ссылки на них будут содержать различные хеш-суммы. При создании торрент файла каждый волен выбирать, каким будет объём фрагмента. Чаще это делает клиентская программа автоматически на основе информации об объёме раздаваемого контента, но каждый клиент делает это по-своему. Такая неопределённость и неоднозначность вносит дополнительную путаницу в процесс файлообмена. Нередки случаи, когда пользователь желает поддержать редкую раздачу, сформировав собственный метафайл на неё. Однако в силу различия в размерах фрагментов, указанных в его метафайле и метафайле, находящемся на том или ином ресурсе в открытой сети, он ничего не сможет раздать, так как технически оба торрента указывают на различные раздачи.

Изъяны реализации клиент-серверов

1. Торрент файл, загруженный в клиент-сервер, должен точно указывать на раздаваемый материал.

Изменение имени файла(-ов) или пути к раздаваемому материалу – например, при переносе в другую папку – делает раздачу неработоспособной или, что хуже, заново скачивает контент в то же самое место. Удаление материала раздачи с жёсткого диска также требует удаления метафайла из торрент-клиента. При большом количестве раздач такие манипуляции не могут не вызывать раздражения. Безусловно, некоторые клиенты – например, qBittorrent – дают возможность переименовать файлы в раздача, но делается это в ручном режиме, что нельзя назвать оптимальным решением.

2. Нет возможности открыть доступ к папаке с множеством файлов, подлежащих раздаче.

Таким образом, каждый файл, подлежащий раздаче, требует:

  • создания отдельного метафайла;
  • публикации метафайла на торрент-портале;
  • связывания сгенерированного метафайла с конкретным локальным файлом

и, наконец,

  • неусыпного контроля за торрент-клиентом и локальными файлами.

Для большого количества раздаваемого материала такая процедура разделения ресурсов чудовищна по трудоёмкости. (Хвала тем людям, которые находят время и силы для формирования и поддержания большого количества раздач, что, без сомнения, делает наш мир лучше).

3. Отсутствует возможность децентрализованного поиска файлов по имени или хеш-суммам.

Требуется постоянное обращение к торрент-порталам в Интернете для поиска желаемого материала. На фоне современных тенденций в файлообмене это выглядит нелепо. Нет доступа к порталу, где хранятся торрент-файлы, – нет контента. В свете последних тенденций это не только нерационально, но и опасно. Не зря в течение последних нескольких лет появились базы данных с хеш-суммами инфо-секций всех метафайлов, опубликованных на крупнейших порталах. Справедливости ради, следует отметить, что в некоторых клиентах имеется встроенный поиск – как в упомянутом qBittorrent, – но всё равно при осуществлении поиска обращение идёт к определённым сайтам в Интернете. Иключение среди открытых продуктов одно – Tribler.

4. Если донор и реципиент файла находятся за непрозрачными роутерами, файлообмен не состоится.

Протоколом не предусматривается решение проблемы „проброса“ портов, не привлекаются различные подходы к установлению соединения, не синтезируется соответствующая топология сети. В современных файлообменных сетях проблеме уделяется должное внимание, решения имеются и, в большинстве случаев, отдача файла(-ов) начнётся.

А какие же альтернативы? Для примера приводится полная ссылка на видеофайл в шифрованной сети RetroShare: „retroshare://file?name=Rising%20arrows%20(2010).mp4&size=75967501&hash=2d34dfbba466a9974ce49bd489f505bf904395b2“. В представленной ссылке имеется

  • имя файла – допустим поиск по имени или фрагменту имени файла, а также расширению;
  • объём файла в байтах – поиск по запросу не больше (не меньше) определённого объёма;
  • уникальная хеш-сумма файла – пользователь может её сохранить и позднее быть уверенным в том, что он качает именно тот файл, который ему нужен.

Аналогичная ссылка для сети eDonkey: „ed2k://|file|Centos-7.0-1406-x86%2064-Everything.iso|7062159360|D849C30B8D630470FB9C9F74AB11D9ED|/“. Для скачивания никаких вспомогательных файлов не требуется; доступ к ресурсам открывается целыми папками; система сама отслеживает изменения файлов в разделяемых папках.

Заключение. BitTorrent как протокол и файлообмен на его основе, возможно, неплохо адаптирован к потребителю контента, но ни в коей мере его нельзя удобным и эффективным для распространителя контента.

Материал статьи может незначительно изменяться и дополняться

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: