準備というか伏線というか、このハナシしておかないとな -- というわけで。
一時期、COMETに飛びついた人は多いですよね。僕もその一人です。やってみた感想は、「これはやっぱりHTTPの裏技で、まっとうじゃないな」。まっとうじゃなくても、この技術を使わざるを得ないようなキラーアプリがあれば話が別なんですが、それも思いつかないし。
そんなわけで、COMET熱は冷めちゃったわけですが、今でも「COMETが出現して良かったな」と思うことはあります。それは、逆向きのHTTP通信に名前を与えたことです -- COMET通信ですね。
HTTPの場合、クライアントとサーバーが通信をするとき、事前の準備は特に必要ありません。COMETの場合、COMET通信の片方のエンド（＝HTTPクライアント）が先にHTTPリクエストを送って通信チャンネルを開設しておく必要があります。これをイニシエーションと呼んでおきましょう。通常のHTTPの場合は、何もしないことがイニシエーションだと考えれば、通常のHTTP通信もCOMET通信も、「イニシエーションにより通信路が確立される」としてよいでしょう。
イニシエーションが終われば、通信の両端のあいだでデータのやり取りが出来るようになります。このとき、HTTP通信（通常のHTTP）とCOMET通信では、クライアントとサーバーの役割が逆転します。「COMETサーバー」という言葉は、COMETをサポートしたHTTPサーバーの意味で使われることが多いですが、ここではクライアント-サーバー・モデルでの役割を表して「COMETサーバー」「COMETクライアント」という言葉を使うことにします。
すると、次のような対応があります。
| HTTP通信 | COMET通信 |
|---|---|
| HTTPクライアント | COMETサーバー |
| HTTPサーバー | COMETクライアント |
| HTTPリクエスト | COMETレスポンス |
| HTTPレスポンス | COMETリクエスト |
実際は、HTTP上でP2Pモドキを実現したいときにCOMETが使われるので、クライアントとサーバーの区別を意識しないことが多いでしょうが、ここでは「役割の逆転」を強調します。
HTTPクライアント（＝COMETサーバー）がブラウザのケースで説明しましょう； COMETイニシエーション手順として、ブラウザがHTTPサーバーにHTTPリクエストをすると、HTTPサーバー（＝COMETクライアント）は、受け取ったHTTPリクエストを握ったままにします。これでCOMET通信路が確立するのです。
COMETクライアント（HTTPサーバー）がブラウザ（＝COMETサーバー＝HTTPクライアント）に何かの連絡や依頼をしたいことがあると、握っていたHTTPリクエストを手放してHTTPレスポンスを返します。このHTTPレスポンスが、COMETの意味ではリクエストとなるのです。ブラウザ（＝COMETサーバー＝HTTPクライアント）はCOMETリクエスト（HTTPレスポンス）を解釈して、COMETクライアント（＝HTTPサーバー）にCOMETレスポンス（次のHTTPリクエスト）を返す（送る）のです。
何もかにもが逆転します。本来HTTPは可逆（リバーシブル）に設計されてないので「何もかにも逆転」することは不自然で無理があります。そこに技術としてのCOMETの弱点があります。
しかし、HTTPの不可逆なところを捨象してしまって、「まー、だいたい可逆だろう」とオオザッパに考えてみると、HTTP通信とCOMET通信はお互いが鏡像のような関係になります。「クライアント ←→ サーバー」「リクエスト ←→ レスポンス」という役割が入れ替わります。現実のプロトコルは通常のHTTPだけですが、そのプロトコルの使い方や両端の役割が、通常のHTTPとCOMETではひっくり返るのです。
別な言い方をすると、HTTP(通常のHTTP通信）とCOMET（逆HTTP通信）は双対です。これは比喩や言葉の流用ではありません。厳密な意味で双対です。では、いかなる解釈と文脈のなかで「厳密に双対」なのでしょうか？ コンパクト閉圏（compact closed category）の双対性です -- 「それってなに？」 … そのうち語る機会もあるでしょう、今日はここまで。
