と呼ばれるBtdigg.orgに興味があり"DHT search engine"
ます。この記事によると、コンテンツは保存されておらず、データベースさえありません。次に、それはどのように機能しますか?他の通常の検索エンジンのように、メタ情報を収集してデータベースに保存する必要はありませんか? ユーザーがクエリを送信した後、DHT ネットワークをスキャンし、「リアルタイム」で結果を返しますか? これは可能ですか?
4 に答える
私は BTDigg について具体的な洞察を持っていませんが、データベース (またはデータベースのように機能するもの) が存在しないという主張は誤りだと思います。その記事の著者は、たとえば実際の .torrent ファイルが保存されている従来の torrent サイトで遭遇する可能性のある、より具体的なものに言及していた可能性があります。
BTDigg のようなサイトは次のように機能します。
- 特にDHTトラフィックを「傍受する」目的で、人々が話している情報ハッシュに導入するために、一連のDHTノードを実行します。
- これらのスウォームに参加し、ut_metadata 拡張子を使用してメタデータ (.torrent ファイル) をダウンロードします
- そこにある情報にインデックスを付け、情報ハッシュにマップします
- そのインデックスのフロントエンドを提供する
少し贅沢したい場合は、知っている情報ハッシュを定期的にスクレイピングして、時間の経過とともに統計を収集し、群れがいつ消滅してインデックスから削除する必要があるかを把握することもできます.
したがって、.torrent ファイルもコンテンツも保存しないという主張は真実です。
DHT はキーワード検索を中心に編成されていないため、DHT をリアルタイムで検索するのは現実的ではありません。インデックスを「バックグラウンドで」継続的に構築および維持する必要があります。
編集:
この回答以降、最適化 ( BEP 51 ) が一部の DHT クライアントに実装され、ホストしている情報ハッシュをクエリできるようになり、インデックス作成のコストが大幅に削減されました。
DHT とそのアプリケーションについての深い理解については、Scott Wolchok の論文とプレゼンテーション「Crawling BitTorrent DHTs for Fun and Profit」を参照してください。彼は、自律型検索エンジンのアイデアを、DHT のセキュリティに関する研究の補足として次のように提示しています。
彼の論文のPDF:
DEFCON 18 での彼のプレゼンテーション (パート 1 & 2)
それは2つのステップに分かれています。
bep_0005 protocol got infohash を実現するために
find_node (request)
、すべてのプロトコルを実装する必要はありません。これは私のオープンソースのdhtspiderの 1 つです。get_peers (response)
announce_peer (response)
bep_0009 プロトコルを達成するために、メタ情報 インデックスを取得しました。これは、私自身のbittorrent 検索エンジンです。毎日、一意の情報ハッシュ 300w +、有効なメタ情報 50w + を取得できます。
https://www.usenix.org/legacy/event/woot10/tech/full_papers/Wolchok.pdf
セクション 3 で使用されている方法は、すべての torrent データを格納するデータベースが必要であることを示唆しているようです。パフォーマンスは向上していますが、真の DHT 検索エンジンではない可能性があります。
セクション 8 は、効率は劣りますが、キーワードがストアの値である限り、DHT 検索エンジンのようです。
セクション 3、Bittorent 検索のブートストラップから:
「このシステムは、各 torrent のファイル名と説明の連結を典型的な情報検索モデルのドキュメントとして扱い、逆インデックスを使用してキーワードを torrent と照合することにより、ユーザーのクエリを処理します。これには、人気のあるオープンソースのリレーショナルによって十分にサポートされているという利点があります。 DBMS. トレントの人気度に応じて検索結果をランク付けします。これは、DHT にリストされているピアの数から推測できます。
セクション 8、関連作業から:
DHT を使用して検索を分散する通常のアプローチは、逆インデックスを使用するもので、各 (キーワード、一致するドキュメントのリスト) ペアをキーと値のペアとして DHT に格納します。ジョンら。[17] は、このアプローチを説明し、そのパフォーマンスの問題を指摘しています。ファイル間でのキーワードの Zipf 分散は、非常に偏ったロード バランスをもたらし、ドキュメント内のキーワードごとにドキュメント情報が 1 回複製され、分散環境でドキュメントをランク付けすることは困難です。