[d | b / bro / ci / cu / dev / hr / l / m / mi / mu / o / ph / r / s / sci / tran / tu / tv / vg / x | au / tr | a / aa / c / fi / jp / rm / tan / to / ts / vn / vo]
- [Радио 410] [ii.booru-Архив РПГ] [acomics-cf-ost] [@] - [Архив - Каталог] [Главная]

[Назад]
Ответ
Leave these fields empty (spam trap):
Имя
Тема
Сообщение
Файл
Подтверждение
Перейти к [
Пароль (для удаления файлов и сообщений)
 
ЗАПРЕЩЕНО:
  • детская эротика/порнография
  • троллинг
 
  • Поддерживаются файлы типов GIF, JPG, MP4, OGV, PNG, WEBM размером до 4096 кБ.
  • Максимальное количество бампов треда: 500.
  • Всем посетителям рекомендуется ознакомиться с FAQ.

slow.png - (110 KB, 800x508)  
110 KB №192849   #1

А может мне кто-то объяснить, как работает DHT в торрентах. Конкретно меня интересует анонсирует ли мой торрент-клиент в DHT информацию о запущенных у меня торрентах.
Т.е. если я создам новый торрент, но нигде не буду размещать ни торрент файл ни магнет-линк, будет ли мой клиент анонсировать infohash этой раздачи?
И как работает поиск пиров в DHT? Я понимаю, что клиент смотрит на infohash и обращается к другим пирам в DHT, у которых адреса наиболее близки к этому infohash. Но что, если ни у кого из них нет данных про эту раздачу (И откуда эти данные вообще берутся? Пир должен участвовать в этой раздаче?)? Ведь, как я понимаю, поиск идёт "по сужающейся спирали", т.е. опрашиваются пиры, адреса которых наиболее близки к infohash. Но что если единственный сидер имеет адрес очень отличающийся от infohash? Как тогда его найти?

>> №197041   #2
OpenDHT_—_A_Distributed_Hash_Table_(blog(...).png - (21 KB, 622x392)  
21 KB

>>192849
Какая картинка прикреплена, столько и ответа ждать!

Да, клиент анонсирует, если DHT в нём включен и если в торренте не указан флаг приватности. И для новой раздачи клиент тоже будет делать то же самое, различий тут нет. Именно благодаря этому свойству работают поисковики по DHT, вроде погибшего BTDigg — слушая и записывая все анонсы раздач, которые ходят в сети.

Механизм поиска пиров чуть более сложный... Начнём с явного указания того, что Peer ID и infohash раздач принадлежат к одному и тому же адресному пространству, и клиент может сравнивать их друг с другом. Вовсе не страшно, если infohash раздачи будет сильно отличаться от Peer ID единственного раздающего. Более того, вообще нет никакой необходимости в том, чтобы именно эти два значения были похожи.
И опрашиваются те известные DHT-пиры, Peer ID которых наиболее похож на infohash желаемой раздачи, совершенно верно. Но те не обязаны сразу знать о раздаче с таким infohash — вместо этого они могут вернуть нашему клиенту данные для связи с ещё одним DHT-узлом, чей Peer ID ещё более похож на infohash раздачи. И так далее... пока цепочка не приведёт нас к узлу, у которого окажется непосредственная информация об интересующей нас раздаче. Ну и участвовать в раздаче не обязан ни один из них — только хранить полученную из анонсов информацию. Таким образом, состояние сети стремится к тому, что узлы будут хранить информацию о тех раздачах, infohash которых похож на их собственный PeerID. Сид с раздачей отдельно, информация о ней отдельно.

А вообще, лучше будет прочесть описание протокола вот здесь: http://translatedby.com/you/protocol-dht/.

>> №197044   #3

>>192849
Технически возможно искать не анонсируя. И тогда пир с ид наиболее близким к инфохэшу не будет обладать инфой о раздаче.

>> №207866   #4
Chuunibyou demo Koi ga Shitai! - resonat(...).webm - (1554 KB, 1920x1080)  
1554 KB

>>197044

Как это?

Ну анонсирует кто-то другой тогда.



Удалить сообщение []
Пароль
[d | b / bro / ci / cu / dev / hr / l / m / mi / mu / o / ph / r / s / sci / tran / tu / tv / vg / x | au / tr | a / aa / c / fi / jp / rm / tan / to / ts / vn / vo]
- [Радио 410] [ii.booru-Архив РПГ] [acomics-cf-ost] [@] - [Архив - Каталог] [Главная]