RSSCloudとPubSubHubbub, どっちがいい?: fat pingが勝つのはどうして?

次の記事

ドイツのブロガーたちが起草したジャーナリズムのための「インターネットマニフェスト」

編集者注記: 最近は、RSSCloudかPubSubHubbubかという議論が騒々しくなっているので、どちらにも詳しいデベロッパから話を聞きたくなった。この記事を書いたJosh Fraserは、EventVueの協同ファウンダで、空き時間にはPubSubHubbubに積極的に貢献している。彼はとくに、WordPressのプラグインをはじめ、PubSubHubbubのクライアントライブラリをいくつか作った。彼は、どっちに軍配を上げるだろうか。

ここ数か月、リアルタイムWebへの関心が高まっている。しかし問題は、Webが元々、リアルタイムを念頭に置いて設計されていないことだ。したがって今では技術者たちが、Webアプリケーションの動作を根底から変えるための新しいプロトコルを喉から手が出るほど求めている。今日は、Web上のリアルタイム通知を可能にする二つの有力なプロトコルを見てみたい。リアルタイム通知を可能にするプロトコルとして、XEP-0060のような古いものもあるが、今後将来性がありそうなのは二つの新しいプロトコル、PubSubHubbub(PuSH)とrssCloudだ。

PuSHとrssCloudはどちらも、今日のWebアプリケーションの動作の根本的な欠陥を補おうとする。現状では、Web上の更新を取得するためにはコンスタントにポーリングをしなければならない。コンテンツの購読者は、まるで、しつこくおねだりをする子どものように、“ねえ、まだ?、まだなの?”と言い続ける。購読者は発行者のサイトをコンスタントにpingして、新しい更新がないか尋ねるが、しかしその99%の答えは“ノー”なのだ。これではおそろしく効率が悪く、リソースを浪費し、しかも新しいコンテンツを登場とほぼ同時に得ることはきわめて難しい。二つのプロトコルはこの現在のやり方を逆転させ、更新をリクエスト駆動ではなくイベント駆動にする。つまり、どちらのプロトコルも、ポーリングの必要性を排し、購読者に対して“何か新しいものがあるか尋ねないでくれ。こっちから教えるから”と言う。

かなり前に誰よりも早くこれを考えたのはDave Winerだ。実は、<cloud>成分が2001年のRSS 2.0の規格に加わったが、注目されるようになったのはごく最近だ(主にPuSHに対する関心のため)。rssCloudは今週大きく前進して、その発表によれば、WordPressがWordPress.com上の750万のブログでrssCloudをサポートするようになるという。それと対照的にPuSHは現在、Friendfeed、Blogger、Google Reader、LiveJournal、Google Alerts、FeedBurnerなどの上で1億あまりのフィードに対しイネーブルになっている。どちらかのプロトコルを採用するサービスは、今後さらに増えるだろう。

しかし、両者がどう違うのか、と疑問を抱いている人が、たくさんいる。

両プロトコルは、概念的にはとてもよく似ている。どちらも簡単な宣言をフィードに加え、購読を取り扱うハブやクラウドを購読者に伝える。どちらのプロトコルにも中央のハブがあって、それが新たなコンテンツが発行されたときに購読者に通知する。どちらも、HTTPベースのプロトコルだ。

しかし、実装の微妙な違いを理解することが重要だ。そしてぼくの考えでは、今のところPuSH のほうが良いプロトコルだ。三つの点で、PuSHのほうがロバストな(堅牢な)プロトコルだと言える。

第一に、PuSHは何かが変わったと通知するだけでなく、新しいコンテンツも一緒に送る(これを”fat ping, 太ったping”と呼ぶ)。この重要な機能が、rssCloudにはない。fat pingは購読者にとって導入が楽なだけでなく、購読者がpingの通知に応答するのと更新されたフィードをリクエストするのが完全に同時なので、そこにまちがってDDoS攻撃が入り込むことがない。この問題はコンピュータ科学の界隈ではよく知られていて、よく“大群獣問題(the thundering herd problem)と呼ばれる。狭い資源に向かって、一挙に大量のプロセスが殺到することだ。rssCloudでこれに対する対策は比較的簡単だが、対策しなければならないことは事実だ。

第二に、PuSHではコールバック(通知が送られる先のカスタムURL)が可変だが、rssCloudでは変えられない。rssCloudの仕様は“通知はリクエストの発信元のIPに送られる。ほかのサーバのために通知をリクエストすることはできない”と述べている。これでは、購読を扱うサーバと、pingの通知を受け取るサーバを別にできないからとても不便だ。

第三にPuSHは、購読の取り消しの扱いがフレンドリだ。rssCloudでは、どのフィードも25時間後には自動的に購読取り消しになる。PuSHには購読を取り消すファンクションがあり、自動取り消しまでの時間を指定することもできる。これも、小さなことだけど大規模な展開では重要だ。rssCloudでは、RSSリーダーが毎晩、何百万ものフィードを再購読しなければならない。どういうときに購読や購読取り消しをするのかを指定できるPuSHのほうが、ずっと効率的だ。

rssCloudにも利点がないわけではない。PuSHのハブを実装するより、RSSのクラウドを実装するほうが、ずっと容易だ。PuSHの現在の設計では、ハブの実装が簡単ではない。

そのほかの細かい違いもあるが、重要なのは上の三つだ。そのほかはすべて、セマンティクスの問題だ。

両プロトコルをめぐって言われている二つの誤解を解いておきたい。たとえば、rssCloudは分散版のTwitterを作る、という説がある。これはDave WinerがrssCloudの目標声明として、”緩結合のTwitterふうのネットワークを作り140文字のステータスメッセージをやりとりする”なんて書いてるからだ。それは確かにおもしろい使い方の一つだが、プロトコルにできることに対する非常に狭い見方を広めてしまった。rssCloudの能力は、Daveが書いたことよりもずっと高いはずだ。

PuSHに関する最大の誤解は、Googleが所有してコントロールしているという説だ。これはまったく真実ではない。PuSHはぼくのような独立のデベロッパが多数、開発に関わっているし、また、SuperFeedrのようなGoogleとは無縁のPuSHハブもある。Brett Slatkinがこう指摘している:

われわれの仕様開発過程は完全に透明だ。2008年の8月5日以降、誰もがチェックインされたコードを見ることができる。すべての議論は公開メーリングリストの上で行われている。仕様が完全にオープンで、中央集権的でなく、どこかの企業がコントロールしないことが、重要なのだ。

全体的に見ると、PubSubHubbubもrssCloudもどちらも、Webの大きな進歩を表している。個人的にはPuSHのほうがいいと思うが、今後も熾烈な競争が続いて、どちらのプロトコルもより強力になっていくことが望ましい。

(写真クレジット: Flickr/Libertinus)

[原文へ]

(翻訳:iwatani(a.k.a. hiwa))

“RSSCloudとPubSubHubbub, どっちがいい?: fat pingが勝つのはどうして?” への1件のコメント

  1. […] RSSCloudとPubSubHubbub, どっちがいい?: fat pingが勝つのはどうして? | TechCrunch Japan コメントを書く « 2009年9月10日(木) […]

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中