Кратко

  • CU-SeeMe снижала стоимость и требования к пользовательскому компьютеру, однако конференции с несколькими участниками зависели от отдельного ретранслятора Unix: TCP/IP-среда Macintosh не предоставляла необходимую проекту поддержку multicast.
  • Ретранслятор обеспечивал групповое общение, копируя и распределяя потоки, но одновременно сосредоточивал в одной точке сетевую нагрузку, настройки, пределы числа участников, видимость и правила пользования.

Третий участник менял архитектуру

Первоначальная задача была практической. В статье за март 1995 года Tim Dorcey описал CU-SeeMe как программу видеоконференций для Macintosh и Windows. Для приёма видео требовались подключённый к сети компьютер и монитор с оттенками серого. Для передачи нужны были камера и устройство оцифровки; Dorcey писал, что их сочетание для Macintosh можно было купить менее чем за 100 долларов. Это цена оборудования для съёмки, а не полного рабочего места с интернет-доступом. Небольшое монохромное изображение соответствовало вычислительным возможностям тогдашних машин.

Два пользователя могли соединиться напрямую. Для большой группы этого было недостаточно: каждому требовалось подключиться к «ретранслятору» — компьютеру Unix с программой CU-SeeMe, которая копировала и заново распределяла потоки пакетов. По словам Dorcey, первоначальной причиной разработки ретранслятора было отсутствие multicast в TCP/IP-среде Macintosh. Персональный компьютер создавал изображение; общий компьютер собирал участников в одну комнату.

Стандарт IP multicast к тому времени уже существовал. RFC 1112, опубликованный в 1989 году, описывал отправку и приём хостами дейтаграмм, адресованных группе. Ограничение было конкретным: в целевой для CU-SeeMe реализации TCP/IP для Macintosh не было нужного проекту приёма multicast. Ретранслятор устранял пробел одной платформы; это не означает, что multicast отсутствовал во всём интернете.

Общая точка задавала ещё и адресатов

CU-SeeMe не рассылала любые материалы всем автоматически. В описании Dorcey каждый клиент периодически отправлял пакет OpenContinue с перечнем желаемых материалов других участников: видео, звука или слайдов. Ретранслятор изучал эти сообщения и формировал списки доставки для каждого источника. Он не только копировал пакеты, но и согласовывал получателей, поэтому мог не передавать то, что участник не запрашивал.

Такое управление помещало меняющееся состояние конференции в ретранслятор и заставляло каждого участника обрабатывать сведения обо всех остальных. В статье 1995 года Dorcey оценивал масштабируемость протокола как слабую для групп примерно больше тридцати человек, хотя для небольших собраний считал её надёжной. Это оценка масштабирования протокола, а не фиксированный предел каждой конфигурации ретранслятора.

Ретранслятор превратился и в место встреч. На странице проекта Cornell указывалось, что он необходим для многопользовательской конференции; там же предупреждали, что программа повторяет потоки конференции получателям. Подключившись к активному ретранслятору, можно было увидеть других участников. Место встречи одновременно становилось границей видимости: способ пересылки определял, кто кого мог наблюдать.

Вместе с ёмкостью росла роль правил пользования

Сохранившиеся инструкции для участников ясно показывают общие затраты. Страница Cornell просила заранее связаться с оператором, не оставаться подключённым часами без приглашения, не передавать надолго статичную картинку, ограничивать скорость клиента значением ниже 100 килобит в секунду и оценивать влияние на общую линию. Даже неподвижное изображение занимало сетевую полосу и ёмкость ретранслятора. Это был не отвлечённый совет по протоколу: общий ресурс предоставлял другой человек.

Руководство для операторов в книге Internet TV with CU-SeeMe предлагало плановый пример: примерно 80 килобит в секунду для приемлемого соединения; 640 килобит в секунду на приём восьми участников; 5,12 мегабита в секунду на обратную пересылку их потоков группе. Последняя цифра — иллюстративная оценка из руководства, а не измеренный результат. Она показывает, как умножалась работа: принять потоки, затем отправить копии. Руководство объясняло выбор Unix связностью, производительностью и способностью работать долгое время, а также описывало текстовые параметры для ограничения числа участников и отправителей.

Файл README Cornell, распространявшийся в мае 1993 года, советовал не превышать 100 килобит в секунду, если пользователь не понимал, куда направляется трафик. В современном тому периоду сообщении говорилось, что один ретранслятор принимал до шести участников. Ни один показатель не задаёт универсальную ёмкость. Вместе они показывают зависимость масштаба от местного оборудования, канала, конфигурации и решения оператора.

Доступность переместила работу, а не устранила её

В истории вычислительной техники Cornell появление ретранслятора связывается с запросом конца 1992 года: сотрудник NSF спросил, сможет ли CU-SeeMe поддержать групповое занятие для школьников. Richard Cogger предложил эту концепцию, John Lynn разработал отдельную программу Unix, а Scott Brim дал замечания к протоколу. Затем конференция Global Schoolhouse связала школьников из нескольких штатов США с Лондоном. Эта история объясняет назначение ретранслятора: реальное учебное использование требовало большего, чем демонстрация для двух человек.

Dorcey осторожно описывал компромисс. Команда старалась не создавать зависимость от ретранслятора сверх копирования и распределения пакетов, но видела ценность настройки потоков для разных получателей. Это был практический мост, а не замысел сделать сервер главным распорядителем любой связи. Но мосту необходимы узел, оператор, достаточный запас ресурсов и правила для пользователей.

К 1995 году проект расширил протоколы и добавил звук, цветное изображение, текстовый чат и управление полосой пропускания. Дополнительные возможности не сняли вопрос эксплуатации. Доступная камера удешевляла пользовательский конец системы, но не обеспечивала исходящую полосу конференц-комнаты, Unix-узел, обслуживание и координацию. CU-SeeMe снизила один барьер и перенесла другой в общий сервис.

Источники не доказывают, что обслуживание ретранслятора было непомерно дорогим, что каждый оператор применял опубликованные правила или что все пользователи имели равный доступ. Они показывают архитектурный обмен: клиент делал участие достаточно дешёвым для эксперимента; ретранслятор обеспечивал группу, сосредоточивая работу в ёмкостно ограниченной точке, видимой участникам.

Источники