要約

  • CU-SeeMeは端末の価格と必要機材を抑えた一方、当時のMacintosh TCP/IPに必要なマルチキャスト機能がなかったため、多人数会議には独立したUnixリフレクターを要した。
  • リフレクターは映像などのストリームを複製・配信して会議を成立させた。同時に帯域、設定、参加人数、見える範囲、利用ルールが共有ノードに集まった。

一人増えると構成が変わる

最初の狙いは明快だった。Tim Dorceyが1995年3月に発表した記事によれば、CU-SeeMeはMacintoshとWindows向けのデスクトップ会議ソフトで、映像を見るだけならネット接続とグレースケール画面があればよかった。送信にはカメラとデジタイザーが必要で、Mac向けの一体型機材は100ドル未満で購入できたという。ただし、これは部品の価格で、ネット接続を含む利用一式の費用ではない。小さな白黒映像は当時の計算資源に合わせた選択だった。

二人は直接接続できる。それ以上の会議では同じ接続を増やすだけでは足りず、全員が「リフレクター」と呼ばれるUnix機に接続した。CU-SeeMeのソフトを動かすその機械が、パケットの流れを複製して再配信する。Dorceyは開発のきっかけを、MacintoshのTCP/IP環境にマルチキャスト機能がなかったことだと説明した。端末が映像を作り、共有機が会議の場を用意した。

IPマルチキャストの仕様自体はすでにあった。RFC 1112は1989年に、ホストがグループ宛てデータグラムを送受信するための機能を定めている。問題はより限定的で、CU-SeeMeが対象としたMacintoshのTCP/IP実装に必要な受信機能がなかった。リフレクターは端末側の欠落に対するアプリケーション層の解決策であり、インターネット全体にマルチキャストがなかったことを示すものではない。

共有機は配信先も調整した

CU-SeeMeは、すべてのメディアを無条件に全員へ送る設計ではなかった。Dorceyによると、各クライアントはOpenContinueパケットを定期的に送り、ほかの参加者から受け取りたい映像、音声、スライドを伝えた。リフレクターはその情報を読み、送信元ごとの配信リストを作った。単なる複製に加え、受信者に必要なメディアを選び分ける役割も担っていた。

その柔軟さは、会議の動的な状態をリフレクターに置き、各参加者がほかの全員の変化を処理することを求めた。Dorceyは1995年の論文で、少人数会議では堅牢に動くものの、約30人を超えるとプロトコルの拡張性が低いと評価した。これはプロトコルの規模上の評価であり、すべてのリフレクターに適用される固定上限ではない。

リフレクターは、人が出会う場所にもなった。Cornellのプロジェクトページは多人数会議に必要な仕組みと説明し、接続中の会議ストリームは受信者に繰り返し配信されると注意していた。稼働中のリフレクターにつなげば、誰が参加しているか見える場合がある。待ち合わせ場所は可視性の境界でもあり、配信の仕方が「誰から誰が見えるか」を決めた。

容量は利用者同士の気遣いに委ねられた

残された利用案内には、共有コストがはっきり表れている。Cornellのリフレクター利用規則は、利用前に運用者へ連絡すること、招待なしに何時間も接続し続けないこと、静止画像を流しっぱなしにしないこと、送信レートを毎秒100キロビット未満に抑えること、共有回線への影響を確認することを求めた。静止画像も回線帯域とリフレクターの処理容量を使うという。これは抽象的なプロトコル作法ではなく、共有設備を提供する人への配慮だった。

『Internet TV with CU-SeeMe』の運用ガイドは、計画用の例として、満足できる接続に毎秒約80キロビット、八人分の受信に毎秒640キロビット、会議へ反射配信するには毎秒5.12メガビットを示した。最後の値はガイドの概算であり、測定値ではない。それでも、受信したデータを参加者へ複製して送り返すという負荷の増え方を表している。ガイドはネット接続、処理能力、長時間の稼働を理由にUnix機を推奨し、参加者数や送信者数をテキスト設定で制限できると説明した。

1993年5月に出回ったCornellのREADMEは、通信先を把握している場合を除き、帯域上限を毎秒100キロビット未満にするよう促した。同時期の一利用者の投稿には、あるリフレクターが最大六人を受け入れたとの報告がある。どちらも普遍的な容量を示す値ではない。利用規模は、各サイトの機器、回線、設定、運用者の判断に左右された。

参加しやすさは運用作業を別の場所へ移した

Cornellの大学史によると、1992年末にNSFの担当者が小学生のための多人数会議にCU-SeeMeを使えないか尋ねた後、リフレクターが生まれた。Richard Coggerが構想し、John Lynnが独立したUnixプログラムを開発し、Scott Brimはプロトコル設計に意見を寄せた。Global Schoolhouse計画の会議では、米国の複数州とロンドンの生徒がつながった。実際の教育利用には二人のデモ以上の仕組みが要ったことが、開発の経緯に表れている。

Dorceyはこの交換条件を慎重に説明した。開発側はパケットの複製と配信を超えてリフレクターへの依存を増やさないようにしつつ、受信者に応じて配信を細かく調整できる価値も認めていた。サーバーが通信全体を支配する設計思想ではなく、実用上の橋渡しだった。それでも橋には、ホスト、運用者、処理余力、そして利用者が守るルールが必要になる。

1995年までに、プロトコルは拡張され、音声、カラー画像、テキストチャット、帯域管理などが加わった。機能の進歩だけでは運用の問いは消えない。安価なカメラで端末は手に入りやすくなっても、会議室の上り帯域、Unixホスト、保守、調整までは提供されなかった。CU-SeeMeは一つの障壁を下げ、別の障壁を共有サービスへ移した。

資料から、リフレクター運用が極端に高価だった、すべての運用者が公開ルールを適用した、誰もが等しく参加できた、とまでは言えない。一方で、設計上の取引は確認できる。参加を試しやすくした端末のそばには、容量に限りがあり、利用者から見える共有ノードがあり、そこでの運用作業を担う人がいた。

出典