BlazeDS のプッシュ機能

１．Long Polling （使用するチャネル： AMFChannel）

この方法では、クライアントは通常の HTTP リクエストとしてポーリングをサーバに行います。サーバ側ではクライアントへ送るデータが無かった場合は、そのまま新しく送信するデータが利用可能になるまでレスポンスを保留します。（これがロングポーリングと呼んでいる理由です） クライアントはデータを受信すると次の受信に備えるため、直ちに新しいポーリングのリクエストをサーバに送信します。

クライアントが毎回リクエストを送る手間を除けばほぼリアルタイムのプッシュが実現できます。この方法の利点の一つは、一般的な HTTP のリクエスト・レスポンスのパターンを利用するため、ネットワーク環境について特別に心配する必要がないことです。

下はロングポーリング用チャネルの設定例です。

<channel-definition id="long-polling-amf" class="mx.messaging.channels.AMFChannel">
<properties>
  <polling-enabled>true</polling-enabled>
  <polling-interval-millis>0</polling-interval-millis>
  <wait-interval-millis>-1</wait-interval-millis>
  <max-waiting-poll-requests>300</max-waiting-poll-requests>
  ...
 

まず polling-enabled を true にしてポーリング機能を有効にしています。次の行では polling-interval-millis に 0 を指定することでクライアントがデータを受信したら直ぐ （待ち時間が 0） 次のポーリングを行うよう設定しています。

サーバ側は、wait-interval-millis を -1 にすることで、ポーリングに対するデータが利用可能になるまでずっとレスポンスの送信を保留するようになります。ここまでがロングポーリングの基本設定です。

ロングポーリングで注意が必要なのは、返事を保留しているリクエストの数だけサーバのスレッドがブロックされてしまうという点です。無制限にポーリングリクエストを受け付けたりすると、全てのスレッドが保留状態になってサーバが新規リクエストを一切受け付けられなくなってしまうかもしれません。

そこで、上の例では max-waiting-poll-requests を使い、受け付けられるポーリングリクエストの最大値を 300 に指定しています。実際には、この数値はアプリケーションサーバのスレッドの最大数と、スレッドの使われ方を基準に決定することになることと思われます。

あとは、不要に長時間スレッドを占有する状態を避けるため、wait-interval-millis に例えば 60,000 （1 分） 程度の値を設定して、一旦サーバ側のリソースを開放するという方法も効果があるかもしれません。

なお、同じ HTTP セッションを使って複数のポーリングリクエストを行うことはできません。（サーバ側で制限しています） 例えば、複数の Flash Player インスタンスを同一ブラウザ内で起動する場合、一時点では、どちらか片方のみがロングポーリングを利用できます。

この方法では、サーバがデータをプッシュする度に、クライアントがポーリングリクエストを送るという「余分な」負荷がかかります。沢山のクライアントに頻繁にデータを送るケースではあまり向かない（効率が悪くなる）可能性もあるということですね。

ちょっと長くなったので、続きはまた次回。