как правило HTTP-ссылки не прямые (rapidshare, etc), поэтому автоматически скачивать с них нельзя. а хранить их в качестве "примечания" в магнет-ссылке слишком избыточно

К фильмам и варезу такой подход мало применим, согласен.

Когда я поставил Шареазу, я впервые в жизни увидел, что магнитная ссылка может быть полноценной заменой http. Обычно либо есть, либо нет. Самому нужно проверить наличие и скачать из web, если в dc нет. А Шареаза эту байду автоматизирует. Нажал на ссылку, скачал. Также, как http. Ещё в Gnutella(2) можно &xs оставлять. В dc это может быть только хаб, что не всегда желательно. А в Gnutella это сервис, предоставляемый клиентом. Клиент (прямо как трекер) отслеживает, у кого есть копия файла и позволяет быстро найти источники. Насчёт того, что Gnutella может быть заменой DHT, я погорячился. Shareaza ищет с некоторой скоростью, и эта скорость меньше, чем миллион узлов в секунду. DHT и Kad, надо полагать, поэффективнее будут, впрочем, смотреть надо.

Я вообще считаю, GreyLink нужно влить в Шареазу. У них обоих столько плюсов, но и минусов одновременно ( http://sourceforge.net/apps/phpbb/shareaza/viewtopic.php?f=20&t=340 ).

Во всех сетях уже предусмотрен http fallback. В ed2k и в Gnutella и даже в сраном bt это есть. Shareaza вообще позиционирует себя как Интернет качалка (типа замена Download Master), и это тоже полезный юзкейс. Жалко, что в Шареазе обработка директорий ни к чёрту, так бы можно было в локалке Шареазу вместо Грея насаждать. А, может, так и сделаю.

но и скачивание тоже осуществимо. сделай, чтобы chatbot.dll отдавал информацию плагину и принимал команды.

можно просматривать списки открытых хабов, списки пользователей, поставить запрос на скачку файл-листа. получить событие завершения скачки файл-листа, открыть скачанный файл-лист в панели, послать команду на скачивание файл по magnet-ссылке

каких ещё функций не хватает в API?

Поддерживаю!!!

Предлагаю подумать о бинарном формате, возможно, сразу о двух или два в одном. При обзоре шары желательно BFS порядок. Так можно скачать небольшой сегмент бинарного файллиста и быстро получить представление о содержимом. Если же надо скачать директорию целиком, тут больше подойдёт DFS порядок. То есть, из файллиста скачиваем только тот кусок, который относится к директории, и, вуаля, сразу же получаем всю директорию.

(8g1) Допустим, будет BFS+DFS два в одном. Это значит, в файллисте полловина листа перечисляет директории в BFS порядке, другая половина перечисляет в DFS порядке. У файлов указан только TTH, у директорий — смещение в BFS половине и диапазон смещений в DFS половине.

Пока писал, подумал, что звучит это всё как–то кисло. Чего–то здесь не хватает. ИМХО файллист надо как–то сегментировать и хранить в человеческом формате. А вот как это сделать, вопрос открытый. ADC GET на одну директорию – это полезно, но не всегда.

Другие возможные схемы:
(8g2) Выводить в порядке BFS директории из корня шары, пока не наберётся 64Kb (размер можно подобрать позже; размер именно файллиста, а не файлов, им описываемых). Все папки, у которых содержимое осталось неописанным, помещаются в очередь, и с ними рекурсивно проделывается та же операция. В итоге имеем несколько файллистов. Совместимые клиенты запрашивают только те сублисты, которые им нужны.

(8g3) Либо, наоборот, в порядке DFS выводим во временный поток содержимое всех директорий. Пока идёт процесс, пытаемся превысить лимит 64Kb. Если какая–то директория на стеке полностью прочёсана, и в её файллисте набралось более 64Kb информации, файллист директории вычленяем в отдельный, оставляем в основном файллисте только ссылку, идём дальше. Ссылки тоже занимают место, так что, вполне возможно, при этом процессе будут вычленяться файллисты, ссылающиеся на файллисты.

Если размер директории превысил лимит 256Кб (вдруг там 6 невычлененных директорий по 50Kb), ищем поддиректорию с максимальным размером файллиста и вычленяем его. И так далее, пока не удастся сократить размер до 256Кб. Не факт, что это получится. Если в директории дофига файлов, сократить размер ниже некоторого предела не удастся.

Общая мысль понятна, думаю.

видимо, тормозит инсерт всех папок в TreeView. возможно, стоит слева тоже поставить ListView в виртуальном режиме, как теперь стоит на очереди скачивания (и очередь стала открываться быстрее)

в принципе, почти всё в протоколе для этого готово.
люая дира может быть помечена, как incomplete и рисоваться незагруженной.
команда ADC GET также расширяется параметрами, определяющими глубину и стратегию поиска.
(например, добавить тэг LM - limit на килобайты неполного списка)

только одна засада: хитрый запрос шары будет демаскировать версию клиента.
сейчас пока не проверяется, но вполне возможно, что в будущем клиенты типа StrongDC не будут вообще ничего отдавать, если указан неизвестный параметр ADCGET. тогда просмотр шары обламывается

можно сделать тэг в supports - но по нему тоже могут обрывать коннекты

если бинарным блобом отдавать только TTH, которые есть в шаре, этого будет полностью достаточно для добавления всех файлов юзера в источники. но увы, экономия получается небольшая: для сжатого файл-листа 1.5мб имеем 40.000 файлов. голые несжимаемые TTH весят 40000*192/8=937Kb. даже в 2 раза не экономится, не стоит заморачиваться

с другой стороны, если передавать не файл-лист и не список TTH, а bloom-хеш шары (всё равно он уже вычислен, хотя ADC-хабы так и не научились его использовать), то, при вероятности позитивной ошибки 0.1 хеш для шары в 40000 файлов займёт 24 кб (для ошибки 0.01 - 48kb). впечатляет [если я ничего не напутал в расчётах]