Кратко

  • В RFC 966 один адрес обозначал группу хостов, состав которой мог изменяться; клиенту не требовалось хранить список всех работающих серверов.
  • Отправителю разрешалось находиться вне открытой группы. Однако право послать датаграмму не удостоверяло присутствие получателей или успешный ответ службы.

Представим бездисковую рабочую станцию в момент запуска. Ей нужен сервер, но зашитый список адресов становится неверным после замены оборудования. Широковещательный запрос, напротив, отвлекает машины, которым нечего сообщить. В декабре 1985 года Стив Диринг и Дэвид Черитон предложили в RFC 966 адресовать запрос не заранее выбранному компьютеру, а группе потенциальных поставщиков услуги. Документ предлагал модель для обсуждения и не устанавливал, где она уже была введена в действие.

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

Группа в предложении могла не иметь ни одного участника. Один хост мог вступать сразу в несколько групп. Временная группа прекращала существование, когда уходил последний участник; для изменений предусматривались CreateGroup, JoinGroup и LeaveGroup. Таким образом, постоянство адреса означало постоянство роли, о которой можно спросить. Оно не подтверждало, что сейчас имеется хотя бы один доступный сервер.

Открытость группы касалась отправки. Клиент не должен был вступать в группу серверов, чтобы направить ей вопрос. При этом RFC 966 отдельно обсуждал ключ доступа, ограничивающий вступление в некоторые группы. Вступить в число получателей, отправить датаграмму и получить обслуживание от приложения — три разных действия. Групповой адрес не превращал сетевой запрос в доказательство полномочий клиента.

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

В RFC 988, сменившем исходный проект в 1986 году, принцип был сформулирован особенно чётко: у постоянной группы постоянен адрес, а не её члены. RFC 1112 в 1989 году сохранил это различие и напомнил, что доставка по мере возможностей не гарантирует целого пакета всем участникам или одинакового порядка. Преемственность формулировок подтверждает значимость идеи, но не доказывает повсеместное внедрение проекта 1985 года.

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

Источники и границы

Использованы только первоначальные документы RFC 966, RFC 988, RFC 1112 и раннее предложение о широковещании RFC 919. Они не устанавливают дату первого рабочего развёртывания, степень распространения или результат отдельной службы.