引き続き BlazeDS を使ったサーバからのプッシュ機能の設定のご紹介です。
2.ストリーミングチャネルの使用 (使用するチャネル: StreamingAMFChannel)
この方法では、クライアントが HTTP リクエストをサーバに送ってクライアント・サーバ間の接続を確立すると、サーバはその接続をデータプッシュ専用のチャネルとして張りっぱなしにします。サーバからのデータは HTTP 1.1 の Transfer-Encoding: chunked を使って送信されます。(そのため HTTP 1.0 クライアントはこの方法が使えません)
ロングポーリングではサーバがデータをプッシュする度にクライアントは新しいポーリングリクエストを送りなおす必要がありましたが、ストリーミングチャネルでは一度リクエストが送られると後はサーバからのプッシュのみ繰り返しになります。ポーリングによるオーバヘッドが無いことや、より遅延の少ないデータ配信が可能であることはこの方法の利点と考えられるでしょう。
下はストリーミングチャネルの設定例です。
<channel-definition id="my-streaming-amf" class="mx.messaging.channels.StreamingAMFChannel"> <properties> <idle-timeout-minutes>0</idle-timeout-minutes> <max-streaming-clients>100</max-streaming-clients> <server-to-client-heartbeat-millis>5000</server-to-client-heartbeatmillis> ...
idle-timeout-minutes に 0 を指定するとチャネルがタイムアウトにより閉じられることがなくなります。これで、ずっとチャネルを開きっぱなしの状態が実現されます。
ストリーミングチャネルも接続されているクライアントの数だけサーバのスレッドを占有します。そのため max-streaming-clients を使ってストリーミング用に使用できるスレッドの最大数を指定するようにします。上の例では 100 が設定されています。
貴重なスレッドを不要なのにも関わらず使用していたら効率がよくありません。そのため、サーバからクライアントがちゃんと接続されているか確認信号を送ることができるようになっています。server-to-client-heartbeat-millis に正の値 (単位はミリ秒) を指定するとこの機能が利用できます。上の設定では 5 秒おきにハートビートが送信されます。
ところで、ストリーミングチャネルでは、一回のリクエストに対して複数回に渡りレスポンスを送るという構造になるため、サーバとクライアント間のネットワーク構成の影響を受ける可能性があります。例えば、間の HTTP プロキシがデータをバッファしてからクライアントに送るような環境では、リアルタイムのプッシュが実現できません。
そのため、idle-timeout-minutes には 0 でなく 2 や 3 (単位は分) を指定して、「データは送られているがクライアントには届いていない状況」を判別できるようにしたほうが安全だと考えることができます。その場合は、クライアント側では「届いていないと判断されてチャネルが閉じられてしまった場合」に備えて、ChannelSet に 2 次利用できるチャネル (ポーリング AMF チャネル等) を指定しておく必要がありそうです。
このようにストリーミングチャネルは動きに少し癖があります。最初にご紹介したロングポーリングの方が一般的には使いやすいかもしれませんね。
3 つめの方法は、また次回。
コメントする