ユーザーがブラウザを介してチャットしたり、ファイルを相互に送信したりできるWebサイトを作成しています。私はUIにGWTを使用しており、mysqlデータベースバックエンドに接続するためにgileadで休止状態になっています。
ユーザーが一緒に対話できるようにするために使用するのに最適な戦略は何でしょうか?
ユーザーがブラウザを介してチャットしたり、ファイルを相互に送信したりできるWebサイトを作成しています。私はUIにGWTを使用しており、mysqlデータベースバックエンドに接続するためにgileadで休止状態になっています。
ユーザーが一緒に対話できるようにするために使用するのに最適な戦略は何でしょうか?
コメット/AJAX|サーバープッシュなどをお探しだと思います。いくつかの指針については、この問題に関する私の以前の回答を参照してください。基本的に、サーバーとクライアント間の通信の反転をシミュレートしています。たとえば、友人がオンラインになったばかりであることをユーザーに通知したい場合など、ここで接続を開始するのはサーバーです。
この手法の実装は非常に急速に変化するため、明確な推奨事項は作成しません。ニーズに最適なものを選択してください:)
COMETは、Webページを介したチャットを可能にするテクノロジーです。基本的には、キープアライブ接続を介して通信します。これにより、サーバーはクライアントに情報をプッシュできます。GWTを使用するクライアント側では、これをいくつか実装しています。最近のほとんどのサーバーはこれをサポートしています。これはサーブレット3.0仕様の一部でもあります(まだ誰も実装していません)
COMET は非常に優れていますが、それだけが解決策ではありません。時間間隔のある通常のポーリング (COMET ロング ポーリングとは対照的に) は、今でも一般的に使用されています。ユーザーによる手動更新を要求することもできます。
例として Stackoverflow を取り上げます。ほとんどの場合、変更を確認するにはブラウザを手動で更新する必要があります。一般に、それは正常であり、期待されていると認識されていると思います。COMET または頻繁なポーリングは追加のボーナスです。
COMET の問題は、サーバー上で多数のスレッドが簡単に発生する可能性があることです。ただし、まだ十分にサポートされていない非同期処理 (「高度な IO」とも呼ばれる) を追加で使用すると (たとえば、深刻なバグのために Glassfish v3 で HTTPS が機能しないなど)、Apache コネクタなどで問題が発生する可能性があります。 .
頻繁なポーリングの問題は、追加のトラフィックが発生することです。そのため、多くの場合、ポーリングの頻度を下げる必要があり、エンド ユーザーの利便性が低下します。
したがって、特定の状況に応じてオプションを比較検討する必要があります。