ブラウザ切断_JavaScriptスキルのB/S判定問題に関する議論

クライアントはスクリプトを介してリクエストを保持し、サーバーはその時間をチェックし、その時間が所定の時間を超えていることが判明した場合、クライアントのブラウザが閉じられたと判断できます。次に、対応する操作を実行します。どのクライアント ブラウザが閉じられたかを知りたい場合は、セッションをポーリング オブジェクトにバインドできます。すべてのサーバーが長時間接続をサポートしているわけではありません。この方法はあなたの方法よりもはるかに現実的です。
私の個人的な意見です。
私はまずこれらのアプローチに同意します 。それらはすべて、クライアントのポーリングを通じてサーバーの最終アクセス時間を更新し、サーバーにタイムアウトを検出させます。これら 2 つのメソッドについての私の理解を話させてください

1 サーバー側でタイムアウトを判断し、定期的なポーリングのためにバックグラウンド スレッドを開始するにはどうすればよいですか?各セッションが間隔を超えているかどうかをループして確認しますか?
2 スレッドを使用する場合、サーバーが判断する間隔またはサイクルは何ですか。1 秒、10 秒、20 秒...
3 全員が 10 秒の間隔を使用する場合、顧客もこの間隔を負担できます、結果を見てみましょう
1) 100G のファイルをダウンロードした場合、どのサーバーが長時間接続をサポートしていないのかわかりません。途中でn回切断する必要がありますか?
2) サーバーが応答するまで、各クライアントは 10 秒以内に新しいリクエストを発行する必要がありますが、私のクライアントではその必要はありません
3) ポーリング操作、つまり同期アクセス中の同時実行性の問題に注意してください。問題は、データをアプリケーションまたはその他のカスタム グローバル データ構造に保存する必要があることですが、マルチスレッドにはこの問題はありません
4) ポーリングはシングルスレッドで均一に処理されますが、長い接続はマルチスレッドです
5) リクエストを更新するたびにクライアントを切断すると、サーバーが占有する接続数が減り、同時実行数が増加しますが、各リクエストの負担が相対的に増加します。
4 主な違い: リクエストが 0.1 秒以内に行われなければならない場合 正確 接続が切断されていることが判明した場合は、すぐに処理する必要があります。ブラウザが短期間に 10 件のリクエストを発行するのは難しいため、マルチスレッド ソリューションの方が効果的だと思います。 。接続が長い場合は、データ送信の間隔を短くするだけで済みます。



概要:
要求によってアプリケーションが決まります。
システムが要求する判定タイムアウトが短いほど、長い接続ソリューションの利点が大きくなり、ポーリングの可用性が強化されます。アプリケーションに基づいて具体的な決定を行う必要があります。
一般的な B/S 判断に関しては、ほとんどのチャット ルームとオンライン人口統計は外出先での投票操作です。チャット ルームから退出した場合、オンライン リストはすぐには更新されませんが、IM プログラム (QQ/MSN) などは比較的正確に更新されます。

正確な判断が必要な場合は、長い接続が考えられる解決策の 1 つだと思いますが、もう 1 つはソケットを使用したアプレット、Flash、ActiveX などのクライアント プラグインです。しかし、メカニズムと長い接続には違いはありません。
2 つのヒント

1. 0.1 の応答を達成するのは問題ありませんが、0.1 秒の「正確な」応答を達成することは不可能です。 TCP プロトコルは長時間接続ですが、CS の一方の端が切断されたときに、もう一方の端がそれをすぐに知ることができるとは規定していません (そうしないと、後で TCP で標準ではない「ハートビート」プロトコルが存在しなくなります)。これは、中間ネットワーク ハードウェアのサポートに関連しています。これは現実にも当てはまります。 もちろん、モデレータがこの記事と上記の記事を書いたかどうかはわかりません。そのため、このシステムがどのようなネットワークで動作するかはわかりません。

2. 記事に「前のページ」と記載されていたので。このシステムは QQ サーバーやゲーム サーバーではないようです。おそらくバックグラウンドで通常の WEB サーバー、IIS または APACHE が実行されているようです。 。設計目標は明確であるため、接続数は最大になります。表面的には、数千人が同時にオンラインであっても問題ありません。接続が短いため、通常は同時接続数で十分です。ただし、クライアントが非アクティブであっても接続を維持する必要がある場合、この数はすぐに限界に達します。
ゲームや IM ツール (通常は QQ) でさえ、TCP を使用してサーバーに長時間接続することはできません。

つまり、私の結論は、最大でも 100 人か 200 人が同時にオンラインになるプロジェクトを計画している場合 (同時にアクティブになるのではなく)、元の投稿者の方法を使用できるということです。 。 Flash、activeX、socket…と人数が増えてくると長時間接続ができなくなるので、UDPを使ったほうが良いでしょう。