Comments 62
Еще в школе недоумевал, зачем файлообменной сети чат и наоборот (тем, кто шарил весь диск C: лишь бы пускало на хабы пообщаться).
Конкуренция. В браузере Opera на движке Presto ведь тоже был свой торрент-клиент, которым мало кто пользовался.
Вот так выглядит облом в BitTorrent. Это я искал редкие файлы (среди которых основной — OEDev.zip) всякими разными способами, и когда нашёл, решил раздать во все сети, где я раньше тщетно пытался найти. Этот торрент давно без сидов, а вот один пир ну очень долго тусовался, но выкачать OEDev.zip целиком так и не смог, потому что его начало в одном куске с другим файлом, которого у меня нет. И никак. И чата нет, чтоб как–то по–другому файл передать. Смотрим друга на друга, немые, как рыбы.
А могу рассказать ещё одну замечательную историю. Как это обычно бывает в торрентах, четвёртый год пытаюсь скачать 6AE765434DEB78AB7CBDA3AAC869363E81046348. Когда мне админ одного сайта передал-таки один из файликов, я решил, а не раздать ли тоже хоть часть файлика. Правда, человек, который создавал торрент, запаковал каждый файл в торренте в отдельный rar, ну а я, конечно, не угадаю, как в этот rar запаковать, чтоб так же было. И тоже смотрим молча друг на друга.
В самом деле, хорошо, что чата нет! Просто замечательно!
Плохая фича, непродуманная.
Суть не столько в том, чтобы почитать описание фильма вообще (это можно на кинопоиске сделать), сколько описание конретной раздачи с конкретных хешем. Кто мешает к TTH экранки дописать ссылку на обсуждение BD-RIP? И не специально так будут делать, а просто нашли подходящую тему — прилепили её к ссылке.
В-общем, не вижу никакого особенного прогресса. Никто не мешал скидывать в чат magnet+ссылку по отдельности. Просто некоторое удобство управления ссылками, right-click + copy, вместо выделения куска с magnet и ссылкой + copy. Тогда давайте краткую аннотацию и год выхода материала тоже писать в magnet (в base64). Удобно же — из магнета сразу можно прочитать, не надо открывать поисковик.
Суть не столько в том, чтобы почитать описание фильма вообще (это можно на кинопоиске сделать), сколько описание конретной раздачи с конкретных хешем. Кто мешает к TTH экранки дописать ссылку на обсуждение BD-RIP? И не специально так будут делать, а просто нашли подходящую тему — прилепили её к ссылке.
В-общем, не вижу никакого особенного прогресса. Никто не мешал скидывать в чат magnet+ссылку по отдельности. Просто некоторое удобство управления ссылками, right-click + copy, вместо выделения куска с magnet и ссылкой + copy. Тогда давайте краткую аннотацию и год выхода материала тоже писать в magnet (в base64). Удобно же — из магнета сразу можно прочитать, не надо открывать поисковик.
Кто мешает к TTH экранки дописать ссылку на обсуждение BD-RIP?зачем? админ хаба может забанить такого юзера сразу после первых жалоб других пользователей о не соответствии содержимого двух ссылок в чате.
В-общем, не вижу никакого особенного прогресса. Никто не мешал скидывать в чат magnet+ссылку по отдельности. Просто некоторое удобство управления ссылками, right-click + copy, вместо выделения куска с magnet и ссылкой + copy.так и есть
Тогда давайте краткую аннотацию и год выхода материала тоже писать в magnet (в base64). Удобно же — из магнета сразу можно прочитать, не надо открывать поисковик.зачем? Когда можно как в торрент файле по аналогии вписать эти и другие параметры — и всё это называется dcls файл.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<FileListing Version="2" CID="42PRTX54SCGRDWZ3N6K3TZ5CCTEGZ6LH5DHFQRY" Generator="DC++ 0.785" IncludeSelf="1">
<Directory Name="BBC">
<File Name="80_Chudes_Sveta_Part_IV_CD2.avi" Size="731826630" TTH="4J5Z4PQYYBTZ2HIQGTPVKS6R7P322AJ35ISJH3Q" TS="1331132829" BR="128" WH="672x368" MA="59mn 10s | MPEG , 128 Kbps, 2 channels, = | MPEG , 128 Kbps, 2 channels" MV="MPEG-4 , 1 379 Kbps, 16:9, 25.000 fps"/>
<File Name="80_Chudes_Sveta_Part_IV_CD1.avi" Size="731828818" TTH="2772VTZAB3DJB7HUTV6WF4DQZSFG7K3TMSZ4IIA" TS="1331132829" BR="128" WH="672x368" MA="59mn 12s | MPEG , 128 Kbps, 2 channels, = | MPEG , 128 Kbps, 2 channels" MV="MPEG-4 , 1 378 Kbps, 16:9, 25.000 fps"/>
</Directory>
</FileListing>
А в результатах поиска передаётся?
Нет, к сожалению, а может и к счастью. Если представить, что по нажатому магнету у пользователя создавалась бы запись вида TTH+http и потом выводилась другим пользователям при поисковом запросе, получится ситуация с огромным числом старых неработающих битых ссылок, некоторые юзеры могут начать рекламировать свои сайты и самих себя, распространять ссылки на вирусы и пр. Другими словами полное отсутствие контроля и модерации.
Я пишу программу, которая иногда получает файлы из p2p сети. Так вот когда выбирал из какой сети она будет брать файлы понял, что в торрентах совсем нет поиска, встроенного в протокол. Т.е. там есть поиск по хэшу торрент файла (самого .torrent файла) или по хэшу частей содержимого, но не самого искомого файла. Парсить веб страницы для меня выглядит очень уродливо. Даже получение результатов поиска через api какого-либо сервиса — выглядит убогостью по сравнению с тем что есть в DC++.
В DC++ это всё в текстовом виде. Поиск встроен в протокол. TTH — одна из лучших реализаций хэша. Подключиться к хабу и качать файлы можно даже через telnet! Как разработчик я доволен. И для меня это жирный минус торрентам в перспективе.
В DC++ это всё в текстовом виде. Поиск встроен в протокол. TTH — одна из лучших реализаций хэша. Подключиться к хабу и качать файлы можно даже через telnet! Как разработчик я доволен. И для меня это жирный минус торрентам в перспективе.
Оцените тогда и Gnutella2. Качаются файлы по HTTP протоколу. Поиск глобальный по именам и хешам и другим параметрам. Описание и рейтинг файла также передаются в результатах поиска.
В Gnutella2 гениальный компактный формат пакетов, позволяющий очень гибко и неограниченно расширять функционал. Но при этом слабая документация, многие фишки совсем не документированы, можно только из исходников понять принцип действия. HTTP там весьма условный, оно поверх HTTP работает для обхода файрволов. Оптимальным является UDP.
Что касается поиска — это сложная тема, там многоуровневый поиск. Раньше искали как в DC++, спрашивая всех участников. Сейчас появились ультра ноды, которые по сути трекеры.
Что касается поиска — это сложная тема, там многоуровневый поиск. Раньше искали как в DC++, спрашивая всех участников. Сейчас появились ультра ноды, которые по сути трекеры.
посмотрел Gnutella2. Недостатки:
низкая распространённость
Что бы поискать файл нужно установить несколько соединений. Т.е. сначала получить список хабов. Потом соединиться с парой… и уже после этого начать поиск… Причём поиск будет длиться неизвестно сколько! Так как происходит опрос по какой-то сложной логике…
В DC++ я соединяюсь один раз с хабом. Поиск происходит максимально быстро т.к. я получаю ответы от самих клиентов в общем чате. Никаких списков при этом мне не нужно знать… тупо подключился… кинул поиск… отпарсил ответы… подключаюсь напрямую и качаю… что может быть лучше???
Ну и разные прибамбасы лишние Gnutella2 — это кадры, комменты…
Недостатки я копнул поверхностно… но мне их уже хватает что бы не работать с этим протоколом.
А в dc++ я бы общий чат хаба перевёл на xml. Так парсинг и поиск ускорился бы вдвое… если не в 10 раз))
Вот и всё.
низкая распространённость
Что бы поискать файл нужно установить несколько соединений. Т.е. сначала получить список хабов. Потом соединиться с парой… и уже после этого начать поиск… Причём поиск будет длиться неизвестно сколько! Так как происходит опрос по какой-то сложной логике…
В DC++ я соединяюсь один раз с хабом. Поиск происходит максимально быстро т.к. я получаю ответы от самих клиентов в общем чате. Никаких списков при этом мне не нужно знать… тупо подключился… кинул поиск… отпарсил ответы… подключаюсь напрямую и качаю… что может быть лучше???
Ну и разные прибамбасы лишние Gnutella2 — это кадры, комменты…
Недостатки я копнул поверхностно… но мне их уже хватает что бы не работать с этим протоколом.
А в dc++ я бы общий чат хаба перевёл на xml. Так парсинг и поиск ускорился бы вдвое… если не в 10 раз))
Вот и всё.
Не совсем так. В DC++ чтобы произвести поиск нужно подключиться к хабу. Зачастую, для использования поиска необходимо предварительно зарегистрироваться на хабе, что добавляет некоторого гемора. Кроме того, поиск производится по тем клиентам, что сейчас подключены к хабу. Далее, из свой практики, могу сказать, что для комфортного пользования необходимо сразу одновременно подключаться к 5-10 крупнейшим хабам. При этом на каждом свои правила регистрации и поиска. Но зато результативность поиска выше. Жаль, что между хабами нет межхабовой связи. Чтобы подключившись к одному — была доступна вся сеть и все юзеры. Это недостатки DC++.
А еще и мутная реализация протокола с входящим/исходящим траффиком, пробросом портов и т.п. В торрентах все как-то проще.
А еще и мутная реализация протокола с входящим/исходящим траффиком, пробросом портов и т.п. В торрентах все как-то проще.
В dc++ есть DHT. не хватает только текстового поиска по DHT-сети, сейчас ищет только TTH.
вот я говорю про конкретно то что у меня получилось сделать. У меня получилось подключиться к любому крупнейшему хабу и отправив поисковой запрос без регистрации получить ответы… и даже имея глубоко серый ip адрес открыть соединение и скачать нужный файл с пользователей, без каких-либо ограничений и с максимальной скоростью.
А если меж хабами была какая-то связь, то предполагаю забаненый человек на одном хабе становился забаненным на всех. Что мешает это сделать? Собственно и сейчас ничего не мешает доработать ПО хабов, для авторизации на других хабах и получения информации… но видимо разработчики думают о свободе распространения информации больше, чем о выдаче в поиске. И они правильно делают! Мне как разработчику крайне неудобно ждать по 30 секунд ответа других хабов. В текущем хабе результаты выдаются практически сразу. 300мс — 1,5с. задержка. И это комфортно. А к каким хабам подключиться — это моё дело.
Кстати автоматизировать регистрацию на хабах тоже проще простого. Но и без этого всё работает!
Всё я это к тому что DC++ (nmdc) можно использовать, как CDN! причём, если правильно написать реализацию, то получится даже круче по пропускной способности.
Ничего мутного в протоколе нет, если найти нормальную вики. Я разобрался за пару дней и теперь могу качать файлы хоть через telnet)))
А если меж хабами была какая-то связь, то предполагаю забаненый человек на одном хабе становился забаненным на всех. Что мешает это сделать? Собственно и сейчас ничего не мешает доработать ПО хабов, для авторизации на других хабах и получения информации… но видимо разработчики думают о свободе распространения информации больше, чем о выдаче в поиске. И они правильно делают! Мне как разработчику крайне неудобно ждать по 30 секунд ответа других хабов. В текущем хабе результаты выдаются практически сразу. 300мс — 1,5с. задержка. И это комфортно. А к каким хабам подключиться — это моё дело.
Кстати автоматизировать регистрацию на хабах тоже проще простого. Но и без этого всё работает!
Всё я это к тому что DC++ (nmdc) можно использовать, как CDN! причём, если правильно написать реализацию, то получится даже круче по пропускной способности.
Ничего мутного в протоколе нет, если найти нормальную вики. Я разобрался за пару дней и теперь могу качать файлы хоть через telnet)))
Ваше исследование достойно уважения, однако, не могу согласиться с некоторыми Вашими утверждениями:
Странно. Большая часть хабов из первой двадцатки не разрешает поиск без регистрации. По крайней мере так было года 2 назад.
С этим тоже (м.б. было) все непросто. В DC есть три режима своего соединения: типа прямой, через роутер с пробросом и «пассивный» за фаером. В третьем режиме не со всех можно качать и есть прочие ограничения.
«Это фантастика». Я имея 30МБ канал и одновременное подключение к 10 хабам — результаты поиска получаю в течение 30-60 секунд, пока от всех придут ответы. И это нормально. Плюс, на многих хабах ограничение между поисковыми запросами от 20 до 120 секунд.
ИМХО, это вообще не должно парить людей. Подключился к любому первому попавшемуся — и тебе доступна вся сеть. Может, не с мгновенными ответами. Но я предпочту поиск в течение 5 минут, чем сеть, ограниченную одним хабом. И это логично.
Не работает (или не работало). Регистрация — это ненужный рудимент, мешающий людям. Но ее зачем-то упорно делают. Если не хочешь общаться в чате, то подключайся, качай, раздавай, ищи без регистрации. Это же логично. Но ведь нет. Причем, этот идиотизм присутствует на большинстве форумов и сайтов, когда чтобы скачать приаттаченный файл я должен зарегаться. Ну зарегаюсь, потрачу время, скачаю и забуду про это форум. И будет фантомный юзер в базе висеть. Ну нафига так делать? Однако ж факт…
У меня получилось подключиться к любому крупнейшему хабу и отправив поисковой запрос без регистрации получить ответы
Странно. Большая часть хабов из первой двадцатки не разрешает поиск без регистрации. По крайней мере так было года 2 назад.
и даже имея глубоко серый ip адрес открыть соединение и скачать нужный файл с пользователей, без каких-либо ограничений и с максимальной скоростью
С этим тоже (м.б. было) все непросто. В DC есть три режима своего соединения: типа прямой, через роутер с пробросом и «пассивный» за фаером. В третьем режиме не со всех можно качать и есть прочие ограничения.
крайне неудобно ждать по 30 секунд ответа других хабов. В текущем хабе результаты выдаются практически сразу. 300мс — 1,5с. задержка.
«Это фантастика». Я имея 30МБ канал и одновременное подключение к 10 хабам — результаты поиска получаю в течение 30-60 секунд, пока от всех придут ответы. И это нормально. Плюс, на многих хабах ограничение между поисковыми запросами от 20 до 120 секунд.
А к каким хабам подключиться — это моё дело.
ИМХО, это вообще не должно парить людей. Подключился к любому первому попавшемуся — и тебе доступна вся сеть. Может, не с мгновенными ответами. Но я предпочту поиск в течение 5 минут, чем сеть, ограниченную одним хабом. И это логично.
Кстати автоматизировать регистрацию на хабах тоже проще простого. Но и без этого всё работает!
Не работает (или не работало). Регистрация — это ненужный рудимент, мешающий людям. Но ее зачем-то упорно делают. Если не хочешь общаться в чате, то подключайся, качай, раздавай, ищи без регистрации. Это же логично. Но ведь нет. Причем, этот идиотизм присутствует на большинстве форумов и сайтов, когда чтобы скачать приаттаченный файл я должен зарегаться. Ну зарегаюсь, потрачу время, скачаю и забуду про это форум. И будет фантомный юзер в базе висеть. Ну нафига так делать? Однако ж факт…
Да что говорить. У меня есть программа, которая делает то о чём я говорю.
Вот github.com/master255/ImmortalPlayer
30 секунд ожидание — это для того что бы собрать как можно больше ответов. Что бы ответы не накладывались друг на друга. А не для того что бы ждать пока там ответят. Первые ответы прилетают сразу.
Моя программа авторизуется и воспроизводит видео прямо от пользователей из поиска. Причём, сразу… без задержек. Если имя занято, то к имени прибавляется номер. И так несколько раз. Я разобрался в протоколе NMDC, а вы разобрались, что бы что-то утверждать?
Вот github.com/master255/ImmortalPlayer
30 секунд ожидание — это для того что бы собрать как можно больше ответов. Что бы ответы не накладывались друг на друга. А не для того что бы ждать пока там ответят. Первые ответы прилетают сразу.
Моя программа авторизуется и воспроизводит видео прямо от пользователей из поиска. Причём, сразу… без задержек. Если имя занято, то к имени прибавляется номер. И так несколько раз. Я разобрался в протоколе NMDC, а вы разобрались, что бы что-то утверждать?
Нет повода не верить Вам на слово. Я лишь рассказываю что сам видел.
Да, первые ответы прилетают сразу. Остальные потом подтягиваются, видимо у всех скорость и загруженность разная.
Т.е. Вы хотите сказать, что отсутствие регистрации Вам не помеха в поиске? Хм. Может это фича такая? И она зарублена в клиенте?
Я сейчас навскидку не помню какие хабы требовали регистрацию, но Вы можете попробовать на первой десятке крупнейших хабов такой поиск? Точно помню что там были такие, что поиск без регистрации не давали.
Да, первые ответы прилетают сразу. Остальные потом подтягиваются, видимо у всех скорость и загруженность разная.
Т.е. Вы хотите сказать, что отсутствие регистрации Вам не помеха в поиске? Хм. Может это фича такая? И она зарублена в клиенте?
Я сейчас навскидку не помню какие хабы требовали регистрацию, но Вы можете попробовать на первой десятке крупнейших хабов такой поиск? Точно помню что там были такие, что поиск без регистрации не давали.
ну есть наверное такие. Но в моей программе хабы можно будет выбирать и я пропишу туда нормальные хабы наверное… а не с регистрацией.
Клиент моей программы — это чат бот. И там никаких фич не зарублено. Он просто и быстро качает файлы без помех!
Клиент моей программы — это чат бот. И там никаких фич не зарублено. Он просто и быстро качает файлы без помех!
Все понятно. Но заморочка в реализации самой технологии. Для того, чтобы поискать что-то — надо подключиться к хабу. И Вам будут доступны результаты лишь пользователей этого хаба, а не всей DC сети. Для того, чтобы охватить поиском побольше аудиторию — подключаюсь сразу к первой десятке крупнейших хабов.
В случае, если вам ответил поиск, то вы знаете хеш и знаете несколько юзеров. И тут другая ситуация — вы можете далее строить DHT сеть и искать файлы, хеши которых вам известны.
Но сначала то надо опросить несколько хабов. А на крупнейшей десятке сидит подавляющее большинство юзеров сети. А некоторые из них мутят с регистрацией и прочими заморочками. Вот как-то так.
Поэтому выбирать какой-то один хаб, как и пропускать неудобные — уменьшать себе результаты поиска.
В случае, если вам ответил поиск, то вы знаете хеш и знаете несколько юзеров. И тут другая ситуация — вы можете далее строить DHT сеть и искать файлы, хеши которых вам известны.
Но сначала то надо опросить несколько хабов. А на крупнейшей десятке сидит подавляющее большинство юзеров сети. А некоторые из них мутят с регистрацией и прочими заморочками. Вот как-то так.
Поэтому выбирать какой-то один хаб, как и пропускать неудобные — уменьшать себе результаты поиска.
вы не правы.
Одно дело я отправил поиск хабу, а он пересылает другим и другим и ждёт ответы…
Не знаю как там это реализовано, но сами подумайте — загруженный хаб пересылает другому хабу — тот пользователям и другим хабам… Какая будет скорость первого ответа???
Или я подключён к 3 хабам в которых много петабайт данных. Задаю запрос… и сразу получаю от всех трёх ответы. Ясно и понятно.
А в вашей взаимосвязанной сети нет децентрализации. Рухнет связующий хаб и не будет связи между сегментами сети. И быть подключенным к 100 хабам — это всего лишь держать открыто 100 портов. Парсить поступающие данные не обязательно! Только приветствие и всё. А это быстро и одновременно можно делать.
К тому же я пишу программу не для вашей страны, а на весь мир. А это значит должен быть выбор у пользователя.
И программа будет не только получать данные, но и отдавать. Это значит нужно что бы все сидели примерно в одном хабе, а не в сети хабов. DHT — это уже следующий шаг. Я ещё не дошёл.
Результаты поиска будут скорей всего состоять из пользователей программы. Так что точно не интересует ваша гнутелла.
Одно дело я отправил поиск хабу, а он пересылает другим и другим и ждёт ответы…
Не знаю как там это реализовано, но сами подумайте — загруженный хаб пересылает другому хабу — тот пользователям и другим хабам… Какая будет скорость первого ответа???
Или я подключён к 3 хабам в которых много петабайт данных. Задаю запрос… и сразу получаю от всех трёх ответы. Ясно и понятно.
А в вашей взаимосвязанной сети нет децентрализации. Рухнет связующий хаб и не будет связи между сегментами сети. И быть подключенным к 100 хабам — это всего лишь держать открыто 100 портов. Парсить поступающие данные не обязательно! Только приветствие и всё. А это быстро и одновременно можно делать.
К тому же я пишу программу не для вашей страны, а на весь мир. А это значит должен быть выбор у пользователя.
И программа будет не только получать данные, но и отдавать. Это значит нужно что бы все сидели примерно в одном хабе, а не в сети хабов. DHT — это уже следующий шаг. Я ещё не дошёл.
Результаты поиска будут скорей всего состоять из пользователей программы. Так что точно не интересует ваша гнутелла.
Поиск в Gnutella2 производится также как в DC. Т.е. каждому хабу отправляется поисковой запрос. Хаб рассылает его клиентам. Клиенты возвращают результаты напрямую по UDP запросившему либо хабу к которому он подключен. Для того чтобы не опрашивать поисковым запросом всю сеть а ограничится только теми пирами у которых возможно есть то что вы ищете существует Query Hash Table.
в чём тогда разница с DC++? Зачем нам нужен второй такой же протокол? Но менее распространённый.
Поиск глобальный по имени и хешу. Протокол передачи файлов(HTTP) совместим с обычным браузером/сервером. Сеть полностью децентрализованная. Хабы сети это такие же клиенты и если ресурсов достаточно клиент переключается в режим хаба. Сеть будет работать до отключения последнего клиента. Соответственно устойчива к отключениям и выносам серверов. Режим хаба можно включить форсированно но не рекомендуется. Недавно я скорректировал чувствительность к старению кеша сделав клиент более автономным.
в какое время прилетает первый ответ на поиск?
Думаю не сложно будет оптимизировать мою программу и под этот протокол
Думаю не сложно будет оптимизировать мою программу и под этот протокол
Около секунды. Но это на самом популярном файле. Естественно редкие файлы долго ищет. Ну и как у DC качество поиска зависит от открытости портов.
почему редкие файлы долго ищет? Дальше лежат?)). По какому принципу долго ищет?
Клиент постепенно опрашивает хабы на которых возможно есть искомые файлы. Поэтому долго.
по какому принципу? Подсоединяется и ищет или сразу подсоединяется ко всем и ищет? Или как?
Просто опрашивает хабы и кластеры по очереди по UDP.
Первым пакетом клиент получает ключь для поиска.
Вторым пакетом отправляет поисковой запрос с полученным ключем.
От хаба прилетает список хабов к которым улетела копия запроса клиента + список хабов которые можно опросить.
От подключенных к опрошенным хабам клиентов прилетают результаты поиска.
Первым пакетом клиент получает ключь для поиска.
Вторым пакетом отправляет поисковой запрос с полученным ключем.
От хаба прилетает список хабов к которым улетела копия запроса клиента + список хабов которые можно опросить.
От подключенных к опрошенным хабам клиентов прилетают результаты поиска.
Вообще, я не следил за состоянием, может, что-то и исправили, но вот какие отличия увидел на примере Shareaza:
DC++ наиболее близок к старому доброму FTP. Он отлично передаёт все нюансы структурированной файловой системы. Скажем, в торренте нельзя описать пустую папку, а в dcls — можно. Были ещё детские болезни вроде «не качать пустой файл» (подразумевается, что и не создавать тоже) и «не качать совпадающие файлы» (подразумевается, что и не копировать из шары тоже), нарушающие целостность директорий по сравнению с эталонным FTP, но ими DC++ клиенты переболели лет 8 как.
Что касается Shareaza, то там структура в скачанных списках файлов реализована очень своеобразно, я когда первый раз увидел, просто в осадок выпал. Там дерево папок ведёт себя как фильтр файлов. Я выбрал папку и увидел все файлы из подпапок поскиданными в одно место. Я скачал, и действительно, там вся структура папок сплющилась. В Gnutella1 с директориями всё было плохо, их не было, но G2, такое чувство, что этой детской болезнью до конца не переболела. Мне что, вручную воссоздавать директории? F7, Shift-F6, F7, Shift-F6, я правильно понимаю? Это я вот этим должен заниматься?
Далее, вот есть dcls для многофайловых раздач, а в Shareaza для этого есть коллекции. Только я что-то не увидел в wiki, как там дела с поддиректориями. Они вообще есть? Я вот подозреваю, что нет. И раз уж DC++ застолбил этот формат, будет логично, если Shareaza поддержит dcls, чтоб по нескольку раз не напрягаться для разных клиентов. Хотя это и не оформленная раздача, как в Shareaza.
Кроме того, я наблюдаю, что DC++ совершенно нормально обрабатывает мои многотысячные списки файлов, со всякими Platform SDK незапакованными. А у других видел и под миллион. В DC++ оптимальнее не запаковывать, чтобы общие файлы находились. Platform SDK, MSDN Library разных версий — они во многом повторяются по файлам. А Shareaza, наоборот, с каждым новым файлом начинает корчиться в муках и корчить в муках мой ноут. Что ещё хуже, если Shareaza вдруг ненароком увидела всю бездну файлов DC++, шокирована она будет навсегда. Хоть там убрать шокирующую папку из базы, хоть базу средствами программы почистить, всё равно мегатормоза. Только вручную если поудалять базу данных и заново расшарить, помогает. Получается, наоборот, оптимальнее упаковывать файлы в архивы, но тогда поиск альтернативных источников — до свиданья, и это получается как ещё один торрент, где владельцы идентичных файлов как в кромешной тьме и не могут друг друга найти. А мне с одним торрентом уже хватает головной боли. Это уже исправлено?
А ещё я считаю нормальным не иметь вычисленный sha1. Когда p2p только зарождался, разработчики делали proof of concept, были довольно наивными, а для наивного человека нормально полагать, что можно с 20и источников скачать файл общим размером 20Гб, и потом просто в дежурном режиме проверить SHA1 от 20Гб, и ни у кого клиент не сглючит, никто не обманет, хеш сойдётся. По идее, эта наивность должна остаться в далёком прошлом, вместе с SHA1, MD5 и всеми остальными недревовидными хешами, когда пошли жалобы «моя закачка начинается снова и снова, что делать?». Зачем вообще вычислять недревовидные хеши? Они же бесполезны. А если я на сервере хотел бы сгенерить коллекцию Shareaza, и у меня есть имя, размер, TTH, и больше ничего нет? Что, смогу я это сделать или нет? А вот по магнитной ссылке с TTH загрузка файла может начаться? Там в протоколе уже по чистому TTH закачка инициируется или всё ещё надо сначала ненужный SHA1 получить?
А так, в принципе, если бы DC++ расширить Gnutella2, это было бы хорошо. Стронговская DHT мне не понравилась, в Shareaza глобализация явно лучше. Только со спамом беда. На DC++ хабах спамераста можно выпнуть с хаба, а в Gnutella2 выпнуть некому, а было бы нелишне иметь небольшой контроль. Что-то вроде подсети Gnutella2, где каждый участник получил криптографическое подтверждение на право присутствия в хабе. И сообщения от хаба нумеровать серийными номерами, подписывать и через узлы оптимально распространять.
Возвращаясь к вопросу об оформлении, это сложный вопрос, выходящий за рамки проблем p2p. У нас есть отличный блог-редактор Windows Live Writer и протоколы XML-RPC, по которым он работает, но нет застывшего в файле аналога XML-RPC, чтоб как в Word, HTML с картинками содержал. Если мне по работе нужно было запостить на два наших сайта, я делаю пост в WLW, переключаю учётку и делаю ещё раз пост. А если репост с ненашего сайта — я шёл выколупывать с того сайта картинки по одной. А новостей может быть по 10 в день, в каждой по 5 картинок. Если новый пост пишу не я, а журналисты, отправляя друг другу на проверку и переделку, что чаще всего, то писать его будут не в WLW, потому что в нём нет файлов, а в Word, где файлы есть, но потом каждый раз в HTML переделывать надо из-за разной вёрстки. Знали бы вы, какой геморрой так каждый день. А всё потому что нет формата застывшего XML-RPC с вменяемым редактором для него. WLW не может ни сохранить в файл, ни открыть из файла, а если ковырять, то там какой-то вообще левый формат wpost Compound Document, который было бы сложно парсить и генерить на сервере. Другие HTML редакторы не аналогичны Word, в смысле, не умеют положить картинку внутрь общего файла. У Mozilla какой-то HTML редактор картинки кладёт в data URI, что для многих и без того непростых HTML парсеров на сервере стало бы серьёзным испытанием, когда картинки под мегабайты. Последний SAX парсер, которым я пользовался, не позволял читать атрибуты по 8К блокам, а возвращал их все сразу. С точки зрения формата идеально устроен WizHtmlEditor, там всё как надо, формат .zip, а в нём HTML с картинками, но сам редактор топорный до безумия, там даже картинку разместить с обтеканием без залезания в HTML код не получится. И XML-RPC нет. Непаханное поле, и вот кто это поле вспахал бы, заодно и с форматом p2p раздач вопрос решил.
DC++ наиболее близок к старому доброму FTP. Он отлично передаёт все нюансы структурированной файловой системы. Скажем, в торренте нельзя описать пустую папку, а в dcls — можно. Были ещё детские болезни вроде «не качать пустой файл» (подразумевается, что и не создавать тоже) и «не качать совпадающие файлы» (подразумевается, что и не копировать из шары тоже), нарушающие целостность директорий по сравнению с эталонным FTP, но ими DC++ клиенты переболели лет 8 как.
Что касается Shareaza, то там структура в скачанных списках файлов реализована очень своеобразно, я когда первый раз увидел, просто в осадок выпал. Там дерево папок ведёт себя как фильтр файлов. Я выбрал папку и увидел все файлы из подпапок поскиданными в одно место. Я скачал, и действительно, там вся структура папок сплющилась. В Gnutella1 с директориями всё было плохо, их не было, но G2, такое чувство, что этой детской болезнью до конца не переболела. Мне что, вручную воссоздавать директории? F7, Shift-F6, F7, Shift-F6, я правильно понимаю? Это я вот этим должен заниматься?
Далее, вот есть dcls для многофайловых раздач, а в Shareaza для этого есть коллекции. Только я что-то не увидел в wiki, как там дела с поддиректориями. Они вообще есть? Я вот подозреваю, что нет. И раз уж DC++ застолбил этот формат, будет логично, если Shareaza поддержит dcls, чтоб по нескольку раз не напрягаться для разных клиентов. Хотя это и не оформленная раздача, как в Shareaza.
Кроме того, я наблюдаю, что DC++ совершенно нормально обрабатывает мои многотысячные списки файлов, со всякими Platform SDK незапакованными. А у других видел и под миллион. В DC++ оптимальнее не запаковывать, чтобы общие файлы находились. Platform SDK, MSDN Library разных версий — они во многом повторяются по файлам. А Shareaza, наоборот, с каждым новым файлом начинает корчиться в муках и корчить в муках мой ноут. Что ещё хуже, если Shareaza вдруг ненароком увидела всю бездну файлов DC++, шокирована она будет навсегда. Хоть там убрать шокирующую папку из базы, хоть базу средствами программы почистить, всё равно мегатормоза. Только вручную если поудалять базу данных и заново расшарить, помогает. Получается, наоборот, оптимальнее упаковывать файлы в архивы, но тогда поиск альтернативных источников — до свиданья, и это получается как ещё один торрент, где владельцы идентичных файлов как в кромешной тьме и не могут друг друга найти. А мне с одним торрентом уже хватает головной боли. Это уже исправлено?
А ещё я считаю нормальным не иметь вычисленный sha1. Когда p2p только зарождался, разработчики делали proof of concept, были довольно наивными, а для наивного человека нормально полагать, что можно с 20и источников скачать файл общим размером 20Гб, и потом просто в дежурном режиме проверить SHA1 от 20Гб, и ни у кого клиент не сглючит, никто не обманет, хеш сойдётся. По идее, эта наивность должна остаться в далёком прошлом, вместе с SHA1, MD5 и всеми остальными недревовидными хешами, когда пошли жалобы «моя закачка начинается снова и снова, что делать?». Зачем вообще вычислять недревовидные хеши? Они же бесполезны. А если я на сервере хотел бы сгенерить коллекцию Shareaza, и у меня есть имя, размер, TTH, и больше ничего нет? Что, смогу я это сделать или нет? А вот по магнитной ссылке с TTH загрузка файла может начаться? Там в протоколе уже по чистому TTH закачка инициируется или всё ещё надо сначала ненужный SHA1 получить?
А так, в принципе, если бы DC++ расширить Gnutella2, это было бы хорошо. Стронговская DHT мне не понравилась, в Shareaza глобализация явно лучше. Только со спамом беда. На DC++ хабах спамераста можно выпнуть с хаба, а в Gnutella2 выпнуть некому, а было бы нелишне иметь небольшой контроль. Что-то вроде подсети Gnutella2, где каждый участник получил криптографическое подтверждение на право присутствия в хабе. И сообщения от хаба нумеровать серийными номерами, подписывать и через узлы оптимально распространять.
Возвращаясь к вопросу об оформлении, это сложный вопрос, выходящий за рамки проблем p2p. У нас есть отличный блог-редактор Windows Live Writer и протоколы XML-RPC, по которым он работает, но нет застывшего в файле аналога XML-RPC, чтоб как в Word, HTML с картинками содержал. Если мне по работе нужно было запостить на два наших сайта, я делаю пост в WLW, переключаю учётку и делаю ещё раз пост. А если репост с ненашего сайта — я шёл выколупывать с того сайта картинки по одной. А новостей может быть по 10 в день, в каждой по 5 картинок. Если новый пост пишу не я, а журналисты, отправляя друг другу на проверку и переделку, что чаще всего, то писать его будут не в WLW, потому что в нём нет файлов, а в Word, где файлы есть, но потом каждый раз в HTML переделывать надо из-за разной вёрстки. Знали бы вы, какой геморрой так каждый день. А всё потому что нет формата застывшего XML-RPC с вменяемым редактором для него. WLW не может ни сохранить в файл, ни открыть из файла, а если ковырять, то там какой-то вообще левый формат wpost Compound Document, который было бы сложно парсить и генерить на сервере. Другие HTML редакторы не аналогичны Word, в смысле, не умеют положить картинку внутрь общего файла. У Mozilla какой-то HTML редактор картинки кладёт в data URI, что для многих и без того непростых HTML парсеров на сервере стало бы серьёзным испытанием, когда картинки под мегабайты. Последний SAX парсер, которым я пользовался, не позволял читать атрибуты по 8К блокам, а возвращал их все сразу. С точки зрения формата идеально устроен WizHtmlEditor, там всё как надо, формат .zip, а в нём HTML с картинками, но сам редактор топорный до безумия, там даже картинку разместить с обтеканием без залезания в HTML код не получится. И XML-RPC нет. Непаханное поле, и вот кто это поле вспахал бы, заодно и с форматом p2p раздач вопрос решил.
И хеши передаются все TTH, BTIH, ED2K, SHA1.
Многие bittorrent клиенты умеют качать по http протоколу и не только одиночные файлы, а даже раздачи папками. Некоторые мои раздачи на рутрекере сидируются Dropbox. Правда, не все торрент-клиенты сейчас понимают https протокол, но utorrent 3.4.2 уже умеет. Поиск по именам и хешам есть в ed2k клиентах, рейтингами и комментариями так же можно обмениваться, например в том же utorrent 3.0
У нас Gnutella2 не получила широкого распространения, возможно из-за популярности на тот момент других p2p протоколов. И возвращаясь к первому комментарию, не всегда хорошо, когда p2p клиент умеет больше чем от него хотят. Зачем торрент-юзеру Shareaza или MLDonkey, если он качает только торрентом, и чатом он не пользуется? Мне кажется, что именно по этой причине мультисетевые клиенты не получили большой популярности.
У нас Gnutella2 не получила широкого распространения, возможно из-за популярности на тот момент других p2p протоколов. И возвращаясь к первому комментарию, не всегда хорошо, когда p2p клиент умеет больше чем от него хотят. Зачем торрент-юзеру Shareaza или MLDonkey, если он качает только торрентом, и чатом он не пользуется? Мне кажется, что именно по этой причине мультисетевые клиенты не получили большой популярности.
Если вас не смущает использование стороннего сервиса, то вот: btdigg.org/about/
У них есть API.
У них есть API.
Полагаю, немалую роль в популярности торрентов играет тотальное засилие браузеров и поисковиков в качестве основного инструмента работы в интернете и соответственно, заточка всех веб-сервисов под браузеры и поисковики. Может это не лучший вариант, но конкурировать с ним будет непросто.
Отсюда вывод — для поднятия популярности DC++ нужны публичные веб-сервисы, которые будут индексироваться поисковиками. А если такой веб-сервис будет обеспечивать закачку и скачивание файлов прямо из браузера (как в файлообменниках) — популярность будет выше, чем у торрентов. Еще бы, скачать бесплатно без SMS на полной скорости, за счет энтузиастов.
Отсюда вывод — для поднятия популярности DC++ нужны публичные веб-сервисы, которые будут индексироваться поисковиками. А если такой веб-сервис будет обеспечивать закачку и скачивание файлов прямо из браузера (как в файлообменниках) — популярность будет выше, чем у торрентов. Еще бы, скачать бесплатно без SMS на полной скорости, за счет энтузиастов.
Мне кажется DC++ надо идти на встречу torrent'ам. Добавить в протокол возможность поиск торрента по хешу, в ответ отдавать известные TTH файлов в торренте. Таким образом начав качать торрент можно докачивать и через DC++. Это будет лучше торрентокачалки уже в том, что можно будет находить одинаковые файлы в разных торрента и качать с нескольких раздач.
TorrentWizard пишет в торрент файл TTH каждого файла.
Совместимо с TorrentBuild?
По этой инструкции добавил "P2P:Protocol:Specifications:Optional Hashes". В моём моде Shareaza TorrentWizard пишет TTH. В официальном пишет всё хеши кроме TTH.
Любопытно. А понимает? Вот для теста: Operating Systems
Это такой аналог HttpFileServer, только он не сами файлы и не директории скопом в .tar или .zip может давать скачать, а вместо файлов — магнитные ссылки, а вместо директорий для скачивания скопом — соответственно, описывающие их .dcls и ещё .torrent. Торренты тут не обычные. В идеале после того, как в 2006м опубликовали спеку, должен был начаться переходный период, когда были и TTH, и архаичный info.pieces, и сейчас, десять лет спустя клиенты были бы готовы к переходу на чистый TTH, но этого не произошло, поэтому мои чисто-TTH-ные торренты, скорее всего, застанут большинство из них врасплох. А вычислять архаичный info.pieces для трети петабайта чужих шар, понятное дело, не получится. И всякие пофайловые sha1 — туда же. Ну и, конечно, торренты тут ещё затем что их ищут чаще, чем DCLS и TTH. Ищете торренты — нате пожалуйста, но только с TTH. Тот же DCLS, вид сбоку.
Это такой аналог HttpFileServer, только он не сами файлы и не директории скопом в .tar или .zip может давать скачать, а вместо файлов — магнитные ссылки, а вместо директорий для скачивания скопом — соответственно, описывающие их .dcls и ещё .torrent. Торренты тут не обычные. В идеале после того, как в 2006м опубликовали спеку, должен был начаться переходный период, когда были и TTH, и архаичный info.pieces, и сейчас, десять лет спустя клиенты были бы готовы к переходу на чистый TTH, но этого не произошло, поэтому мои чисто-TTH-ные торренты, скорее всего, застанут большинство из них врасплох. А вычислять архаичный info.pieces для трети петабайта чужих шар, понятное дело, не получится. И всякие пофайловые sha1 — туда же. Ну и, конечно, торренты тут ещё затем что их ищут чаще, чем DCLS и TTH. Ищете торренты — нате пожалуйста, но только с TTH. Тот же DCLS, вид сбоку.
Оригинальная Shareaza читает TTH из торрента. В однофайловой раздаче она умеет его использовать. В многофайловой на сколько я помню нет. Но всегда такой торрент можно разобрать скриптом на магниты и скачать файлы по отдельности.
Кстати sha1 файла полезен тем что из него и других параметров файла можно собрать микро торрент.
Плохо что магниты без скриптов не доступны.
Ну так и из TTH можно микроторренты генерить по той же спеке. В принципе, веб-сервер можно научить. Скрипт модифицировать, чтоб рядом с каждым файлом подрисовывал тоже торрент с теми же параметрами, что у магнитки, и пожалуйста. И на любой размер смасштабируется, и на малых размерах (<2Мб) проверка будет по 1Кб, а не по всему размеру. А MD5, между прочим, в RFC есть, Content-MD5 называется, и Apache2 его генерить умеет. Только файл нужно качать от начала и до конца, иначе Content-MD5 от куска будет. Что теперь, за каждую архаичность цепляться? Есть TTH, он хороший, проверенный и нечего вытрёпываться, велосипедить пи-хеш, а-бтих, будь здоров, и нечего вытрёпываться использовать недревовидные хеши, а среди древовидных нужно веское основание не вычислить TTH. Я так считаю.
Да, вот это и проблема, что только однофайловые. По оглашению мультипротокольная, а по умолчанию — все протоколы по-своему плохо. На базе DC++ гибридизация более перспективная, на мой взгляд.
Скрипты — это вынужденная мера. Обычная раздутая страница — 6.9Кб, а сжатая до той степени, насколько возможно не в ущерб SEO — 1.5Кб. А чем меньше размер, тем больше чужих шар влезет. С точки зрения SEO я больше хотел, чтобы TTH был искабельным через поисковики, поэтому он там текстом, а магнитки в явном виде нет, как и многого другого. Если же кому-то захочется в автоматическом режиме что-то обработать, так проще всю директорию слить в одном из предложенных форматах.
Да, вот это и проблема, что только однофайловые. По оглашению мультипротокольная, а по умолчанию — все протоколы по-своему плохо. На базе DC++ гибридизация более перспективная, на мой взгляд.
Скрипты — это вынужденная мера. Обычная раздутая страница — 6.9Кб, а сжатая до той степени, насколько возможно не в ущерб SEO — 1.5Кб. А чем меньше размер, тем больше чужих шар влезет. С точки зрения SEO я больше хотел, чтобы TTH был искабельным через поисковики, поэтому он там текстом, а магнитки в явном виде нет, как и многого другого. Если же кому-то захочется в автоматическом режиме что-то обработать, так проще всю директорию слить в одном из предложенных форматах.
Можно конечно и TTH и другие хеши в него запихнуть но это будет просто торент с альтернативными хешами. Суть микро торрента в том чтобы его могли собрать имея только sha1 хеш, имя и размер файла с обоих сторон и получить одинаковый infohash.
Микро торрент теоритически совместим со всеми торрент клиентами.
Сейчас в сети есть некоторое количество магнет ссылок у которых есть sha1 хеш (bitprint). Так-же в архиве да и в остальном интернете sha1 хеш присутствует рядом с остальной информацией о файле. Используя это можно собрать микро торрент и найти источники в Bittorrent DHT если кто то догадается так сделать.
Я планирую в Shareaza добавить автоматическую генерацию микро торрента для скачиваемого файла пока нет infohash из других источников.
Проверка частей файла при скачивании будет производится по TTH если он есть.
Да, вот это кажется бредом, чахнуть как Кащей над BTIH, лишь бы сошёлся. Имя поменяли — всё, капец, не сходится. Ну что за стыд.
Вот я понимаю, многофайловые раздачи непросто будет пересекающиеся находить, но с однофайловыми-то всё понятно должно быть. Просто берём и используем TTH вместо BTIH. Ну не влезло маленько 4 байта разница, давайте в старом механизме обрубим, а в новом учтём.
Вот я понимаю, многофайловые раздачи непросто будет пересекающиеся находить, но с однофайловыми-то всё понятно должно быть. Просто берём и используем TTH вместо BTIH. Ну не влезло маленько 4 байта разница, давайте в старом механизме обрубим, а в новом учтём.
Я сам обеими руками за использование TTH в торрентах. Но уже есть новый шаг в P2P передаче файлов — Межпланетная файловая система IPFS.
Такая система позволяет находить не только одинаковые файлы в сети но даже одинаковые части разных файлов. Эта система позволяет делить файлы на части в зависимости от формата так что бы в сети находилось большее количество дубликатов частей.
И этот «новый шаг» начался не с поддержки TTH. О чём они вообще думали, для кого они это делали. Крайне скептически я отношусь к таким «новым шагам». Ну как сделают TTH, так можно будет посмотреть.
Я тоже сначала возмутился этому а потом понял. У них тоже используется древовидная структра блоков. Только это уже не древовидное хеширование а направленный ациклический граф. Он позволяет более гибко хешировать файлы. Также размеры блоков как я понимаю не фиксированы но не могут превышать определённого значения.
Я попросил добавить TTH в мультихеш. Сейчас для хеширования блоков используется sha256.
Не надо бросать пыль в глаза. Любой хеш Меркля — на самом деле направленный ациклический граф. Если вдруг хеши соседних узлов сошлись, вот считай, уже не дерево, и можно было бы такие куски дедуплицировать. Другое дело, что в масштабах миллионов файлов держать индексы не только для корней, но и для внутренних узлов, и всё это в режиме реального времени обнаруживать, мне кажется, было бы убийственно для производительности.
Единственный полезный способ применять их произвольно гибкий граф, который я увидел, — это Jigdo для p2p. Но нормальный p2p стоит на прочном фундаменте хешей, всегда одинаковых для идентичных файлов. Я могу напихать файлов в Jigdo .iso, и эти файлы по TTH найдутся у тех, кто расшарил их, не координируясь со мной. Таким образом, из TTH+Jigdo можно сделать IPFS, а обратное, когда каждый хеширует файлы кто в лес, кто по дрова, не верно.
Я там прокомментировал, как технически можно было бы внедрить TTH с учётом тонкостей. Попутно мне пришла идея, а не запилить ли совместимый с IPFS хеш в DC++? Просто такие ребята, ну знаете, как-то раз три года назад собрались начать переход на новый древовидный хеш на основе SHA3, когда конкурс ещё только шёл, и вот до сих пор можно открыть список официальных расширений протокола, TIGR там есть, а SHA3 — нет.
Получается, планы озвучены, а в деталях реализации ещё чистый лист. Пользуясь шансом, можно взять и синхронизироваться. Чтобы сохранить все хорошие свойства TTH, придётся натянуть алгоритм IPFS на особенности вычисления TTH, и в каком-то диапазоне размеров файлов будет совместимость, а где-то у IPFS могут возникнуть (решаемые) проблемы.
Так, нижние блоки совершенно аналогично TTH всегда имеют гранулярность 1024 байта. Они образуют объекты Blob, а из Blob образуются объекты List аналогично TTH узлам. Синтаксис List используется, как в IPFS. При этом все синтаксические навороты IPFS с точки зрения преемника TTH — это просто способ посолить хеши. В TTH базовая криптографическая функция Tiger солится нулевым или единичным байтом, а здесь это будет:
Но только размеры здесь не могут быть произвольные. Всё должно быть повторяемо. Собственно, так же, как посоленная конкатенация Tiger хешей отправляется на вход Tiger и после вычисления исчезает, приведённая структура тоже существует только временно в памяти и не передаётся клиентами. Клиентами будет передаваться аналог gltth, то есть, тупо срез дерева хешей в максимально компактном виде.
И так же, как в TTH, с дерева при необходимости может сниматься не самый нижний уровень. Клиенты, поддерживающие TTH, не требуют от другой стороны более глубокой детализации блоков, а просто проверяют более крупными блоками, сами достраивая поддеревья до ближайшего известного узла. В IPFS — не знаю, наверное, это может вызвать проблемы. Но их оригинальные хеши слишком гибки для нас, а наши всегда совпадающие для идентичных файлов хеши могут оказаться неудобны для них, при этом на фундаменте наших хешей уже что-то работает, а можно было бы даже и Jigdo сделать, а на их хешах в общем случае — нет.
Ещё есть мысль добавить TTH рядом с этим новым, основанным на SHA3 хешем. Мне пока не понятно, возможно ли в Blob и List добавить ещё поле для TTH, но было бы здорово.
В общем случае взаимодействия между DC++ и независимо опубликованными в IPFS файлами всё равно не будет потому что кто в лес по дрова хеширует, но потом можно научиться публиковать файлы в IPFS так же, как это делает будущий гипотетический DC++, и тогда и с DC++ совместимость получится, и внутри IPFS разброд и шатания будут с меньшей амплитудой, владельцы идентичных файлов смогут находить друг друга. И TTH таким образом вплетённый, не «забудут» посчитать.
Единственный полезный способ применять их произвольно гибкий граф, который я увидел, — это Jigdo для p2p. Но нормальный p2p стоит на прочном фундаменте хешей, всегда одинаковых для идентичных файлов. Я могу напихать файлов в Jigdo .iso, и эти файлы по TTH найдутся у тех, кто расшарил их, не координируясь со мной. Таким образом, из TTH+Jigdo можно сделать IPFS, а обратное, когда каждый хеширует файлы кто в лес, кто по дрова, не верно.
Я там прокомментировал, как технически можно было бы внедрить TTH с учётом тонкостей. Попутно мне пришла идея, а не запилить ли совместимый с IPFS хеш в DC++? Просто такие ребята, ну знаете, как-то раз три года назад собрались начать переход на новый древовидный хеш на основе SHA3, когда конкурс ещё только шёл, и вот до сих пор можно открыть список официальных расширений протокола, TIGR там есть, а SHA3 — нет.
Получается, планы озвучены, а в деталях реализации ещё чистый лист. Пользуясь шансом, можно взять и синхронизироваться. Чтобы сохранить все хорошие свойства TTH, придётся натянуть алгоритм IPFS на особенности вычисления TTH, и в каком-то диапазоне размеров файлов будет совместимость, а где-то у IPFS могут возникнуть (решаемые) проблемы.
Так, нижние блоки совершенно аналогично TTH всегда имеют гранулярность 1024 байта. Они образуют объекты Blob, а из Blob образуются объекты List аналогично TTH узлам. Синтаксис List используется, как в IPFS. При этом все синтаксические навороты IPFS с точки зрения преемника TTH — это просто способ посолить хеши. В TTH базовая криптографическая функция Tiger солится нулевым или единичным байтом, а здесь это будет:
{
"data": ["blob", "list", "blob"],
// lists have an array of object types as data
"links": [
{ "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x",
"size": 189458 },
{ "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5",
"size": 19441 },
{ "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z",
"size": 5286 }
// lists have no names in links
]
}
Но только размеры здесь не могут быть произвольные. Всё должно быть повторяемо. Собственно, так же, как посоленная конкатенация Tiger хешей отправляется на вход Tiger и после вычисления исчезает, приведённая структура тоже существует только временно в памяти и не передаётся клиентами. Клиентами будет передаваться аналог gltth, то есть, тупо срез дерева хешей в максимально компактном виде.
И так же, как в TTH, с дерева при необходимости может сниматься не самый нижний уровень. Клиенты, поддерживающие TTH, не требуют от другой стороны более глубокой детализации блоков, а просто проверяют более крупными блоками, сами достраивая поддеревья до ближайшего известного узла. В IPFS — не знаю, наверное, это может вызвать проблемы. Но их оригинальные хеши слишком гибки для нас, а наши всегда совпадающие для идентичных файлов хеши могут оказаться неудобны для них, при этом на фундаменте наших хешей уже что-то работает, а можно было бы даже и Jigdo сделать, а на их хешах в общем случае — нет.
Ещё есть мысль добавить TTH рядом с этим новым, основанным на SHA3 хешем. Мне пока не понятно, возможно ли в Blob и List добавить ещё поле для TTH, но было бы здорово.
В общем случае взаимодействия между DC++ и независимо опубликованными в IPFS файлами всё равно не будет потому что кто в лес по дрова хеширует, но потом можно научиться публиковать файлы в IPFS так же, как это делает будущий гипотетический DC++, и тогда и с DC++ совместимость получится, и внутри IPFS разброд и шатания будут с меньшей амплитудой, владельцы идентичных файлов смогут находить друг друга. И TTH таким образом вплетённый, не «забудут» посчитать.
Посмотрел. Там протобуф. Значит, поле для TTH добавить везде можно. А ещё значит, механическое добавление TTH к списку других хешей не поможет в данном вопросе. Даже в Blob там будут добавки, сделающие содержимое слишком другим.
Поможет хакнутая функция, которая умеет парсить ProtoBuf для Blob и List и возвращать TTH для них.
Поможет хакнутая функция, которая умеет парсить ProtoBuf для Blob и List и возвращать TTH для них.
У GreyLink DC++ есть спецификация на такой режим режим работы. TTH (24 байта) чуть больше BTIH (20 байт), и BTIH + порядковый индекс файла в торренте образуют структуру той же длины, что и TTH, и по ней предполагалось делать поиск. Хотя лучше бы трекеры повернулись к нам лицом и начали требовать от заливающих TTH в торрентах. Вот один портал, называть который слишком много чести, требует отдельно текстом указать MD5 и SHA1, а TTH почему-то не требует ни текстом указать, ни в торрент включить.
На мой взгляд имело бы смысл доработать сам торрент файл, что бы в нем был шаблон с параметрами и описанием раздачи. Сей час не такая уж и большая проблема скачать файл в 2-3 мегабайта по сравнению с файлом весом 50-500 килобайт. Такой подход позволит прямо в торрент-клиенте расшаривать контент. В таком случае становиться реальной фича в скане папки или раздела и привязка файлов автоматически к соответствующим раздачам.
А моя личная мечта совместить торрент-клиент с перекодировщиком видео (транскодирование наподобие DLNA-сервера) и тогда кто-то подгрузил свеженький BD-релиз, и по запросу система быстренько конвертнула содержимое в удобный формат, который можно скормить любой железке. Эх, мечты-мечты!
А моя личная мечта совместить торрент-клиент с перекодировщиком видео (транскодирование наподобие DLNA-сервера) и тогда кто-то подгрузил свеженький BD-релиз, и по запросу система быстренько конвертнула содержимое в удобный формат, который можно скормить любой железке. Эх, мечты-мечты!
На мой взгляд имело бы смысл доработать сам торрент файл, что бы в нем был шаблон с параметрами и описанием раздачи.
Зачем это нужно? Я не видел, чтобы пользователи коллекционировали torrent-файлы. Источником файла является web-страница, и там можно всё написать.
Идея бы пригодилась для сети нового типа, где торрент-файлы были бы самостоятельными единицами и перекачивались от пользователя к пользователю. Например, зашёл к кому-нибудь в шару, а там все торренты аккуратно разложены. Скачал торрент-файлы, ознакомился с описанием, поставил контент понравившегося торрента на закачку.
В торрент файле есть поле комментарий. Если туда вставить HTML с описанием и переименовать в файл в «name.torrent.html» то по двойному клику по файл откроется в браузере. А если в ручную добавить этот файл в торрент клиент то начнется скачивание. Такие торенты можно шарить p2p сетях позволяющих поиск файла.
Я бы хотел обратить внимание общественности при выборе файлообменной сети вот на какой факт.
Начинал я пользование p2p с DC++ и потом с трудом воспринимал торренты (как в статье как раз и написано). И вот какую проблему я вижу. Да, у DC++ много минусов. Скачивание кота в мешке, а также появившаяся в последние годы новая проблема с фейками, когда имя файла не соответствует содержимому. Соответственно, появились и борцы с фейками, которые держат у себя этот фейк, но переименовывают его так, чтобы в имени файла было «фейк, лажа» и т.п. И в поиске ты видишь, что тут дело нечисто. Но тут могут подтянутся копирасты и специально создавать такую дезу на правильные файлы. В общем, без форума для каждой раздачи, как это сделано в торрентах — плохо.
Однако, лично для меня есть 2 существенных минуса у торрентов и, соответственно, два плюса DC++:
1 — Трудность раздачи контента из-за драконовских правил оформления. Ну вот имею я контент, но попробовав его правильно оформить, получив собак от админов и юзеров — проще плюнуть и забыть, чем оформлять все до запятых. В DC просто расшарил с правильным названием и все. Пользуйтесь. Ну и поиск по хешам работает.
2 — Привязка файловой структуры к торрент-файлу. Вот скачал я файлы по торренту. Там черт знает какое имя и структура каталогов. Меня однозначно не устраивает помойка на компе и неудобные мне имена файлов. Я сразу имя файла привожу к понятному виду и перекладываю его в свою коллекцию. И все, по торренту он уже недоступен. А вот по DC пожалуйста.
Вот как-то так. Если бы совместить файловую свободу DC с отзывами и описаниями торрнетов — это была бы бомба. Кстати, современные торрент-клиенты поддерживают скачивание по хэшу, без самого торрнет-файла. Это здорово.
Извините за длиннопост.
Начинал я пользование p2p с DC++ и потом с трудом воспринимал торренты (как в статье как раз и написано). И вот какую проблему я вижу. Да, у DC++ много минусов. Скачивание кота в мешке, а также появившаяся в последние годы новая проблема с фейками, когда имя файла не соответствует содержимому. Соответственно, появились и борцы с фейками, которые держат у себя этот фейк, но переименовывают его так, чтобы в имени файла было «фейк, лажа» и т.п. И в поиске ты видишь, что тут дело нечисто. Но тут могут подтянутся копирасты и специально создавать такую дезу на правильные файлы. В общем, без форума для каждой раздачи, как это сделано в торрентах — плохо.
Однако, лично для меня есть 2 существенных минуса у торрентов и, соответственно, два плюса DC++:
1 — Трудность раздачи контента из-за драконовских правил оформления. Ну вот имею я контент, но попробовав его правильно оформить, получив собак от админов и юзеров — проще плюнуть и забыть, чем оформлять все до запятых. В DC просто расшарил с правильным названием и все. Пользуйтесь. Ну и поиск по хешам работает.
2 — Привязка файловой структуры к торрент-файлу. Вот скачал я файлы по торренту. Там черт знает какое имя и структура каталогов. Меня однозначно не устраивает помойка на компе и неудобные мне имена файлов. Я сразу имя файла привожу к понятному виду и перекладываю его в свою коллекцию. И все, по торренту он уже недоступен. А вот по DC пожалуйста.
Вот как-то так. Если бы совместить файловую свободу DC с отзывами и описаниями торрнетов — это была бы бомба. Кстати, современные торрент-клиенты поддерживают скачивание по хэшу, без самого торрнет-файла. Это здорово.
Извините за длиннопост.
1 — Трудность раздачи контента из-за драконовских правил оформления. Ну вот имею я контент, но попробовав его правильно оформить, получив собак от админов и юзеров — проще плюнуть и забыть, чем оформлять все до запятых.Вас никто не заставляет делать раздачу на трекере. Я, например, часто ищу торренты прямо на btdigg.com/ — поисковику по DHT. Как правило, по названию папки и файлов в ней, все понятно.
2 — Привязка файловой структуры к торрент-файлу. Вот скачал я файлы по торренту. Там черт знает какое имя и структура каталогов. Меня однозначно не устраивает помойка на компе и неудобные мне имена файлов. Я сразу имя файла привожу к понятному виду и перекладываю его в свою коллекцию. И все, по торренту он уже недоступен. А вот по DC пожалуйста.Некоторые торрент-клиенты позволяют переименовывать файл, но проблема действительно есть. Честно говоря, ничего удобнее DC++ пока не видел.
Вас никто не заставляет делать раздачу на трекере.
Если не делиться своим со всеми — то нечего будет и качать. А создать раздачу — это единственный способ расшарить свой контент в торрентах.
Я, например, часто ищу торренты прямо на btdigg.com/ — поисковику по DHT. Как правило, по названию папки и файлов в ней, все понятно.
Спасибо за подсказку (кстати, ссылка битая чтоли?). В случае с DC поиск по файлам часто может навести на фейк. А тут, я так понял, поиск по файлам из торрент-раздач, значит где-то есть и сама тема на трекере, в которой фейк могут зарубить. Это неплохой вариант.
Некоторые торрент-клиенты позволяют переименовывать файл
Это костыль. Причем неполноценный. Переименование и перекладывание он вряд ли осилит. Кроме того, часто я потрошу раздачу, например, удаляю отдельную оригинальную звуковую дорогу на английском, сабы (то, что мне и 90% людей не нужно), а сам файл переименовываю и перемещаю. При поиске по имени файла или хэшу он будет доступен.
кстати, ссылка битая чтоли?btdigg.org
Sign up to leave a comment.
Новый параметр описания раздачи &x.do= в магнет-ссылке для FlylinkDC++. Факторы выбора юзером файлообменной сети