cometdaily.comによると、クライアントとサーバー間の双方向のデータ交換をエミュレートするためのソリューションがいくつかあります。
- ロングポーリング-サーバーはXHRリクエストにすぐに応答しませんが、このソース（「インテロゲーター」）宛てのキューにイベントが到着したときにのみ応答します。
- Forever frame-iframeを作成します。サーバーは、イベントが到着すると常にイベントを追加します。
- スクリプトタグ-動的に作成されたJSブロック。これにより、クロスドメイン通信が可能になります。
- ActiveXObject（「htmlfile」）-IEで使用可能なメソッドとActiveXを使用
- JSONRequestオブジェクト（ www.json.org/JSONRequest.html）-2つの同時要求（1つは送信用、もう1つは受信用）による双方向接続を実装します。
さらに、FlashオブジェクトまたはJavaアプレットを使用できます。 そして、写真を完成させるために、Forever GIFのような古代のテクニックに言及することができます。
私からは、いくつかの高レベルのソリューションを追加します。
- Bayeuxプロトコル（ svn.cometd.com/trunk/bayeux/bayeux.html Dojo Foundation） -1つのクライアント-多くのサーバー、1つのサーバー-多くのクライアントのスキームに従ってイベントを交換できます。 特に、CometDプロジェクト（www.cometd.com）で使用されています。
- BOSHプロトコル（http://xmpp.org/extensions/xep-0124.html XMPP標準基盤）-2つの同期HTTP接続を使用して、ブラウザーとサーバー間の双方向データストリームをエミュレートします
- Lightstreamer（ www.lightstreamer.com ）は、データをリアルタイムで「リッチ」アプリケーションに「プッシュ」するためのスケーラブルで信頼性の高いサーバーです。
- APE（Ajax Push Engine）（ www.ape-project.org ）は、MooTools、Dojo、jQueryでサポートされている軽量のオープンソースプッシュサーバーです。 Habré（ habrahabr.ru/blogs/webdev/60803 ）の詳細をご覧ください。
ネイティブソリューションを使用する場合、これらのアプローチのいずれかが多かれ少なかれハックであることに注意してください。 HTML5ワーキンググループのメンバーは明らかにこの状況をよく理解しているため、Web Socketsなどの標準が標準に導入されています。 その説明は万能薬のように聞こえます：ファイアウォールとルーターに耐性があり、クロスドメイン通信を許可し、既存のHTTPロードバランサーと統合し、バイナリデータの交換を許可し、安全な接続で動作します。 これらすべてにより、Web Sockets APIは非常にシンプルです（ habrahabr.ru/blogs/webdev/79038も参照 ）。
Hooray、ありがとう、みんな無料ですか？ しかし、違います。 現在、Web SocketsはChromeの開発バージョン（ 4.0.249.0-www.chromium.org/getting-involved/dev-channelから）でのみサポートされており、Firefox 3.7でサポートが約束されています。 今何をする？ 明らかに、回避策がない場合、Web Socketが存在する場合に「ネイティブ」APIを使用するクライアント側のファサードが必要です。 そのようなソリューションは、お金のためではなく、魂の親切のために配布された場合、Kaazing Websocket Gateway（ kaazing.com/download ）になります。 Web Socketsに加えて、amqp、imap、irc、ldap、smtp、ssh、stompへのアクセスが確実に必要な場合は、Orbited（ orbited.org ）をio.js（ github.com/mcarter/js.io ）と一緒に使用できます。通信をプロキシするサーバー上のtelnet、xmppおよびPython。 私の選択：WebSocket.js（ github.com/gimite/web-socket-js ）。 小さなJSライブラリとFlashオブジェクト形式のブリッジ。
これでWebSocketサーバーのみが必要になり、私たちの場合（バックエンドはJavaで記述されています）、Jettyはバージョン7.0.1からこれに最適です（現時点ではステータスはほぼ安定していますが、いつ怖がりましたか？）。 サーバーアプリケーションがphpで作成されている場合は、phpwebsocket（ code.google.com/p/phpwebsocket ）またはPhpwebsockets（ code.google.com/p/phpwebsockets ）を使用してみてください。 しかし、両方のソリューションは実験的であるため、ユーザー自身の危険とリスクがあります。
更新：phpDaemon habrahabr.ru/blogs/php/79377でのチャット実装例
Jettyをインストールしても問題は発生しませんが、Adobeのいわゆるクロスドメインポリシーにより、WebSocket.jsで問題が発生する可能性があります。 Flashオブジェクトがサーバー上のソケットを開くことを許可する必要があります。 最も信頼できるソリューションは、ポート843でマイクロサーバーをホストすることです 。これは、 www.lightsphere.com/dev/articles/flash_socket_policy.htmlで説明されているように、適切なXMLでポリシー要求に応答します。 この記事では、最もシンプルなXMLサーバーについても説明しています。 しかし、私はそれがあまり好きではなく、 devzone.zend.com/article/1086の例に基づいてソケットサーバーを作成しました。
Webソケットができたので、サーバーイベントに即座に応答できるWebアプリケーションを作成できます。 Facebookなどの通知システム（通知）、Google Waveスタイルのユーザーインタラクション用サービス、リアルタイムモニター（オンラインのユーザーなど）、または着信SMSやイベントなどのサードパーティのイベントソースとの統合が可能です。デスクトップアプリケーションで。 さまざまなソースからさまざまなクライアントに向けたさまざまなイベントが予想されるため、サーバー上に信頼できるメッセージフロー制御システムが必要です。 シンプルだがエレガントなSTOMPプロトコル（ stomp.codehaus.org ）があります。 APIには、STOMPクライアントとSTOMPブローカーが通信する少数のコマンド（SEND、SUBSCRIBE、UNSUBSCRIBE、BEGIN、COMMIT、ABORT、ACK、DISCONNECT）のみがあります。 特に、Zend Queue（ framework.zend.com/manual/en/zend.queue.stomp.html ）にはSTOMPアダプターがあります。 メッセージブローカーは、Apache ActiveMQ（ activemq.apache.org ）またはRabbitMQ（ www.rabbitmq.com ）に基づいて実装できます。
ただし、非常に深刻な場合は、より開発された柔軟な（ habrahabr.ru/blogs/webdev/62502 ）プロトコルAMQP（ www.amqp.org ）に注意する必要があります。
JBOSSコンテナであるJettyは、Webソケットを提供します。 AMQPアラートをWebソケットにブロードキャストするには、別のコンテナーを使用するだけです。 このためには、AMPQのブローカーの1つをインストールする必要があります。 ZeroMQ（ www.zeromq.org ）は最速と見なされます。 Qpid（ qpid.apache.org/amqp-brokers.html ）は非常に人気があり、Apacheプロジェクトから期待されています。