7

Web指向のアプリでエレガントなPub-Subアーキテクチャを開発することは、実際の課題です。長いポーリング接続（COMETなど）と反復タイムアウト（js setTimeoutなど）を使用した非常に興味深いソリューションがいくつかありますが。IMHO AJAXプッシュは、無実のHTTPプロトコルを強制する微調整とハッキングのレイヤーのように見えます。

では、AJAXはHTTPプロトコルの異常をプッシュしていると思いますか？

Webアーキテクチャで検討できる他の選択肢はどれですか？

4

4 に答える 4

5

私が以前に使用した別のオプションは、小さな隠しJavaまたはFlashを使用して、プレーンソケットを介してリモートサーバーに接続することです。サーバーは、クライアントからのポーリングなしで、いつでもこれらのソケットを介してデータ/イベントをプッシュできます。

Flashは、署名されたアプレット（ユーザーにセキュリティ警告をポップアップ表示する）を必要としないため、少し優れたIMOです。なんらかの形で9年間ソケットがありましたが、Flash 9 / AS3までは、あらゆるタイプのサービスに接続するために使用できる「純粋な」ソケットを入手していました（以前はメッセージが'null'パケットで終了しました。つまり、XMPP、SMTP、または既存のプロトコルを使用する代わりに、フラッシュ専用のプロトコルを設計する必要がありました）

于 2010-02-23T00:06:12.597 に答える
4

Webアーキテクチャで検討できる他の選択肢はどれですか？

HTML 5 Web Sockets APIとサーバー送信イベントは、将来的に有望に見えます。Web Socketsに対するIEのサポートはまだありません。また、サーバーから送信されたイベントはまだ実験段階です。Douglas CrockfordのJSONRequest提案も、AJAXプッシュの興味深い代替手段ですが、最新のブラウザーにはまだ実装されていません。

とりあえずコメットにこだわる。

于 2010-02-22T23:43:05.147 に答える
2

ポーリングは、pub-subを実行するWebアーキテクチャの方法です。クライアントが頻繁にポーリングせず、応答をキャッシュして共有できる場合（たとえば、ブログのrssフィード）にうまく機能します。cometのように、クライアントごとにtcpソケットを開いたままにしておくことは、httpを使用する理想的な方法ではありません。ただし、アプリがWebブラウザーで実行され、クライアントごとに頻繁に一意の更新が必要な場合、それは悪い方法ではありません。

クライアントごとのリソースのCometとポーリングは、httpまたはWebを完全に悪用するわけではありません。httpとWebは、多くのクライアント間で同じリソース（つまり、Webページ）を共有するように特別に設計されているため、これが最適な方法です。 。

于 2010-02-23T00:25:12.630 に答える
1

最も一般的なCometの実装について考えてみてください。ブラウザをだまして、マルチパート応答またはiframe内の無限に長いHTMLを受信して​​いると思わせるだけで、これが適切なテクノロジーであるかどうかのフラグを立てるのに十分です。仕事で。

于 2010-02-23T10:34:49.927 に答える