Summary

  • Регулярная программа Internet Talk Radio в 1993 году представляла собой заранее записанное аудио, распространявшееся файлами. В объявлении о запуске говорилось, что FTP достаточно, и прямо уточнялось: для этой службы IMS не использовала MBONE.
  • План предусматривал один источник программ и копии, которые сети могли передавать через UUNET, региональные сети, EUnet, WIDE и IIJ. В объявлении нет полного списка работающих зеркал или измерений трафика.
  • Отдельный прямой эфир NPR с использованием MBONE состоялся в мае 1993 года. Этот эксперимент не превратил еженедельную серию «Geek of the Week» в постоянное прямое вещание.

Объявление до появления первого файла

22 марта 1993 года в список рассылки RIPE переслали сообщение с планом Карла Маламуда запустить новую службу. Она называлась Internet Talk Radio; первой программой должна была стать «Geek of the Week» — интервью с участниками сетевого сообщества. Начало было назначено на 31 марта. В сохранившейся записи программы 31 марта также указано как дата выпуска первого эпизода — интервью с Маршаллом Т. Роузом об OSI, X.400, политике IETF и SNMPv2, среди прочего. Объявление и архив описывают одну и ту же начинавшуюся службу с разницей в несколько дней. Лучше всего начать с сообщения в списке RIPE и записи первого эпизода.

Маламуд называл «радио» метафорой. Первым продуктом была профессионально подготовленная аудиозапись, размещённая в интернете. Слушатель мог скачать файл, оставить его у себя и прослушать позже. В мартовском объявлении мультикаст упоминался как один из способов, которым принимающая сеть могла бы передавать программу дальше, но тут же проводилась граница: сама IMS не использовала MBONE для Internet Talk Radio. Возможность ретрансляции через мультикаст не означала прямой эфир по мультикасту.

Так меняется начальная сцена. Тысячам слушателей не нужно было подключаться в один момент. Запись могла сначала попасть на региональный узел, а затем копироваться на локальный компьютер; каждый выбирал, когда её получить и прослушать. Слово «радио» отсылало к привычному расписанию передач, но сеть давала слушателю контроль над временем воспроизведения.

Одна программа — несколько маршрутов по сети

Первый выпуск планировали продолжительностью около получаса. В мартовском сообщении Маламуд оценивал его размер в 15 мегабайт при стандартном PCM, частоте 8 000 отсчётов в секунду и 8-битном mu-law. В презентации для IETF в 1993 году кодирование описывалось как поток 64 килобита в секунду, также упоминались варианты форматов. Позднее создатель вспоминал получасовой файл размером 30 мегабайт. Это не взаимозаменяемые измерения: первое — оценка из стартового объявления для указанного кодирования, второе — ретроспективное воспоминание.

Полного журнала передач или манифеста файлов, который установил бы единый размер каждой копии, нет; поэтому оба числа остаются привязаны к своим источникам.

Размер файла делал план ретрансляции частью программы. Предполагалось начать с UUNET и распространять копии через региональные сети, чтобы не создавать лишних повторных передач. В качестве начального европейского узла хранения назывался mcsun в EUnet, а для Японии — WIDE и IIJ. Клиенты Alternet могли обращаться к анонимному FTP на UUNET. Локальным сетям предлагалось связаться со своим провайдером, а провайдеры могли запросить инструкции. Это описание задуманной схемы, а не подтверждённый список работающих зеркал.

Источники не говорят, что каждая названная сеть установила копию, сколько слушателей пользовались каждым узлом или каким был общий трафик.

Сохранившийся архив IMS показывает, как выглядела редакционная программа: первый выпуск «Geek of the Week» разбит на семь аудиочастей со ссылками на .au, .gsm и .ra. Последующие выпуски собраны по неделям, с датами и именами гостей. В списке за 1994 год есть интервью с исследователями и инженерами сетей — Стивом Крокером, Радией Перлман, Скоттом Брэднером, Тимом О’Райли и другими. Архив сохранял не только звук, но и редакционный ритм. Его страница была каталогом, а запись требовалось получить в совместимом формате. Указатель Geek of the Week содержит даты, гостей и форматы.

Файл можно было разместить там, где сеть могла справиться с передачей. Это снижало зависимость от единого глобального потока, но не делало доступ равным. При скорости 64 килобита в секунду файл размером 15 мегабайт мог загружаться по модемному соединению часами — ещё до учёта повторов и накладных расходов протоколов. Разделение на части облегчало выбор и получение отдельных фрагментов, но не отменяло стоимость передачи байтов. Региональная копия могла сократить повторные дальние передачи, если слушатели скачивали файл локально; однако доступные источники не содержат измерений трафика до и после, которые позволили бы оценить экономию.

«Мультикаст» — возможность, а не доказательство доставки

Смешать название службы со способом передачи легко. Internet Talk Radio возникла в период, когда MBONE позволяла устраивать прямые эфиры для некоторых групп и сетей. Но мартовское объявление говорит прямо: «Мы не используем MBONE». Для еженедельной программы было достаточно FTP; мультикаст оставался вариантом для сетей, желавших ретранслировать выпуск. В одной архитектуре могли сосуществовать оба способа, но впечатления слушателя они не делали одинаковыми.

Отдельный специальный эфир помогает очертить границы утверждения. В мае 1993 года объявили «NPR Meets the Internet»: прямой эфир Science Friday должен был выйти по MBONE на канале Internet Town Hall; запись планировали сделать 21 мая и выпустить 31 мая. Это был синхронный эксперимент, описанный отдельно. Он не доказывает, что каждый еженедельный разговор «Geek of the Week» передавался вживую или что серия отказалась от файлов. Позднейшие описания также упоминают прямые мероприятия и архивную службу как две сосуществовавшие функции.

Для эксплуатации разница принципиальна. В прямом эфире сеть должна доставить сигнал во время прослушивания; задержки и перегрузка влияют на общий опыт. Для файла узкое место меняется: кому-то нужно записать программу, хранить её, включить в каталог, обеспечить путь до слушателя и поддерживать пригодные копии. Файл допускает задержку и даёт пользователю контроль над воспроизведением, но требует хранилища и ставит на первый план права на хранение и копирование.

Для распространения требовались и права

Объявление не считало пропускную способность единственным ограничением. Производство собирались финансировать по модели спонсорства NPR; среди первых спонсоров назывались Sun Microsystems и O’Reilly & Associates. Там же утверждалось, что две крупные государственные сети сочли службу соответствующей своим правилам допустимого использования. Поскольку сети не названы, это следует понимать как заявление самого объявления, а не как проверяемое официальное одобрение конкретных органов.

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

Спонсорство помогало оплачивать производство без продажи каждой загрузки отдельно. Но широкое распространение могло оторвать запись от условий, объясняющих её происхождение. Копия без даты, формата или указания источника могла обращаться по сети, и слушатель не знал бы, полна ли она, одобрена ли она или имеет ли узел право её хранить. Каталог и записи эпизодов снижали часть риска, связывая файлы с датами, гостями и форматами.

Участие не определяет, кто даёт разрешение

Если спросить, кто участвует и у кого остаётся основное право разрешать, в сети ретрансляции обнаруживаются разные уровни. Студия готовила программу; IMS организовывала публикацию; UUNET и региональные узлы могли перевозить или хранить копии; провайдеры и клиенты выбирали место загрузки; слушатель решал, когда включить запись. Такое распределённое участие могло расширить доступ, не передавая каждому зеркалу полномочия решать вопросы производства, прав или утверждённой версии.

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

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

Что позволяет увидеть архив

В 1993 году Internet Talk Radio не требовалось имитировать прямой эфир, чтобы оставаться узнаваемым радио. Программа стала сетевым объектом: обозначенной записью, разбитой на части и форматы, связанной с расписанием и доступной по FTP, с предложенной сетью региональных копий. С радиовещанием её роднили серии выпусков, ведущие и спонсоры; отличали время и маршрут доставки. Слушателю не нужно было приходить к началу, зато файл должен был добраться заранее.

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

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

Необратимой потерей было бы не только пропустить загрузку в конкретный день. Могли исчезнуть эпизод, дата его выхода, контекст формата или разрешение, благодаря которому копия была законной. Сохранившийся архив — одновременно услуга и свидетельство: он удерживает сведения о программах, которые иначе трудно восстановить. Надёжное распространение требует хранить и копии, и их происхождение: кто опубликовал файл, какой версии он соответствует, где передавался дальше и на каких условиях сеть может его оставить или разослать.

Источники и границы свидетельств

Эти различия можно проверить по исходному объявлению, сохранившимся записям программ, поздним воспоминаниям создателя и отдельным свидетельствам о прямых эфирах: