> отчего странно? в данном случае вполне закономерно, DHT так работает. не обязательно
> аннонсить хэш, чтобы ответить на вопрос, есть ли он у меня. Ты не понял: ID ноды выбирается случайно. Поэтому в общем случае у ноды с "похожим на искомый хэш ID" ... вообще нет нужного торента. ID генерится случайно и ни к чему ноду не обязывает.
Нода лишь индексатор, отвечает за близкую к своему ID часть keyspace. Зона ответственности выбирается рандомно, т.к. ID узла случаен. И лишь поэтому узел потенциально может знать где взять торрент с близким хэшом. Чтобы оно вообще узнало где этот торрент брать - обладатели торента с таким хэшом должны явно сделать итеративный лукап, отобрать наиболее подходящих номинантов по близости их ID к хэшу торрента и опубликовать себя на таковых узлах. Это публикация. Тогда те кто ищут такой же торрент, смогут повторив такой же итеративный лукап найти и отобрать примерно те же самые узлы. Опросив оные они узнают "а кто изволил сообщить что у него есть такой хэш?". Если никто не изволил - по идее результатов быть не должно. Просто потому что работает оно так.
Кстати DHT вообще ничего не знает о том что это. Потенциально это вообще может и не хэш торрента быть, DHT глубоко пофигу и это позволяет ряд "побочных" применений, по типу "distributed dynamic dns" и тому подобное веселье.
По факту, UDPшный DHT и TCP-клиент - это 2 разных мира. Они независимы и пересекаются только в тот момент, когда DHT попросили найти всех у кого был такой-то хэш, он сделал итерации, получил от узлов с близкими ID список опубликовавшихся и скормил его TCP клиенту как потенциальных пиров у которых есть торрент.
> просто с анонсом меня быстрее найдут, вот и всё.
По идее без явной публикации вообще искаться не должно. Потому что процесс состоит из публикации ключа и только потом можно получить список тех кто опубликовал этот ключ. Может ли нод сам на себя запубликовать имеющийся торрент с близким ID - вопрос интересный, да, но вероятность возникновения такого расклада в большой DHT в целом небольшая, да и клиент должен при этом все-таки забить на приватный флаг и заиндексить это на самом себе :). TCP клиент который имеет право отвечать на запрос скачать с него торрент про все эти махинации - вообще не в курсе в общем случае. Потому как живет своей жизнью и от DHT его вообще список пиров только волнует. А DHT от TCP клиента интересует только поисковые запрсоы да списки хэшей на публикацию.
DHT и TCP клиент крайне мало знают друг о друге, а опубликованный в DHT ключ в принципе вообще не обязан торрентом быть, что на самом деле позволяет кучу "нецелевых" использований DHT, по типу dynamic DNS и прочая :).
По факту это две независимых подсистемы слегка скрепленные проволокой и скотем. Они могут вообще отдельно друг от друга жить. В DHT нельзя попросить "дай мне торрент X". Там можно попросить "а найди мне всех у кого есть торрент X?". Результат - список пиров изволивших опубликоваться как обладатели торрента X, если узел знает их. Или следующие, "более подходящие" узлы которые он знает.
>> Я нашел более простой воркэраунд: смотрим инфохэш и скармливаем его как магнет.
> учитывая, что я всё равно периодически собираю качалку из гита, а не
> ставлю из пакета, то наложить патч в две строки — никак не проблема.
Ну я тоже собираю, но мне лениво при наличии столь наглого воркэраунда который в принципе не фиксится никак :)
> см. выше. dht-аннонсы просто ускоряют поиск. но даже если я сижу бирюком
> и ничего не аннонсю, а только отвечаю на вопрос «эй, бро, есть чо?»,
Отвечаешь через что? В DHT для этого неизбежно надо сначала опубликовать это. Т.е. забить на этот флаг. Даже публикация на самого себя если хэш близок к ID (вообще, я не помню, допускается ли такой маневр, возможно что это совсем запрещено в спеках) должна забить на этот флаг. А на другие ноды - и подавно. Грубо опрашивать TCP порт всех нодов в процессе лукапа - больно тормозно, да и не кооперируют DHT и TCP на таком уровне. Это 2 независимые подсистемы и напрямую отвечать на такой запрос умеет только TCP-клиент который качанием занимается. DHT умеет только списки пиров которые потенциально обладают этим торрентом выдавать.
> то вероятность меня найти ненулевая. а поскольку таких бирюков
> обычно достаточно много — то и находит. аннонсы просто помогают информации
> обо мне расползтись пошире, поэтому и найдут меня быстрее.
Все-равно не понимаю как это работает - просто долбиться в TCP порт первых встречных нодов с "похожим ID" больно накладно выходит, есть лимит соединений, поэтому никто так не делает, тем паче что TCP клиент ничего о работе DHT не знает. А в DHT просто нет такого типа запросов. Там можно как максимум "а дай мне список тех у кого есть вот это?". Чтобы этот список образовался - кто-то определенно должен забить на флаг и произвести публикацию. Что видимо и происходит :). Может у кого-то баг порылся и приватный флаг по факту совсем игнорируется, так что они все-таки публикуют в DHT, черт его знает.
> xor-метрике близок к этому id. опрашивает на предмет: «эй, бро, есть чо?
Только вот результатом опрса является не торрент а лишь список TCP-клиентов пиров, у которых "чо" может быть. При том эти пиры саи пришли и сами опубликовались, откуда опрашиваемый про их существование и узнал, собственно. Если нод включает в этот список самого себя, получается что он как минимум произвел публикацию сам на себя, положив на приватный флаг. Т.е. покладание на приватный флаг по любому имело место + публикация самого на себя в DHT обычно считается кривым вариантом и многие реализации явно избегают этот маневр, срубая попытку публиковать на самого себя.
> а если нет, спроси у соседа, может, у него есть чо?»
> таким образом запрос расползается по сети.
Не, не так. Если опрашиваемый не может найти то что от него хотели - он смотрит в таблице какие у него ноды есть и дает вопрошавшему не результат поиска а список "еще более подходящих кандидатов", по XOR метрике все той же. Вопрошающий смотрит что ему подсунули, запоминая "наилучший" результат, так что если результат не улучшается - через некоторое время тщетных попыток делается вывод что ключа совсем нет.
> если за некоторое время ответ на запрос не пришёл, то считается, что ничего нет. от,
> собственно, хэша это не зависит никак.
У тебя какие-то архаичные представления о том как это работает, эпохи gnutella. В DHT типа Kademlia запрос к соседу не делается - итеративный лукап делает только тот кто ищет хэш или публикует его. Эта логика не расползается по сети. Что делает ее намного эффективнее. Сеть не флудится черти-чем, вместо этого поиск за несколько итераций отбирает "наиболее подходящих кандидатов".
Утрировано, публикация: публикующий делает итеративные запросы в DHT на поиск цели. Отбирая в результате N-е число кандидатов на которых он публикует "а вот у меня это есть". Обратный процесс: тот кто ищет желаемое, делает такой же итеративный поиск. Если в процессе поиска узлы видят что на них это заиндексировано - вопрошавшему возвращается список опубликовавшихся. А прямых запросов "эй, у тебя есть этот ID?" на UDP порт DHT вообще не предусмотрено. Потому что это прерогатива TCP клиента и он вообще не в курсе чем там UDPшный DHT занимается.
И да, эта логика в отличие от тупого флуда поддается абузивным атакам. Можно поставить пачку узлов с ID крайне близким к атакуемым хэшам и почти вся масса публикаций будет идти туда. При этом, потенциально можно собрать (не полный но близкий к тому) список обладателей хэша + попытаться вызвать облом поиска, завирая что ничего не знаем о таком хэше. Так что поиск может обломаться. По поводу чего в некоторых реализациях DHT немного меняют логику для повышения стойкости к атакам, так чтобы публикация шла не "на N лучших" а "по всему пути итеративного поиска". Это чуть снижает эффективность относительно теоретической, зато делает намного более сложными указанные типы атак.
> аннонсы же всего лишь позволяют несколько укоротить цепочку,
Не, не так. Kademlia всегда лукапает за ~6-7 итераций в сети с миллионами участников. Тупой флуд там не просто не предусмотрен, для него даже сообщений протокольных не предусмотрено. Там предусмотрена только публикация и поиск. По вполне определенным правилам.
Этот процесс в целом больше всего смахивает на что-то типа... хм, наверное, прохода по b-дереву покрывающему весь keyspace, за несколько итераций достигается близкая точка. Совпадение с обходом дерева не идеально точное, но примерная модель поведения такая. И свойства примерно те же, лукап в DHT заканчивается за O(ln N). Тогда как тупой флуд ближе к O(N) что при миллионах нодов работает плохо. Kademlia - структурированная, никакого флуда.
> потому что некоторые соседи
> уже знают про других соседей и про то, что у них
> «есть чо», поэтому можно обойтись без дополнительных запросов и ответить сразу.
А вот и фигу - это тебе не гнутелла с ее флудом во все стороны.
> на, читай вот: http://www.pps.univ-paris-diderot.fr/~jch/software/bittorrent/
> у человека полностью stand-alone реализация торрентового DHT в одном небольшом си-файле.
А ты, я смотрю, юморной тип :). Прислать мне ссыль на либу которая в трансмишне юзается - это оригинально. Думаешь, я ее впервые в жизни вижу? :) Кстати автор оной довольно специфичный тип и как на 100% референс я бы на него не полагался. Он вполне мог в принципе местами проявить инициативу за пределы спеков. За референс предлагаю считать все-таки в основном официальные спеки.
А теперь покажи мне там код, где "а если нет, спроси у соседа, может, у него есть чо?»"
На самом деле вопрошаемый отвечает: я, Вася, не в курсах где это, но вот Петя и Коля могут знать больше - иди их доканывай! :)
Ну а спеки - это http://bittorrent.org/beps/bep_0005.html + для общего понимания идеи Kademlia как она изначально задумана это "Peter Maymounkov, David Mazieres, "Kademlia: A Peer-to-peer Information System Based on the XOR Metric", IPTPS 2002. http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf" - (c)перто с сайта битторента :). Вот этот чудный документец очень хорошо излагает идею протокола.
PS интересно, что вот такого ругательного я сказал что вордфильтр возбух? Ппц!
