まず、必要なデータ フローについて説明します。
Client connects and registers with server
Server sends initialization JSON to client
Client listens for JSON messages sent from the server
これはすべて手動で簡単かつ簡単に行うことができますが、何らかのサーバーを利用して、すべての接続、キープアライブ、デッドクライアントなどを処理したいと考えています.
この種のことを行う前例はありますか？クライアントが接続し、サーバーから JSON メッセージを非同期的に受信する場所は? 手動ソケットプログラミングを使用せずに？
考えられる解決策はCometとして知られています。これには、クライアントがサーバーへの接続を長時間開いたままにすることが含まれます。その後、サーバーはデータが利用可能になるとすぐにクライアントにプッシュでき、クライアントはほぼ瞬時にデータを取得します。最終的に Comet 接続がタイムアウトになり、別の接続が作成されます。
使用している言語はわかりませんが、Java と Scala でこれらのいくつかを見てきました。comet フレームワークと言語名を Google で検索すると、何かが見つかるはずです。
「古き良き時代」では、最初の接続でサーバーがクライアントのIP番号を取得し、コールバックできるため、これは簡単です。実際、FTPがそれを行う方法は非常に簡単だったので、正当な理由はありませんでした。しかし、クライアントがNATの背後にあることはほぼ確実なので、「コールバック」することはできません。
次に、TCP接続を開いたままにしておくことができます。これは双方向であるため、クライアントにデータが表示されるのを待つだけです。サーバーは可能な限り必要なものを送信します。しかし、今では誰もがすべてのアプリケーションをWebブラウザー上で実行することを望んでいます。つまり、HTTPは、クライアントによって開始される厳密な「要求/応答」です。
したがって、現在の答えは彗星です。簡単に言えば、JavaScriptクライアントはリクエストを送信しますが、サーバーは非常に長い間応答しません。接続がタイムアウトした場合、クライアントはすぐに接続を再開するため、サーバーの応答を待機している開いているパイプが常に1つあります。その応答には、サーバーがクライアントに送信したいメッセージが含まれますが、それが適切な場合に限ります。クライアントはそれを受信し、すぐに新しいクエリを送信してチャネルを開いたままにします。
問題は、HTTP が要求応答プロトコルであることです。クライアントからリクエストが送信されない限り、サーバーはデータを送信できません。
リクエストをマッキングしてこれを回避しようとし、同じ元のリクエストに対して応答を継続的に送り返すことは、動作が HTTP に準拠せず、あらゆる種類の仲介者 (プロキシ、ルーターなど) とうまく機能しないため、欠陥があります。ブラウザーの動作 (Ajax 補完)。サーバー上でソケットを開いたままにしておくことは非常にリソースを集中的に使用し、ソケットは非常に貴重なリソースです (通常は数千しか利用できません)。
フローを逆にすることでこれを回避しようとする (つまり、プッシュするものがあるときにサーバーがクライアントに接続する) ことは、これに伴うセキュリティ/認証の問題のため、さらに欠陥があります (応答は簡単に乗っ取られたり、拒否されたり、スプーフィングされる可能性があります)。また、多くの場合、クライアントに到達できない (プロキシまたは NAT デバイスの背後にある) ためです。
私の知る限り、ほとんどのRIAクライアントはタイマーでポーリングするだけです。理想的ではありませんが、これが HTTP の仕組みです。
GWTは、この種のもののフレームワークを提供し、Cometと統合されています（少なくともJettyの場合）。JavaScriptの少なくとも一部をJavaで記述してもかまわない場合は、より簡単な方法かもしれません。