ユーザーがグループを作成し、それらのグループ内でチャット/投稿できるサイトを作成しようとしています。ただし、グループ内で投稿/チャットが行われた場合、ユーザーがそのグループ内のこれらの新しい投稿/チャットを表示するためにページをリロードする必要はありません。私の質問は次のとおりです。これを行う方法 (言語、Web サービスなど) について、あなたの最良の意見は何ですか?
私は PHP、SQL、HTML、CSS をよく知っていますが、XML、Javascript、AJAX はあまりよく知りません (コードを読んで、それらがどのように機能するかを理解するには十分に遭遇しましたが、決して熟練したり、自信を持ったりすることはできません。私が説明した種類のサイトを構築するには、これらのいずれかまたはすべてに関する本を読む必要があると感じています.)
あらゆるご意見をお待ちしております。
Web は、クライアントが要求を行い、サーバーがリソースで応答する典型的な要求/応答モデルをうまく処理します。ただし、クライアントがデータを要求せずにサーバーがクライアントにデータを送信する必要があるアプリケーションに関しては、ここで創造性を発揮する必要があります。
リアルタイムの Web ベースのアプリケーションを容易にするために使用できるいくつかの異なる方法があります。
ポーリング:
ポーリングでは、更新を受信するために、クライアントが定期的にサーバーに要求を送信します。このアプローチには 2 つの主な問題があります。まず、サーバーが非常に長い間プッシュするデータがない可能性があります。したがって、更新のためにサーバーをポーリングし続けるために、大量の帯域幅が浪費される可能性があります。次に、ポーリング レートによって、アプリケーションのリアルタイム性が決まります。ポーリング レートが速いと更新が早く表示されますが、帯域幅が無駄になります。逆に、より長い間隔でポーリングすると使用する帯域幅は少なくなりますが、更新がそれほど速く表示されないという欠点があります。
一般に、これは 2012 年のチャット アプリケーションに使用するには非常に不適切なソリューションです。
コメット/リバース AJAX:
コメットは、リクエスト/レスポンスの概念を採用し、ハックを使用してリアルタイム効果をシミュレートするために、過去 5 年間で成功裏に使用されてきた手法です。Comet の背後にある一般的な考え方は、クライアントがサーバーに要求を送信し、サーバーが接続を無期限に開いたままにするというものです。サーバーは、クライアントに送信する更新があるまで待機します。更新の準備ができると、サーバーは応答を送信します。これは、サーバーがクライアントに要求を行うことをシミュレートします。クライアントが応答を受信すると、新しい接続が開かれ、プロセスが繰り返されます。
この手法は、待機中のスレッドが他のタスクのために解放されることを保証する継続と組み合わせると、一部のプラットフォームで 20,000 を超える同時接続にスケーリングすることが示されています。
これにより、帯域幅が節約されるだけでなく、アプリケーションが非常にリアルタイムに感じられるようになります。
ウェブソケット:
Websockets は HTML5 で Comet の代替として導入され、http の代わりに ws:// プロトコルを使用します。ただし、これはまだすべてのブラウザー ベンダーによって広く採用されているわけではなく、プロトコルの仕様に関してはまだ議論が行われている可能性があります。コメットと同じメリットがたくさんあります。
Comet の詳細については、Comet と PHP、および PHPでの Comet の課題を参照してください。クライアント・サイドの統合については、Dojo Cometd Libraryを調べてください。
AJAX がこれを行うための最良の方法であると言っていました。または、リロードする iframe を作成します