我对 Btdigg.org 感兴趣，称为"DHT search engine"。根据{{3}}，它不存储任何内容，甚至没有数据库。那它是如何工作的？它是否需要收集元信息并将其存储在数据库中，就像其他普通搜索引擎一样？用户提交查询后，它会扫描DHT网络并“实时”返回结果？这可能吗？
答案 0 :(得分：18)
我对BTDigg没有具体见解，但我认为没有数据库（或类似数据库的东西）的说法是错误的陈述。该文章的作者可能指的是您在传统的torrent网站中可能遇到的更具体的内容，例如存储实际的.torrent文件。
这就是类似BTDigg的网站的工作原理：
如果你想稍微奢侈一下，你也可以定期刮掉你知道的信息哈希，以便随着时间的推移收集统计数据，也可以找出群体何时消亡并应从索引中移除。
因此，声称您不存储.torrent文件或任何内容都是正确的。
实时搜索DHT是不现实的，因为DHT不是围绕关键字搜索进行组织的，您需要在“后台”中连续构建和维护索引。
答案 1 :(得分：9)
要深入了解DHT及其应用，请参阅Scott Wolchok的论文和演示文稿“Crawling BitTorrent DHTs for fun and Profit”。他将自主搜索引擎的想法作为他研究DHT安全性的一个旁注：
他的论文PDF：
他在DEFCON 18（第1部分和第2部分）上的演讲
答案 2 :(得分：2)
https://www.usenix.org/legacy/event/woot10/tech/full_papers/Wolchok.pdf
第3节中使用的方法似乎建议用于存储所有torrent数据的数据库。虽然性能更好，但它可能不是真正的DHT搜索引擎。
第8节虽然效率较低，但似乎是DHT搜索引擎，只要关键字是商店值。
从第3节开始，引导Bittorent搜索：
“系统通过处理来处理用户查询 将每个torrent的文件名和描述串联起来 文档在典型的信息检索模型中使用 反向索引将关键字与种子相匹配。这具有优势 得到了流行的开源关系DBMS的良好支持。我们 根据洪流的受欢迎程度对搜索结果进行排名， 我们可以从DHT中列出的同行数量推断“
从第8节，相关工作：
使用DHT分发搜索的常用方法是 使用倒排索引，通过存储每个（关键字，匹配列表） 文档）在DHT中作为键值对配对。 Joung等。 [17] 描述这种方法并指出其性能问题： 文件中关键字的Zipf分布导致负载非常偏斜 平衡，文档信息将为每个关键字复制一次 文档，很难在分布式文档中对文档进行排名 环境
答案 3 :(得分：2)
它分为两个步骤。
要实现bep_0005协议获取infohash，您不需要仅实现现在find_node (request)，get_peers (response)，announce_peer (response)所需的所有协议。这是我的开源dhtspider之一。
要实现bep_0009协议得到metainfo索引，这里是我自己的 bittorrent search engine ，每天都可以得到唯一的infohash 300w +，有效的metainfo 50w +。