「Comet」でデジャヴ
「Comet」でデジャヴ
最近1(http://alex.dojotoolkit.org/2006/03/comet-low-latency-data-for-the-browser/)みたい？]時々話に聞く「Comet」という技術についてつらつらと Web で眺めていて、強烈なデジャヴが。
これってその昔の 1996〜7 年ごろ、Netscape がブラウザに frame などを導入した時分 (3 か 4 のころですな) に、「Server Push」という名前で呼ばれていた技術とほぼ同じですね。当時の Netscape サーバ／ブラウザには面白い機能がいろいろありましたがこれもその一つで、クライアントが HTTP リクエストを発行するとその HTTP コネクションがつなぎっぱなしにされ、サーバはなんと、HTTP レスポンスを MIME Multipart で返してくるのです(爆。ブラウザはサーバから帰ってくる Multipart レスポンスの一つ一つのパートを受信するたびにリアルタイムで画面を再描画するように作られていたため2、サーバ側が任意のタイミングでクライアントの画面を書き換えることが出来ました。
当時、確か僕も仕事で Web Chat を作らないといけないような話があって、そのころ既に存在した IRC やらなにやらと比較したときの Web Chat のリアルタイム性の無さを何とかしたいと考えていて、そんな中、この「Server Push」技術についてもトライしたことがありました。仕事の中では結局使わなかったんですけれど、当時の So-net の掲示板で、So-net の技術者の人と議論した様子が Web Archive に残ってました(このページの上のほうにある、「Server Push ってすでに使えないの？」という Thread ですね。当時僕は「KAOS」と名乗っていたらしいｗ)。
あのころの So-net の人との議論では、Comet の議論でも常に問題になる「サーバ側リソースの枯渇」についてリスクが大きすぎるので、実際に広く利用されるサービスにおいては Server Push は使えない、という結論になりました。最近はいろいろ新しいサーバ OS/アプリや Long Polling 等の技術によってこの辺のリスクも徐々に緩和されてきている(＝ので実際に使えるようになってきた)ようですね。
ちなみに同時期にセットで「Client Pull」という技術も導入されていますが、これはいわゆる Polling であって、未だ現役で利用されている refresh メタタグのことです。これを導入したのも Netscape だったんですね。「Server Push」が Netscape ブラウザ限定の機能だったのに対し、「Client Pull」の方は今日ほとんどのブラウザが対応しているというあたりはなかなか面白い対比です。