Кратко

  • При равном приоритете RFC 1458 предлагал сначала отбрасывать высшее прикладное качество, если нижний базовый слой мог дать полезный результат без зависящего от него улучшения.
  • Для проверки требовалось раздельно видеть модель зависимости, запрос клиента, счётчики MGA, состояние интерфейса, маркировку, реальную потерю, ремонт и итог приложения.

Получатель замечает пропажу не в тот момент, когда маршрутизатор принимает решение. Сначала переполняется очередь и исчезает пакет. Затем возникает разрыв последовательности. Потом приходит NAK, выбирается способ повторной передачи, восстанавливаются слои и лишь после этого приложение может понять, осталось ли изображение пригодным.

RFC 1458 выстроил механизм вокруг этого разрыва во времени. Его парадоксальный порядок потерь — высшее качество первым — имел смысл только потому, что «высшее» означало больше деталей, а не большую независимость.

Грубое изображение было нижней границей успеха

RFC 1458 вышел в мае 1993 года. Карточка RFC Editor относит его к Informational, а не к Internet Standard. Авторы рассматривали огромные цифровые изображения, тысячи терабайт в день, сотни удалённых пользователей, сроки от секунд до минут и сети с различием пропускной способности до шести порядков.

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

Запрошенное качество и обязательный надёжный минимум стали разными параметрами. Клиент хотел полное изображение, но мог требовать гарантированного восстановления только для базы. Полезность нельзя было вывести из одного номера класса.

Спрос превращался в распределённое состояние

Проект включал Multicast Group Authority (MGA), Reliable Adaptive Multicast Protocol (RAMP) и изменённую маршрутизацию. MGA должна была выдавать групповые адреса, регистрировать услуги и считать участников по качеству и надёжности. RAMP отвечал за порядок, восстановление и скорость. Маршрутизаторы хранили для каждого выходного интерфейса группу и набор нужных качеств.

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

Смена качества уменьшала один счётчик, увеличивала другой, проходила по иерархии, могла включить или выключить производство и изменить маршруты. Ответ клиенту и завершение такого перехода — не одна отметка времени.

Значение TOS оказалось зависимо от протокола

Пакет RAMP мог быть отмечен одним или несколькими уровнями. Получатель проверял и групповую принадлежность, и запрошенное качество. Для старого IPv4 RFC 1458 предлагал превратить Type of Service в набор битов качества.

Текст прямо признавал несовместимость с RFC 1349. Там TOS был одним перечислимым значением: уменьшить задержку, увеличить пропускную способность или надёжность, снизить стоимость либо выбрать обычный сервис. Логическое OR нескольких значений объявлялось бессмысленным. RFC 791 также задавал Type of Service как характеристику сетевой обработки, а не структуры изображения.

Один и тот же узор битов получил двух претендентов на смысл. IP видел пожелание к пути, RAMP — прикладную зависимость. Захват пакета доказывает узор, но не толкование. Нужны версия, контекст эксперимента и конфигурация каждого узла.

Верхний слой сужал, а база расширяла возможный итог

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

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

В примере RFC независимые Q1 и Q2 направляются только своим получателям. В зависимом случае пакеты Q2, нужные также Q1, несут обе отметки и копируются в обе ветви. Заголовок утверждает связь содержимого, таблица интерфейса — текущий спрос.

Утверждение не равно проверке. Сервер мог ошибиться в графе слоёв. Счётчик MGA мог устареть. Часть маршрутов могла не обновиться. Устройство могло прочитать TOS по RFC 1349. База могла прийти после дедлайна, а принятый RAMP пакет — не обработаться клиентом.

Порог различал локальную и общую потерю

Получатель RAMP сообщал NAK о пропущенных диапазонах. Отправитель собирал запросы в течение таймера. Если число запросов превышало порог, ремонт шёл multicast; иначе — unicast отдельным заявителям. Освобождённого из буфера пакета могло уже не быть.

Так одиночная потеря не навязывала повтор всей группе, а общая не превращалась в множество копий. Но NAK не устанавливал причину. Порог не доказывал, что ремонт нужен каждому. Повторная отправка не подтверждала приём, а приём — пригодность изображения.

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

Исторический проект не равен внедрению

RFC 1458 разобрал Multicast Transport Protocol из RFC 1301, отметил мастер, маркеры передачи и выборочное NAK-восстановление, но счёл концентрацию управления у мастера неподходящей для больших изображений. Фон группового IP-приёма задавал RFC 1112.

Это свидетельство конкурирующих проектов, не эксплуатации RAMP или MGA. RFC 1458 не называет внедрение и прямо говорит, что вопросы безопасности не обсуждаются. Членство не удостоверяло личность, регистрация не давала полномочий, метка качества не доказывала источник или целостность.

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