今日は、 Cometとサーバープッシュについて一般的に説明します。
サイトなどの従来のWebアプリケーションは、従来の要求/応答/要求モデルに従って動作し、HTTPプロトコルの機能とハンドラーの一部のサーバー実装により、アプリケーションは要求間で情報を保存しないため、各呼び出しは独立しており、識別または、セッションサポートは、高レベルのツール（たとえば、PHPでよく知られているセッションの実装）によって提供されます。 さらに、新しい情報の要求は、常に最新バージョンのデータの取得に関心のあるクライアントから送信されます。 更新が重要なアプリケーションでは、これがボトルネックになることがよくあります。 以前のプロジェクトの1つでは、データを一度に更新するためのいくつかの定期的なAJAX要求がありました。 この場合、クライアントからの単一のリクエストでサーバー側のいくつかのハンドラーを呼び出すオプションがありますが。
しかし、別のアプローチがあります。サーバーが独自に新しいデータがあると判断し（そして、最初にそれについて学習し）、それをクライアントプログラムに配信します。クライアントプログラムは、リクエストに時間を浪費せず、新しいものが現れたときにそれを受け取ります。 ただし、このためには、たとえば双方向ソケットを介して、サーバーへの接続を一定に保つ必要があります。 また、従来のソフトウェアでこれに特別な問題がなければ、Webアプリケーションに長期の永続的な接続を実装することは非常に困難です。 これは最も原始的な方法でIFrameを介して行われますが、これが唯一の可能性ではなく、トップライブラリとプラグインの開発者がそれを試しましたので、お気に入りのフレームワークを見て、Comet実装がそこにあるはずです（間違いなくDojo Toolkitにあり、jQuery用のプラグインがあります、GWTの組み込み機能）。 また、この資料セットのさまざまな実装方法について読むこともできます。
しかし、サーバーの作り方は？ Apache + PHPの通常のバージョンはあまり適していませんが、もちろん可能ですが、ソリューションは最適とはほど遠いものであり、一般的な負荷に耐えられません。 負荷といえば。 Cometアプリケーションの場合、負荷は同時に処理できるクライアントの数です。つまり、データ転送ではなく、クライアントとの開いている接続の数です。 そして、通常のサーバーでのそのような接続の数は、数万、典型的な数-20-5万の並列接続に達するはずです。 そして、ここではApache / PHPバンドルは役に立ちません。 他に何かが必要です。
Javaの世界では、たとえばJetty（おそらくCometの最も有名で標準的な実装、IBMによるロシア語の良い記事 ）、 Grizzle - Atmosphere プラットフォームに基づくサーバーフレームワークなどのアプリケーションサーバーの実装があります。特定のアプリケーション用のサーバーは難しくありません。
他に何をする？ オープンAPEプロジェクトまたはAjax Push Engineを推奨できます。 これはCで書かれた小さなサーバーで、デーモンとしてコンパイルされ、そのポート（デフォルトでは6969）をリッスンしますが、Apacheで動作するように構成することもできます。 他のソリューションとは異なり、APEはGET / POSTリクエストをサポートする特殊なHTTPサーバーです。つまり、HTTPリクエストのみが理解されていれば、どの言語やシステムからでもサーバーに接続できます。 これは自給自足のソリューションであり、原則として、追加のサーバーなしでAPEのみに制限できます（Jettyでは、実装にはアプリケーションサーバーとWebサーバーが必要です）。 開発者によると、APEは負荷がかかっても問題なく機能し、同時に最大10万の接続を保持でき、将来的には水平スケーリングが追加される予定です。
そのアーキテクチャでは、APEプロジェクトは次の3つの部分で構成されていることに注意してください。
- epoll駆動のHTTPサーバーはまさに基盤であり、接続を処理して接続を維持するサーバーであり、 XHRロングポーリングであろうとiframe経由であろうと、クライアントに適した方法でサーバープッシュを実装でき、将来的にはネイティブブラウザーが利用されます（たとえば、 Webソケット）
- APE JavaScriptフレームワークは、プロジェクトの同様に重要な部分であり、サーバー機能を任意のAJAXクライアントアプリケーションに統合できるMooToolsに基づくクライアントスクリプトです。 また、モジュラーシステムと拡張機能も実装しているため、別のライブラリのラッパーを最上部に記述するか、ソリューションに透過的に埋め込むことができます。 ライブラリはソケットとパイプの模倣を実装しているため、開発者はかなり高レベルの抽象化を取得できます。さらに高度に上昇すると、イベントモデルが利用可能になり、実装の詳細を簡単に忘れることができます。
- プラグインシステム -プラグインを介して独自の機能を追加することにより、サーバーを拡張できます。 現在はCモジュールを介してのみ使用できますが、それらは非常にシンプルであり、将来的にはサーバー側のJavaScriptが期待されます。これは本当に素晴らしいソリューションになります（もちろん、PHPを台無しにすることもできますが、もちろん、単純なCプラグインを介して行うことはできますが、それでも）
サーバー側では、APEはepollエンジンとハッシュテーブル実装（DJBハッシュアルゴリズム）を使用します。 これは、最大のパフォーマンスに加えて、移植が困難になります-サーバーはLinuxカーネル2.6.19+およびlibc6-devをビルドしたいので、これまでのところCygwinでビルドすることに成功していません（ストッパーはカーネルに組み込まれたepollメカニズムの点で正確です） ）
APEは、サーバーとクライアント間、およびクライアント間（サーバー経由）で情報を交換するためのいくつかの方法を実装しています。 最初のチャネルは、ユーザーが特定のチャネルをサブスクライブし、このチャネルに関連する新しい情報がサーバーに表示されると、チャネルをリッスンするすべてのクライアントに送信されます。 したがって、すべての顧客に新しいデータをすぐに送信できます。これは無制限の数です。 また、APEはメモリに保存されたメッセージのキューとして使用できます。接続された各ユーザーには1つ以上のキューがあります。 メッセージの受信者はチャネルのいずれかである場合があり、そうすると全員が直接、別のユーザーまたは外部サービスのいずれかでメッセージを受信します。 チャネルは、対話型または読み取り専用のいずれかです。
APEはプロキシサーバーの役割を引き継ぎ、外部サービス（アプリケーションサーバーなど）とメッセージを交換したり、それらからデータを受信したり、チャネルまたは特定のユーザーに送信したりできます。 したがって、ユーザーのフロントエンドがAPEになり、接続を処理し、バックエンドサーバーが動作し、内部APEプロトコルを使用してメッセージの形式でデータを送受信するシステムを構築できますが、接続されたクライアントの数は何も知りません、彼はAPEサーバーと通信できる必要があるだけです。
クライアントとサーバーの相互作用は特別なプロトコルを通してされます 。 ユーザーは、サーバーがRAWデータ（通常はJSON）を送信するのに応答して、メッセージを送信したり、接続を作成したりするなどのコマンドを開始できます。 ただし、サーバーモジュールは組み込みコマンドセットを拡張できるため、ニーズに応じて独自のアクションセットを記述できます。
公式ドキュメントはまだ開発中です（もちろん、これはwikiです）が、利用可能なモジュールについては報告していませんが、ソースリポジトリにはいくつかの基本的なモジュールがあります。これらは、ソリューションの開発と既存のインフラストラクチャへの組み込みの両方のリファレンスツールとして役立ちます。 たとえば、libape-mysqlを使用すると、データベースに接続してそこから新しい情報を取得できます（ただし、モジュールバージョンは0.01であることに注意してください）。libape-chatは、シンプルなチャットシステムのデモバージョンを表示します。 最も興味深い約束はlibape-spidermonkeyになることですが、これまでのところ情報源以外には情報がありません。
このプロジェクトは非常に若いですが、すでにその可能性が示されているため、多くのユーザー（チャットまたはゲームシステム）との同時作業を必要とする深刻なアプリケーションを開始する場合、またはデータ配信が重要な場合は、APEに注意することをお勧めします。
PS Win32システムで誰でもこのサーバーを構築できる場合-ソリューションを共有してください！