2

私はいくつかの DHT システム、特にペストリーとコードを調べてきました. チャーンに対する Chord の反応についていくつかの懸念を読んだことがありますが、それは私の目の前にある仕事にとっては問題にはならないと信じています。コースプロジェクトのために中央サーバーに依存しない、ある種のソーシャルネットワークサービスを実装しています。ルックアップには DHT が必要です。

最初はネットワーク内のすべてのサーバーを知りません。前述したように、メインのトラッカー サーバーはありません。これは次のように機能します。各クライアントには 3 つの専用サーバーがあります。3 台のサーバーにはクライアントのプロファイルがあり、それはウォールであり、個人情報であり、複製されています。ユーザーが友人を追加したとき(クライアントのアドレスを入力したとき)にのみ、他のグループのサーバーについて知ることができます。したがって、3 台のサーバーからなる 2 つのグループに 2 つの個別の DHT を作成し、それらが互いに友達になったら、DHT に参加したいと思います。これは一貫して行いたいと思います。プロトコルに精通する時間があまりないので、2 つの別々の DHT に参加したい場合、どちらが優れているか知りたいですか?

4

1 に答える 1

2

分散ハッシュ テーブルは、特定のデータを格納するノードを見つけるという問題を自動的に処理するように設計されています。したがって、DHT の設計哲学では、プロファイル、壁などに専用のサーバーはありません...それぞれに専用のデータ識別子があり、DHT はアクティブなサーバー間でのデータの配置を処理します。特定のデータに適したサーバーを見つけます。

Pastry と Chord は、機能の点ではかなり似ていますが、隣接セットとルーティングの処理方法が大きく異なります。この種のアプリケーションでは、一方が他方よりも優れているかどうかはわかりません。

本当に詳細が必要な場合は、Infocom 2005の優れた技術比較論文として、A performance vs. cost framework for Evaluation DHT design tradeoffs under churn (PDF)があります。

于 2010-03-31T17:17:27.763 に答える