Facebookが通知を処理する方法をリバースエンジニアリングしようとしています。メッセージを受信すると、ブラウザーを介して即座に通知されます。
私はそれを少しいじりましたが、サーバーから何らかの更新を行う場合、保留中のGETリクエストが常に「リッスン」していることに気付きました。これは、ある種のオブザーバー パターンのようです。このパターンがどこかに文書化されているかどうか疑問に思っていました。
Facebookが通知を処理する方法をリバースエンジニアリングしようとしています。メッセージを受信すると、ブラウザーを介して即座に通知されます。
私はそれを少しいじりましたが、サーバーから何らかの更新を行う場合、保留中のGETリクエストが常に「リッスン」していることに気付きました。これは、ある種のオブザーバー パターンのようです。このパターンがどこかに文書化されているかどうか疑問に思っていました。
この手法は、実際にはLong Pollingと呼ばれます。これは、従来のポーリングの制限を回避するための一般的なComet手法の 1 つです。
非常に単純な例については、次のスタック オーバーフローの投稿を確認してください。
アップデート:
上記に加えて、技術の詳細な説明については、次の Stack Overflow 投稿に対する受け入れられた回答を確認することをお勧めします。
この手法はコメットと呼ばれ、別名「サーバー プッシュ」です。
現在、comet を実装する主な方法は 2 つあります。
1) ダニエルが述べたように、ロング ポーリングでは、ajax を使用して、サーバーが決定するまで応答を返さないハング リクエストをブラウザに残すことができます (他の誰かのアクションまたは別のサーバー イベントに基づくかどうか)。 .
2) Google が使用する 2 番目のアプローチはストリーミングです。これには、ajax を使用して保留中の要求を残すことが含まれますが、応答が返されることはありません。代わりに、サーバーがデータのビットを更新し、javascript を使用して変更を監視し、プッシュされた新しいデータに基づいてイベントを発生させます。何が起こるかというと、決して閉じることのない 1 つの非常に長い連続したデータ ストリームがドキュメントに流れ込み、新しいデータを取得します。入ってくるデータ。
HTML5 には、Web ソケットでこれを行うためのより簡単な方法の仕様があります。将来的には、Web ソケットが使いやすいため、このタイプのライブ Web アプリが一般的になるでしょうが、まだすべてのブラウザーでサポートされているわけではありません。
実稼働用に Comet サイトを構築する場合は、次のいずれかのようなノンブロッキング I/O 非同期サーバーを使用する必要があります。
http://www.tornadoweb.org/ - パイソン
http://nodejs.org/ - サーバー側の JavaScript
-- または彗星サーバーのグーグル。
サーバー側でコメット タイプのアプリをプログラミングする方法を知っておく必要があります。Comet の JavaScript は非常に簡単で、2 つのイベント ハンドラーを使用した通常の ajax 呼び出しだけだからです。