Кратко

  • RFC 3940 присваивал передаваемому NormObject номер в пределах отправителя, чтобы связать данные и ремонт, но не создавал глобальный или постоянный идентификатор содержимого.
  • Поле имело 16 бит и могло повториться после оборота счётчика; долговечное имя приложение должно было определить в NORM_INFO либо в самом содержимом.

Тишина получателей требовала точной метки

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

Для ремонта всё равно требовалось понимать, к какому объекту относится сегмент или запрос. Опубликованный в ноябре 2004 года как экспериментальный RFC 3940 использовал object_transport_id. Отправитель назначал растущие значения и сохранял одно значение для передачи и ремонта объекта. Вместе с идентификатором отправителя, который переносил протокол, оно различало NormObject, пока тот находился в сеансе.

Метка отвечала на вопрос о текущей перевозке, но не называла произведение, версию или архивную запись.

FILE был подсказкой о хранилище

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

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

Конечная последовательность возвращалась

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

Документ прямо провёл границу: заголовки NORM не предоставляли глобальную или прикладную идентификацию содержимого. Транспортные идентификаторы действовали лишь пока отправитель передавал или ремонтировал объект. Монотонный рост давал локальный порядок, но не вечную уникальность.

В ноябре 2009 года RFC 5740 заменил RFC 3940 и перевёл NORM на стандартизационный трек. Разделение сохранилось. Преемник сформулировал ещё определённее: в долгом сеансе поле совершит оборот и повторится. Стандартный транспорт не превратил временную метку в ключ архива.

Небольшая карточка могла сопровождать груз

NORM_INFO позволял приложению приложить к объекту необязательный контекст. Одним из примеров служил MIME-тип. Получатель мог посмотреть карточку и решить, участвовать ли в надёжном приёме, а пропущенную INFO запросить повторно.

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

Общий транспортный номер связывал INFO с нужным объектом во время отправки. После закрытия окна ремонта оставить только номер, выбросив экземпляр отправителя, поколение сеанса и прикладной ID, — всё равно что сохранить талон без адреса гардероба и даты. При следующем появлении числа не протокол объявляет два содержимых одним; архив забывает область действия.

Полный объект мог попасть в чужую карточку

Представим кэш, который постоянно использует только протокольный идентификатор отправителя и 16-битный номер. Он теряет состояние, возвращается после оборота счётчика и получает новый объект под знакомым ключом. Все нынешние сегменты доставлены и восстановлены правильно, но кэш прикрепляет к ним старое название, срок хранения или разрешения.

Это вывод из модели, а не утверждение об инциденте. Он показывает разные роли доказательств. Транспортное состояние связывает сегмент с активным объектом. Хеш приложения может сравнить байты. Постоянный ID связывает доставку с версией. Разрешение и публикация требуют собственных решений. Успех одного слоя не передаёт ему полномочия следующего.

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