スティルハウスの書庫

#appengine でComet！ Channel APIでpushできるぞ

#io2010, GAE

Google I/O 2010ではApp Engine関連の大きな新機能発表がいくつかありましたが、「Channel API」もそのひとつ。これは「Webブラウザとのpush通信（comet）のためのAPI」です。

ついにpushできるよ！

これまでApp Engineにおいてクライアントへのpushを行うには、

• XMPPプロトコルを通じてのXMPPクライアントへのメッセージ送信
• URLFetchを用いて外部のpushサーバー（WebSocket対応サーバーとかTornadoとか）経由でへWebブラウザにpush（例：松尾さんのwebsocket連携）

のいずれかしか手段がありませんでした。

しかしXMPPクライアントの実装は容易ではなく、とりわけApp Engine側のXMPPサーバーとしてGoogle Talkサーバーを用いる場合はTLS通信が必須となり、利用可能なクライアントが極端に限られていました。私もWindowsネイティブのXMPPクライアントとApp Engine間のpush通信には成功していましたが、例えばFlash上にオープンソースのXMPPライブラリを載せてもうまくGTalkサーバーに接続できず、どうしたものか。。と悩んでました（実案件ではさくっとApp Engineを捨ててEC2＋Tornadoを選びましたw）

Channel APIは、そんなApp Engineのアキレス腱であったpush通信をcometで実現する機能です。クライアントとしてはWebブラウザ上で動作するJavaScriptクライアントのほか、Flashクライアントからも利用でき（るはずだろう普通のcometだしとGooglerが答えて）ます！

リンク集

• Google I/O 2010 - What’s hot in Java for App Engine - YouTube
• Live Wave: What’s hot in Java for App Engine
• App Engine at Google I/O 2010: Google App Engine Blog
• Dance Dance Robot!（Channel APIのpush通信によるゲームデモサイト）
• dance-dance-robot - Google Code（そのソース）

Channel APIの概要

• チャネル型の双方向非同期通信サービス
  • 「ついさっきprodに載せた」と言ってましたが、まだ公式APIとしては未公開
    • robotのリポジトリにある.jarには入ってるらしい。。？

• 現在はGoogle Talkサーバーのcomet機能を利用してpushを実現
  • よってスケーラビリティは極めて高い
  • cometでつなぎっぱなしにしたソケットでMXHRを流しているらしい（thx! > @monjudoh）
  • 将来的には同じAPIのままWebSocketに対応予定

• クライアントAPI
  • JavaScriptで実装
  • メッセージ受信時にコールバックするAPI
  • GWT向けJavaラッパーも提供予定
  • 基本cometなので、Flashやその他のJavaScriptでも動くはず。試して！（googler談）

• サーバーAPI
  • アプリ毎にユニークなキーでチャネルを作成
  • クライアントとの間でチャネルを作成したら、ChannelMessageで通信
  • UTF-8文字列を送受信可能（オブジェクトのシリアライズも可）
  • Defered.Defferable
    • Pyのdefferedのようなもの？
    • オブジェクトをシリアライズし、TQでコールバック

dance-dance-robotデモ

セッションではChannel APIを利用したゲーム Dance Dance Robot!のデモが行われました。その場にいた聴衆も参加してゲーム大会開始！ロボットの手足を動かすと、他の参加者にもリアルタイムに動きが伝わります。

• dance-dance-robotデモの特徴
  • Webブラウザ上で動作するGWTクライアント
  • GWT RPCでサーバーのChannel Serviceに接続、リアルタイムにメッセージを送受信
  • アプリ内の各種処理の実行にはTask Queueを多用
  • ゲーム終了時に出てくる賞状画像はBlobstoreで生成

鬼スケーラブルなメッセージングサーバーがタダで使えるなんて。。

というわけで、もうXMPPとかAmazon EC2のFMSサーバーのことは忘れてください。Tornadoを立てる必要もありません。あとでWebSocketな世の中になったときでも、クライアントやサーバーのソースはそのまま使えます。オンラインチャットやコラボレーションツール、ゲームなどの通信サーバーとしてApp Engineが強力な選択肢になったわけです（ただし、データセンターが北米にあることによるレイテンシの問題があるので、対戦型のオンラインゲームには厳しいかも）。

またエンタメ系に限らず業務系でも、例えばひとつのデータを複数ユーザーで共有して同時編集するようなwave的UIの業務アプリを構築するのに使えます（もちろんデータのマージや排他は自分で考える必要がありますが）。GTalkサーバそのもののスケーラビリティと可用性を備えたメッセージングサーバーがタダで使えるんですよ奥さん！これはじわじわ応用が広がってくると思います。

Permalink | コメント(0) | トラックバック(7) | 18:43