2

Webサーバーは着信HTTPリクエストに応答して動作します...リクエストを処理してHTTPレスポンスを返します。サーバーがこのアーキテクチャのクライアントにデータをプッシュできる一般的な方法はありますか...たとえば、リクエストがclient1から着信し、サーバーがclient2に通知したい場合はどうでしょうか。明らかに、ソケットを使用して非Webサーバーで実行できますが、ページ要求をサポートし、データのプッシュを許可する必要があるWebサーバーアプリについてはどうでしょうか。

4

4 に答える 4

1

ページリクエストをサポートし、データのプッシュを許可する必要があるWebサーバーアプリについてはどうでしょうか。

サーブレット3.0では、Cometスタイルのアプリケーション（つまり、長寿命のHTTP接続と長いポーリングまたはストリーミングのいずれかを使用するアプリケーション）を作成できる非同期サポートが導入されています。

サーブレット3.0非同期サポートを待つことができず、コンテナー（GlassFish、Jettyなど）からの独自のCometまたはWebSocketサポートを使用したくない場合は、Atmosphereを参照してください。

も参照してください

于 2010-06-02T13:15:37.573 に答える
1

Webの世界がこの新進気鋭の標準に追いつくのを待つことを気にしないのであれば、 WebSocketsをサポートするJettyのようなWebアプリコンテナーを使用できます。そうすれば、HTTP +ポーリングや特別なプラグインなどの代わりに、実際の双方向通信が可能になります。

于 2010-06-02T13:05:21.773 に答える
0

もう1つの可能性は、これを実現するためにHTTPキープアライブを悪用することです。背景については、http：//en.wikipedia.org/wiki/HTTP_persistent_connectionを参照してください。シナリオではclient2、サーバーへの接続を開始し、サーバーは通知をリッスンして開いたままになります。

これは優れたソリューションではありません。まず、長期間有効なTCP接続を多数保持する必要があります。接続が失われた場合、サーバーを再接続する方法はありません。クライアントが戻るのを待つ必要があります。

于 2010-06-02T13:16:44.703 に答える
0

いいえ、クライアント側の技術（Flash、Silverlight、アプレットなど）がないわけではありません。

ただし、ページにAJAXを使用してサーバーをポーリングさせることもできます。

于 2010-06-02T12:27:52.117 に答える