Google App EngineでBlazeDSによるプッシュを試みる
GAEを使ってBlazeDSによるデータプッシュを試みたが、結果は撃沈だった。
一連の詳細はみさぽんがあげてくれている。
「Google App EngineでBlazeDSのRemoting通信を試す」
「Google App EngineでBlazeDSのMessagingを試す」
「Google App EngineでBlazeDSのLong Polling機能を試す」
「Google App EngineでStreamingAMFChannelが使えたかとぬかった」
BlazeDSを使用する時の主なエラーは、セッション関連とスレッド関連だった。
スレッド関連の問題はGAEのセキュリティーサンドボックスの問題で仕方ないと思う。しかし、これはBlazeDSのソースを変更することで何とかなった。
しかしセッション関連はどうにもならなかった。GAEは分散環境なので、そもそもコネクションを張り続けるという事ができないようなのだ。恐らく、リクエストのたびに違うサーバーが処理しているとのだと思う。
この事がわかり、グーグルに考え方を変えろと言われている気がした。
「１クライアントにつき１秒間に１回かそれ以上のリクエストを処理できれば、それはコネクションを維持してデータをプッシュしているのと変わらないだろ？」と。
プルはダサいと考えていたが、どうやら考え方を変える必要があるようだ。
一連の詳細はみさぽんがあげてくれている。
「Google App EngineでBlazeDSのRemoting通信を試す」
「Google App EngineでBlazeDSのMessagingを試す」
「Google App EngineでBlazeDSのLong Polling機能を試す」
「Google App EngineでStreamingAMFChannelが使えたかとぬかった」
BlazeDSを使用する時の主なエラーは、セッション関連とスレッド関連だった。
スレッド関連の問題はGAEのセキュリティーサンドボックスの問題で仕方ないと思う。しかし、これはBlazeDSのソースを変更することで何とかなった。
しかしセッション関連はどうにもならなかった。GAEは分散環境なので、そもそもコネクションを張り続けるという事ができないようなのだ。恐らく、リクエストのたびに違うサーバーが処理しているとのだと思う。
この事がわかり、グーグルに考え方を変えろと言われている気がした。
「１クライアントにつき１秒間に１回かそれ以上のリクエストを処理できれば、それはコネクションを維持してデータをプッシュしているのと変わらないだろ？」と。
プルはダサいと考えていたが、どうやら考え方を変える必要があるようだ。
"Make It Simple"で考えればプル＝ダサくないということなのでしょうねぇ。分散処理を考えてもプルにしないと難しい面も多そうです。
返信削除Make It Simpleで考えると、確かにダサくないですね。むしろイカしてるかも？
返信削除携帯をプラットフォームとして考えたら、ずっとコネクションを張り続ける事は難しいだろうし、そうなると結局プルということに。
環境を選ぶプッシュより、より広く簡単に動作するプル、ということなのかもですなぁ。