問題タブ [dht]

libtorrent/rasterbar の python バインディングをいじっています。私がやりたかったのは、新しい「ノード ID」を生成し、それを他のノードに再通知することでした。

「コード化された辞書」を作成する必要があることを読みましたが、force_dht_reannounce などを使用して発表されたと思いますが、これは正しいですか?

大学のプロジェクトとして電子投票システムを実装しようとしていて、私の目的に向けた最も重要なステップに直面しました<システムアーキテクチャ>

Multi-Server/Multi-Client , MUST really be reliable to the point of about 80 million clients are online , It also MUST permit new server joining to support the voting process , Its output will be statistics & reports so that it MUST allow me gathering information at any time , Supporting encryption , hashing , digest acks , .. etc

My aim is just to support lots of clients without central point of failure then make client fount the suitable server(s) to authenticate & vote
Suitable server(s) depends on 2 criteria :

• Server distance priority
• Server load priority

First criteria used Initially only , Both are used during voting process

After searching samples around my project found 6 solutions :

• Dynamic DNS server in between servers & clients
• Web Farm Load Balancing Dispatcher in between clients & servers
• サーバーのサーバーレス p2p クラウド、クライアントは PNRP を使用して p2p のサーバーとして参加し、サーバーのリストを取得します
• Serverless/State-Server p2p サーバーのクラウド、クライアントは状態サーバーに接続してサーバーのリストを取得します
• サーバーツリーはメインサーバーから下へ
• DHT ネットワーク & データベース システム

私の観点からは、ボトルネック障害点がないため、最後のソリューションが適切でした。これにより、すぐに使用できる DHT ライブラリまたは完全な分散システムを検索して、アプリケーションに統合するか、車輪を再発明して実装することができます。すべてをゼロから!!

質問:
- 適切なソリューションを選択しましたか?
はいの場合、すぐに使用できる [.NET] ライブラリまたはシステムにつながる正しいルートを教えてください。
いいえの場合は、6 つのソリューションで言及していませんが、適切な [.NET] ソリューションを教えてください。

よろしく ,

トレントDHTネットワークにアクセスしようとしていますが、DHTの「エントリ」ノードにアクセスする方法を理解するのに苦労しています。

BittorentクライアントのDHTはどのように「ブートストラップ」されますか？

ポート6881（UDP）で実行されているrouter.bittorrent.comとrouter.utorrent.comを使用して、いくつかの標準エントリノードを使用できることを説明します。また、 http： //www.bittorrent.org/beps/bep_0005.htmlには、DHTサーバーとの対話方法に関するプロトコルが記載されています。

しかし、単純なUDPメッセージをrouter.utorrent.com:6881に送信した場合、要求に応じてどのポートメッセージが返送されるかをどのように知ることができますか？6881に送信したのと同じポートでメッセージをリッスンしようとしましたが、何も受信しません。

これらのエントリポイントは自分のクライアント（uTorrent）に限定されていますか、それともサードパーティのクライアントが「ルーター」を使用できますか？

'v'Bittorrent Mainline DHT（MDHT）応答のキー値は何に対応していますか？

バンドルされた応答の例を次に示します。

このキーがどこにも文書化されていません。

プロトコルに関する私の現在の情報源は次のとおりです。

• BEP 5：DHTプロトコル
• Kademlia：設計仕様

私が理解しているように、最初のルックアップ要求は、ルーティングテーブル内でトレントの情報ハッシュに最も近いノードに送信されます。

ピアルックアップのプロセス中に、私は多くのノードを受け取ることができます。次のピアルックアップを実行するときに、それらの1つからピアルックアップを開始できますか、それともルーティングテーブルのピアから開始する必要がありますか？

get_peers クエリのメインライン DHT ノードによって送信される udp パケットの最大サイズは? 3000 個のピアを格納するとき、ノードはどのように応答しますか? (その場合、パケットは非常に大きくなります)。メインラインの DHT クライアントはどのように応答を処理しますか?

前もって感謝します。

メインラインDHTの仕様から誰かが私に声明を明確にすることができますか？

最初のノードをルーティングテーブルに挿入し、その後起動すると、ノードはDHT内で自分自身に最も近いノードを見つけようとする必要があります。これは、より近いノードが見つからなくなるまで、より近いノードにfind_nodeメッセージを発行することによって行われます。

「近くが見つからなくなるまで」とはどういう意味ですか？

プログラムがfind_nodeメッセージの送信を開始すると、ノードのセットが空になります。find_nodeメッセージへの各応答は、約8dhtノードを返します。私のプログラムはそれらをリストに集めます。

プログラムはいつfindnodeメッセージの送信を停止する必要がありますか？

すでに収集されたノードのリストにすべての要素が含まれているdhtノードのセットを受信するときに送信を停止する必要があると思いますか？

私は正しいですか？

前もって感謝します。

DHT に関する基本的な考え方は wiki から入手しました。

ストアデータ:

DHT ネットワークでは、すべてのノードが の特定の範囲を担当しますkey-space。ファイルを DHT に保存するには、まずhash the file's name to get the file's key; 2番目にsend a message put(key, file-content) to any node of the DHT、メッセージは責任のあるノードに中継され、keyそのノードはペアを保存します(key, file-content)。

データを取得:

DHT からファイルを取得するときは、まず、ファイルの名前をハッシュしてkey;を取得します。2番目に任意のノードにメッセージを送信し、メッセージget(key)を中継します...

質問:

1. ファイルを保存するには、ファイルの名前をハッシュして を取得できますkeyが、wiki には次のように記載されています。

現実の世界では、キー k は、ファイルの名前のハッシュではなく、ファイルのコンテンツのハッシュであり、ファイルの名前を変更してもユーザーがファイルを見つけるのを妨げないように、コンテンツ アドレス可能なストレージを提供します。

ファイルの内容をハッシュしますか? ファイルの内容を知るにはどうすればよいですか? ファイルの内容を既に知っている場合、なぜ DHT で検索するのでしょうか?

2. ウィキによると、参加しているすべてのノードは、ファイルを保存するためにいくらかのスペースを確保します。では、DHT に参加した場合、自分が担当spare 10G disk spaceするファイルを保管しなければならないということですか?key falls into the specific key-space

3. 実際にそれらのファイルを保存するためにいくらかのディスク容量を確保する必要がある場合、それら(key, file-content)をディスクにどのように保存すればよいでしょうか? つまり、ファイルをB-treeディスク上でまたは何かに配置する必要がありますか?

4. クエリが発生したとき、コンピューターはどのように応答しますか? まず、 をチェックしqueried key、 が にある場合は、ディスク上key-spaceで を見つけます。corresponding file右？

内部クラスター用に独自の dht を実装中です。bittorrent のようなファイル共有プログラムで使用されるため、最初に見たのは「Mainline DHT」でした。その後、「絡み合った」（python、ツイストマトリックスを使用したdht）、議会（python、pyev + libevを使用したdht）、そしてもちろんオリジナルの「kademlia」を見つけました。

k-bucket を整理するためのさまざまなアプローチがあります。

1) 議会、kademlia は、0 <= i < 160 の場合、2* i <= (各 ID の差) < 2 *(i+1) の範囲で固定の 160 バケットを使用します。

2) メインラインの DHT と entangled はダイナミック バケットを使用します。最初は、スペース全体をカバーするバケツが 1 つしかありません。8 つの生きているノードでいっぱいになると、バケットは 2 つの新しいノードに分割されます。ただし、そのバケット内に独自の ID がある場合のみ。そうでない場合 -- バケットは決して分割されません。そのため、すぐに 160 個の最も近いバケットとその他のバケットがいくつかあります。

どちらのバリアントでも十分です。しかし、IDがバケットに属しているかどうかを検出するロジックに大きな違いがあることがわかりました。これが私の質問です。

congress と kademlia は、バケット境界線を「私たちからの最小距離」および「私たちからの最大距離」として扱います。したがって、私たち自身の ID は常にbucket0 にあります。バケット 1 の最大 2 つの他の ID (2* 1 <= x < 2 *2 の距離をカバーするため) は、常に私たちに最も近いものになります。だから私の脳は壊れません。

しかし、Mainline DHT または entangled を調べると、xor 距離ではなく、絶対ノード ID 境界として扱われるバケット境界が表示されます。したがって、理論的に完全なテーブル ID では、0、1、2、3、4、5、6、7 が 1 つのバケットになります。

そう。一部の実装では、バケット境界を「私たちからの最大/最小距離」として扱い、他の実装では「最大/最小 160 ビット整数値」として扱うのはなぜですか??

アプリケーションで分散ハッシュ テーブルを使用したいのですが、エントリ ポイントとして中央サーバーを使用したくありません。これを実装する方法はありますか？