Кратко

  • RFC 3269 рассматривал надёжную многоадресную передачу как семейство решений, зависящих от приложения, а не как универсальный транспорт. Подход на основе строительных блоков стал обязательством по описанию: повторно используемые компоненты должны были раскрывать область применения, интерфейсы, зависимости и границы отказа, а инстанциация протокола — описывать систему целиком.
  • Главным было предупреждение о композиции: два компонента могут работать по отдельности в парах и отказать при совместном использовании с третьим. Поэтому повторное использование — цель проектирования, но не доказательство совместимости, безопасности, развёртывания или принятия.

Проблема границ за модульностью

Reliable Multicast Transport (RMT) исходил из практического различия требований. Массовая доставка файлов, интерактивная совместная работа и потоковое вещание различаются размером группы, задержкой, порядком доставки, числом отправителей и терпимостью к неполной доставке. RFC 2357 уже считал такие различия и внешние последствия перегрузки основаниями для проверки предложений. RFC 3269 задавал другой вопрос: если одного протокола недостаточно для всех задач, что спецификация должна раскрыть до повторного использования её частей?

Ответом не было притворство, будто каждый строительный блок независим. RFC 3269 признавал контекстную зависимость некоторых блоков. A с B может работать, B с C тоже, а A, B и C вместе — нет. Зависимость, незаметная в одной паре, при добавлении другого блока превращается в несовместимость. Прямоугольник на архитектурной схеме сам по себе не доказывает существование реальной границы.

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

Компонент — ещё не собранный протокол

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

Положение о соответствии устанавливало единицу утверждения: инстанциация вместе с указанными документами строительных блоков должна полностью описывать работающий протокол RMT согласно более ранним требованиям RFC 2357. Это не превращало RFC 3269 в отчёт об испытаниях и не гарантировало совместимость реализаций. Оно определяло набор документов, доступных читателю для проверки до оценки формулировки «работающий протокол».

Правило о форматах пакетов особенно наглядно. Инстанциация RMT должна была сначала определить использование поверх UDP. Решение о собственном номере IP-протокола откладывалось до момента, когда протокол будет достаточно развёрнут и понят. Так документ отделял завершённость проектирования от дефицитного выделения номера в реестре и от последующего доказательства принятия. Это граница спецификации, а не доказательство широкого развёртывания конкретного протокола.

RFC 3048 описал разделение повторно используемых блоков и ядер, специфичных для каждого протокола. RFC 3269 добавил обязанности авторов, делающие это разделение понятным. В 2009 году RFC 5651 прямо указал, что при обновлении прежней спецификации блока LCT следует рекомендациям RFC 3269. Это прослеживаемый пример преемственности документов, но не подтверждение всеобщего соблюдения или результата внедрения.

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

Источники