Zusammenfassung

  • CU-SeeMe senkte Kosten und Geräteanforderungen am Endgerät. Mehrparteienkonferenzen benötigten dennoch einen eigenen Unix-Reflektor, weil die TCP/IP-Umgebung des Macintosh die erforderliche Multicast-Funktion nicht bot.
  • Der Reflektor machte Gruppengespräche durch Kopieren und Verteilen von Datenströmen möglich. Zugleich bündelte er Bandbreite, Konfiguration, Teilnehmergrenzen, Sichtbarkeit und Nutzungsregeln an einem gemeinsamen Punkt.

Ein zusätzlicher Teilnehmer änderte die Architektur

Das ursprüngliche Ziel war konkret. Tim Dorcey beschrieb CU-SeeMe in einem Artikel vom März 1995 als Videokonferenzsystem für Macintosh und Windows. Für den Empfang genügten eine Netzwerkverbindung und ein Graustufenmonitor. Zum Senden brauchte man Kamera und Digitalisierer; Dorcey schrieb, dass eine kombinierte Kamera-Digitalisierer-Lösung für den Macintosh unter 100 US-Dollar erhältlich sein konnte. Das war ein Komponentenpreis, keine vollständige Internetstation. Die kleinen monochromen Bilder passten zur damaligen Rechenleistung.

Zwei Teilnehmer konnten sich direkt verbinden. Für größere Runden reichte es nicht, dieselbe Verbindung einfach zu vervielfachen: Alle mussten sich mit einem „Reflektor“ verbinden, einem Unix-Rechner mit CU-SeeMe-Software, der Paketströme kopierte und weiterverteilte. Dorcey nannte als ursprünglichen Grund das fehlende Multicast in der TCP/IP-Umgebung des Macintosh. Der persönliche Rechner erzeugte das Bild; die gemeinsame Maschine stellte den Konferenzraum bereit.

IP-Multicast war bereits standardisiert. RFC 1112 beschrieb 1989, wie Hosts Datagramme an Gruppen senden und solche empfangen. Die Einschränkung war enger: Die vom CU-SeeMe adressierte Macintosh-TCP/IP-Implementierung unterstützte den nötigen Multicast-Empfang nicht. Der Reflektor schloss eine Lücke auf dieser Plattform. Daraus folgt nicht, dass das Internet insgesamt kein Multicast beherrschte.

Der gemeinsame Knoten koordinierte die Empfänger

CU-SeeMe sendete nicht automatisch jedes Medium an alle. Nach Dorceys Beschreibung übermittelte jeder Client regelmäßig ein OpenContinue-Paket mit seinen Wünschen für die Medien der anderen Teilnehmer: Video, Audio oder Folien. Der Reflektor wertete diese Nachrichten aus und erstellte quellenspezifische Verteilerlisten. Er kopierte also nicht bloß Pakete, sondern koordinierte auch deren Empfänger und konnte ungewünschte Medien zurückhalten.

Diese Flexibilität legte den aktuellen Konferenzzustand beim Reflektor ab. Zugleich musste jeder Teilnehmer dynamische Informationen über alle anderen verarbeiten. Dorcey hielt das Protokoll 1995 für wenig skalierbar, sobald eine Konferenz ungefähr 30 Personen überstieg; kleinere Runden funktionierten nach seiner Einschätzung robust. Das ist eine Aussage über die Skalierung des Protokolls, keine für jede Reflektorkonfiguration geltende feste Obergrenze.

Der Reflektor wurde außerdem zu einem Treffpunkt. Die Cornell-Projektseite nannte ihn als Voraussetzung für Mehrparteienkonferenzen und warnte, dass die Software Konferenzströme an Empfänger wiederholte. Wer sich mit einem aktiven Reflektor verband, konnte sehen, wer hinzukam. Der Treffpunkt war zugleich eine Sichtbarkeitsgrenze: Die Weiterleitung bestimmte, wer wen beobachten konnte.

Aus Kapazität wurde eine Frage des Umgangs

Die erhaltenen Hinweise für Nutzer machen gemeinsame Kosten sichtbar. Die Cornell-Seite bat darum, vorher Kontakt mit dem Betreiber aufzunehmen, ohne Einladung nicht stundenlang verbunden zu bleiben, keine unbeaufsichtigten Standbilder zu senden, die Client-Grenze unter 100 Kilobit pro Sekunde zu halten und die Folgen für gemeinsam genutzte Leitungen zu prüfen. Auch ein Standbild belege Netzwerkbandbreite und Reflektorkapazität. Das war keine abstrakte Protokolletikette: Jemand anderes stellte die gemeinsame Ressource bereit.

Ein mit Internet TV with CU-SeeMe veröffentlichtes Betriebshandbuch zeigte ein Planungsbeispiel: rund 80 Kilobit pro Sekunde für eine brauchbare Verbindung, 640 Kilobit pro Sekunde, um acht Teilnehmer zu empfangen, und 5,12 Megabit pro Sekunde, um die Ströme an die Runde zurückzusenden. Der letzte Wert ist eine illustrative Schätzung des Handbuchs, kein Messwert. Er zeigt dennoch die Multiplikation der Arbeit: erst Empfang, dann Versand von Kopien. Das Handbuch empfahl Unix wegen Netzwerkanbindung, Rechenleistung und Dauerbetrieb und beschrieb Textkonfigurationen für Teilnehmer- und Sendergrenzen.

Eine Cornell-README, die im Mai 1993 zirkulierte, riet zu Grenzen unter 100 Kilobit pro Sekunde, sofern Nutzer nicht wussten, wohin ihre Pakete liefen. Ein zeitgenössischer Bericht besagte, ein Reflektor habe bis zu sechs Teilnehmer bedient. Keiner dieser Werte definiert eine allgemeine Kapazität. Zusammen zeigen sie, dass der Umfang von lokaler Hardware, Leitung, Konfiguration und dem Urteil des Betreibers abhing.

Einfachere Teilnahme beseitigte die Betriebsarbeit nicht

Die Cornell-Hochschulgeschichte setzt die Entstehung des Reflektors in den Zusammenhang einer Anfrage Ende 1992: Ein NSF-Programmverantwortlicher fragte, ob CU-SeeMe eine Mehrparteienaktivität für Schulkinder unterstützen könne. Richard Cogger entwickelte das Konzept; John Lynn schrieb das separate Unix-Programm, Scott Brim gab Rückmeldungen zum Protokolldesign. Eine Konferenz des Global-Schoolhouse-Projekts verband danach Schülerinnen und Schüler aus mehreren US-Bundesstaaten mit London. Dieser Ursprung erklärt die Aufgabe des Reflektors: Ein realer Bildungseinsatz brauchte mehr als eine Demonstration zu zweit.

Dorcey beschrieb die Abwägung vorsichtig. Das Team wollte Abhängigkeit vom Reflektor auf Paketkopie und -verteilung begrenzen, erkannte aber den Nutzen, Datenströme auf die Empfänger zuzuschneiden. Der Reflektor war eine praktische Brücke und sollte nicht jede Kommunikation beherrschen. Eine Brücke braucht jedoch einen Host, einen Betreiber, ausreichende Kapazität und Regeln für ihre Nutzer.

Bis 1995 hatte das Projekt Protokolle erweitert sowie unter anderem Audio, Farbe, Textchat und Bandbreitenverwaltung ergänzt. Mehr Funktionen lösten die Betriebsfrage nicht. Eine erschwingliche Kamera senkte die Kosten am Endgerät; sie lieferte weder die Upload-Kapazität des Konferenzraums noch Unix-Host, Wartung oder Abstimmung. CU-SeeMe senkte eine Hürde und verlagerte eine andere in den gemeinsam genutzten Dienst.

Die Quellen belegen weder unerschwingliche Betriebskosten noch eine einheitliche Durchsetzung der Regeln oder gleichen Zugang für alle. Sie dokumentieren aber den Architekturtausch: Der Client machte die Teilnahme günstig genug zum Ausprobieren; der Reflektor ermöglichte die Gruppe, indem er Arbeit an einem kapazitätsbegrenzten und für Teilnehmer sichtbaren Punkt bündelte.

Quellen