HttpMagnetServer

Дата: Понедельник, 12.12.2016, 00:48 | Сообщение # 1

Подполковник

Сообщений: 115

Репутация: 12

Статус: Offline

Приветствую!

Давно хотел сделать аналог HFS для p2p. А то они могут выставлять шару в Интернет по HTTP, а мы — нет. Только отдельными магнитками делиться, либо через сервисы перенаправления http: -> magnet: , либо на сайтах, где ещё и оформить нужно прежде чем запостить. Те, кто поставил себе HFS, выбрали для себя другой путь, и нам бы тоже не помешало такое.

В HFS мне нравилось, что для любой директории можно заказать .tar или .zip. Но только с этим большая проблема — всё это не для p2p. Ни владелец сервера не может расшарить так, чтобы канал свой не проседал, ни посетитель — скачать потом с нескольких источников. Аналог HFS для p2p мог бы стать недостающим звеном.

И вот, что получилось:

HFS: http://hfs.karumo.pp.ru/
HMS: http://p2p.toom.su/fs/hms/RB4EWOJWD6WTLVGYM6G3K6Y56ZHCRMXZONSAC4A/

Вместо прямых ссылок на файлы — магнитные ссылки, а вместо .zip и .tar — .dcls.

Если шара сделана флаем, там ещё метаинформация подгружается, и получается вообще красота:
http://p2p.toom.su/fs....7%D0%B8

Такое можно кинуть своим непродвинутым друзьям в соцсети, а то они на описание торрентов по HTTP посмотреть могут, на FTP могут зайти браузером, на HFS — тоже, а для DC++ такого не было.

Ещё я давно сильно хотел как-то поспособствовать внедрению TTH в торренты. Спека на это дело была опубликована ещё в 2006м, но поддержка так и остаётся непростительно слабой. Такие торренты умеет генерить TorrentBuild, а качать умеет только Shareaza, но только для случая торрента из одного файла. В принципе, даже и это — уже немало. Можно было бы сделать утилитки, конвертирующие .torrent в .dcls и открывать в DC++ клиенте как обычно. Можно было бы на сайтах, куда выгружаются торренты, проверять наличие TTH, и если нет, ругаться или вообще отправлять переделывать торрент, а после того, как торрент получен, вытаскивать TTH и отображать магнитные ссылки на сайте, а может быть, даже и dcls создавать. В краткосрочной перспективе это дало бы возможность качать из любой сети и быть взаимополезными. В долгосрочной перспективе — сами торрент-клиенты научились бы поддерживать TTH, и чёткой границы уже не было бы.

Далее, вот я наблюдаю такую ситуацию, что если ищешь что-нибудь в Nigma, то она предательски предлагает добавить к запросу «торрент», а dcls, допустим, не предлагает. И вообще, это как «памперс», уже не бренд, не точное указание протокола, а способ обращения с информацией. Кстати, в оригинале «торрент» — это поток, так что почему бы и нет. BitTorrent — это торрент, и DC++ — это торрент, и Shareaza — это торрент.

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

GreyLink DC++ слился, но знамя гибридизации недавно подхватил FlyLink DC++, и я не проверял, но меня терзают смутные сомнения, что TTH в торрентах HMS он не увидит. А я бы скорее ожидал поддержку TTH в торрентах там, чем в оригинальных торрент-клиентах.

В-четвёртых, актуализирую понимание ущербности подхода info.pieces по сравнению с пофайловым TTH. Изначально я хотел вообще не класть info.pieces, и думал, что клиенты покажут что-нибудь вроде «невозможно скачать файл» или «невозможно проверить файл», но при этом можно будет посмотреть список файлов, их размеры, а также комментарий, в котором сказано, что требуется поддержка TTH в торренте. Практика показала, что нет, вообще не открываются такие файлы. Нормальный info.pieces для чужих многотерабайтных шар, а также для каждой поддиректории, естественно, HMS не может вычислить, так что пришлось научить его делать фейковый info.pieces, просто чтоб люди скачивали торренты и видели комментарий.

На всякий случай пометил это флагом info.nopieces. Гипотетический клиент, поддерживающий оба способа верификации файла, должен будет отключить проверку архаичным методом при обнаружении этого флага. В принципе, ничего особенного в том, чтобы HMS генерировал фейковый info.pieces, нет. Если клиент не поддерживает TTH, какая разница, что написано в info.pieces? Он всё равно не скачает. Люди вставшие на раздачу разных поддиректорий или хоть немного изменившихся версий одной директории, в BitTorrent уже не найдут друг друга, а если они-таки нашли, то скорее всего предприняли для этого специальные действия, а если они готовы прикладывать усилия к обнаружению друг друга, то им проще поставить DC++ или добиться от разработчиков поддержки пофайлового TTH с возможностью поиска в сети по TTH. Вот если торрент делает человек, тогда да, пока что придётся с этим info.pieces жить, а стимуляцию к переходу осуществлять через отбривание на трекер-порталах торрентов без TTH.

Встречались мне среди апологетов BitTorrent умники, которым никак не доказать превосходство TTH. Текстом, видимо, плохо доходит. Вот теперь этим умникам задачка. Если они такие умные, пусть попробуют сделать аналог HMS. Мы вот у себя благодаря TTH можем всяко-разно обрабатывать директории, склеивать, редактировать их, и DC++ всё скачает. В частности, HMS может извлечь описание любой поддиректории. И DC++ всё скачает. А у вас?

Теперь плохие новости

Из-за ошибки в DC++ dcls не работает тоже, и это печаль великая для меня как грейлинковода, потому что так оно, похоже, там и останется. Суть в чём: перепаковывать bzip2 на веб-сервере, когда он под несколько мегабайт, напряжно для процессора. Генерить для каждой поддиректории — напряжно по месту на жёстком диске. Вот у меня шара запакованная — 3.1 Мб, распакованная — 12 Мб, а если запакованных сгенерить для каждой поддиректории, то будет 21 Мб, что не очень здорово, если хочется захостить как можно больше шар.

Мне пришла в голову идея, я провёл эксперимент, и оказалось, что, действительно, склеенные bzip2 файлы распаковываются в склеенные распакованные. Идея в том, что я генерю xml.bz2, вокруг каждого тега <Directory /> перезапускаю сжатие bzip2 и запоминаю смещения начала и конца. Получается bzip2-франкенштейн, подготовленный к дальнейшим хирургическим вмешательствам. Размер из-за постоянных перезапусков сжатия увеличивается до 5,1 Мб, что всё же лучше, чем 21 Мб.

Потом веб-сервер берёт этот файл и виртуально склеивает вместе пролог, описание директории и эпилог, всё в сжатом виде, и не напрягаясь, даёт скачать. Я экспериментировал с обычным bunzip2 и с FAR Manager, для них такой франкенштейновый dcls вполне себе нормален, но только не для GreyLink DC++. Там, похоже, конец потока средствами Bzip2 принимается слишком близко к сердцу. Возьмите сами посмотрите любой файлик. В сжатом виде там внутри постоянно заголовки BZ, а в разжатом получается нормальный XML. И можно даже переупаковать bzip2, после этого оно откроется в DC++. Пока ошибку не исправят, так, похоже, и придётся делать.

Кстати, это не только на веб-сервере, но и в DC++ для частичных списков было бы полезно. Сейчас либо полный список файлов можно скачать, либо неполный, но тогда там без поддиректорий. А можно было бы по той же методе в самом DC++ получать полное описание любой поддиректории.

Торрент для любой поддиректории, кстати, тоже реализован по такому же принципу, только там сжатия нет, поэтому ничего необычного. Впрочем, один важный эффект всё же проявляется. В dcls директории один раз именуются атрибутом Name тега Directory, а в torrent info.files.path — каждый файл заново перечисляет полный путь. Поэтому после хирургических операций в dcls остаётся только запрошенная папка (и только табуляция выдаёт подвох), а в torrent — куча взаимовложенных папок, ведущих к запрошенной.

Так что в HMS ни dcls, ни torrent к существующим программам не подходят. Только магнитные ссылки. Мы опережаем прогресс.

Сам HMS я пока не опубликовал. Мне чтоб отрезать его от Тум Су, надо будет потратить какое-то время. Но я могу пока выставить ещё чью-нибудь шару.

Вообще, там две части, одна читает XML и генерит кучу файлов (а ещё умеет вытаскивать значки из обычной HFS), а вторая часть — это веб-сервер, который знает, что с этими файлами потом делать. Резать придётся только вторую. Как минимум, я бы хотел быть уверен, что это кому-нибудь интересно.