一番下にあるのは、ソケット通信に関するものです。両方のユーザーのIPを取得する方法がある場合、途中のサーバーを経由せずに、ユーザー間で直接接続を設定できないのはなぜですか?
5 に答える
私の2セント:
サーバーベースのリアルタイム通信モデルを強制する人は誰もいません。実際、XMPPには「サーバーレスメッセージング」と呼ばれる拡張機能があり、エンドポイント検出用のゼロ構成ネットワーキングの原則と、リアルタイム通信用のXMLストリームおよびXMPPメッセージングの構文を使用してローカルまたはワイドエリアネットワークを介して通信する方法を定義します。この方法では、DNSベースのサービス検出とマルチキャストDNSを使用して、IPアドレスや優先ポートなどのプロトコルをサポートするエンティティを検出します。
P2Pチャットアプリケーションは10年以上前から存在しています。サーバーを中央に配置することは、純粋にアプリケーションのニーズに応じた決定です。ユーザーがオンライン/オフラインステータス間を移行しているときにチャットが失われた状態でアプリケーションを使用できる場合は、直接P2Pモデルを使用できます。同様に、サーバーベースのメッセージングモデルの選択に関しては、多くの利点(連絡先リストの管理、アバター、エンティティの検出、プレゼンスの承認、オフラインメッセージなど)があります。P2Pベースのクライアント内でこれらすべてを正しく実行しようとすると、クライアントが自分で実行する必要のあるすべての作業のために、クライアントが死んだり、パフォーマンスが低下したりする可能性があります。
「WebSocket」は、P2P /サーバーレス通信用に設計されたものではなく、ステートレスHTTPプロトコルを介して標準化されたPUSHセマンティクスを提供するように設計されたものです。要するに、「WebSockets」は、ハッキーコメット、ロングポーリング、チャンクエンコーディング、jsonp、iframeベース、および開発者がHTTPを介したサーバープッシュをシミュレートするために使用している他のさまざまな手法に代わる標準化された方法です。
名前付きWebSocket(いつか完全に広くサポートされる場合)が解決策になる可能性があります。
http://namedwebsockets.github.io/spec/
名前付きWebSocketは、さまざまなコラボレーションローカルデバイスおよびローカルネットワークのシナリオで役立ちます。ローカルデバイスやローカルネットワークで一致するピアサービスを検出します。
WebSocketは、ソケットが接続をリッスンすることを許可せず、クライアントとしてサーバーに接続することのみを許可します(リバースではありません)。技術的には、これを許可することはできますが、私が理解している限り、仕様では現在WebSocketのリッスン機能が許可されていません(または許可されていません)。
新しいWebRTC(http://www.webrtc.org/)仕様は、ピアツーピア接続をサポートしているように見えます。私はWebRTCをまったく使ったことがないので、コメントする立場にはありません。WebSocketのものよりも少し複雑になると思います。WebRTCをよく知っている人なら、チャイムを鳴らすことができるかもしれません(Chromeの最新バージョンを除けば、他のブラウザーが本当にWebRTCをサポートしているかどうかはまだわかりません)。
ピアツーピア(P2P)ネットワークでは、ユーザー間の直接通信が可能です。P2Pでは、各参加者はサーバーとしてだけでなくクライアントとしても機能できます。ただし、P2Pネットワークの場合は、通信を可能にするために別のプログラムを作成する必要があります。
Web Socketsを使用すると、既存の一般的なブラウザーをクライアントとして活用できます。すべては、アプリケーションの目的と、アプリケーションをどのようにデプロイするかによって異なります。
両方のユーザーのIPを取得する方法がある場合
あなたはあなたの質問に正解を釘付けにしました。
私が使用しているほとんどのマシンは、IPアドレス192.168.0.10
(またはプライベートネットワークからの同様のもの)を持っており、 NAT192.168.
のいくつかのレイヤーの背後にあります。無料のIPv4アドレスプールの終わりとIPv6はどこにも見えないので、これはほとんどのユーザーが生きている現実です。既知のルーティング可能なアドレスの安定した仲介者を持つことは、この問題を回避するのに役立ちます。