3

P2P インスタント メッセージング システムをセットアップしようとしています。まだ問題は発生していませんが、クライアントがローカル LAN の NAT の背後にある場合、いくつかの問題が発生することが予想されます (すべてのユーザーを参照してください)。

アルゴリズムを説明すると、私が何を意味するかがわかります。サーバーと 2 つのクライアントの 3 つのコンポーネントがあります。クライアントの Alice は、クライアントの Bob とチャットを開始したいと考えています。サーバーはオンラインのユーザーのみを追跡しますが、実際の会話はサーバーを経由しません (クライアントのプライバシーのため)。

そのため、Alice と Bob は両方ともサーバーにサインインします - サーバーの静的リスニング ポートに一時ポートから接続します。それらは、着信チャット要求をリッスンしている静的ポートをサーバーに伝えます。アリスはサーバーに、ボブに連絡する方法を尋ねます。サーバーは、特に IP アドレスとリッスン ポートで応答します。Alice は、接続を確立するために、その IP アドレスとポートで Bob に要求を送信します。それが理にかなっていることを願っています。

Bob が NAT の背後にいる場合、通信を開始するのは Bob であるため、Bob がサーバーと通信できることを確認してください。しかし、Alice の IP アドレスからのチャット リクエストをリッスンしているポートに対して、まだ NAT 関係が設定されていないため、Alice のリクエストは届きません。

誰かがこれを機能させるために知っているある種の黒魔術はありますか? それは問題ではありませんか?開発はそれほど進んでおらず、実際にはまだこの問題に遭遇していません。

はっきり言って、エンド ユーザーにリッスン ポートのポート フォワーディングを設定させる必要はありません。

前述の黒魔術の場合、クライアントとサーバーは両方ともJavaですが、私は一般的にアルゴリズムの後にいます(そしてそれが可能であれば)

4

2 に答える 2

1

ICEをチェックします。

Java の JXTA のようなほとんどの P2P フレームワークは、リレーサーバーの原理を使用します。

A が B に接続する必要があり、B がファイアウォールの背後にあるとします。

- both A and B establish ** outbound ** synchronous (or full duplex/websockets) connections to Relay Server R
- A signals to R that it wants to transmit data to B
- R 'binds' the inbound connection from A to the outbound connection to B (the synchronous HTTP response to B for instance)
- A sends data to R which is relayed to B

ここで重要なことは、すべての接続がアウトバウンドに確立されることです(通常、既知のポートで HTTP のような使いやすいファイアウォール プロトコルを使用します)。

リレーを分散している場合は、明らかにもう少し複雑になります。次に、情報を維持するために分散ハッシュマップ (DHT) に依存するリレーを介してさまざまなピアへのルートを維持する「ルーター」が必要です。

于 2012-10-02T07:55:18.093 に答える