Кратко

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

Ошибка, которая не переписывает прошлое

RFC 4077 позже назвала один из сбоев SigComp прямо: STATE_NOT_FOUND. Получатель не смог найти состояние, на которое сослалась сжатая сигнальная посылка, и возвращал его идентификатор в отрицательном подтверждении. Обычно после этого компрессор должен был перестать использовать такой базис для будущих сообщений.

Легко прочитать этот NACK как доказательство, что состояние никогда не существовало. RFC 3321 оставляет другую возможность. Состояние могло быть успешно создано и явно подтверждено, а затем удалено из-за нехватки памяти. Положительная и отрицательная записи описывают разные моменты. Конфликт возникает только в системе наблюдения, которая отбросила время.

RFC 3321 была опубликована в январе 2003 года как Informational, а не как стандарт Интернета. Она описывала расширенные операции SigComp поверх UDVM из RFC 3320: явные подтверждения, совместное сжатие, состояние между сеансами, пользовательские словари и контрольные состояния. Документ не доказывает внедрение, совместимость реализаций или измеренный выигрыш.

Для чего понадобилось положительное подтверждение

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

RFC 3321 требует использовать только состояние, установленное у удалённого декомпрессора: иначе последует сбой распаковки. Надёжный транспорт вроде TCP гарантирует доставку предыдущего сообщения, но не бессрочное хранение производного состояния. Доставка, разрешение приложения на сохранение, фактическое создание и дальнейшее присутствие в памяти остаются отдельными фактами.

Предыдущая статья о RFC 3320 рассматривала границу между успешной распаковкой и правом создать постоянное состояние. Здесь создание уже разрешено и подтверждено. Центральный вопрос иной: какое последующее событие делает старую квитанцию недостаточной для нового действия?

Контрольная точка с конечным сроком

Раздел RFC 3321 о checkpoint state перечисляет три пути к отсутствующему состоянию. Создающее сообщение могло потеряться. Памяти могло не хватить при создании. Наконец, установленное состояние могло быть позднее удалено из-за дефицита памяти.

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

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

Неявный сигнал мог пережить состояние

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

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

Частичный идентификатор тоже не несёт полной семантики. Он может относиться к подтверждённому, совместному или глобальному состоянию; тип выводит реализация. Базовая реализация SigComp вправе игнорировать расширенные идентификаторы. Поэтому значение в трассе не доказывает ни одинаковую интерпретацию сторонами, ни актуальное наличие объекта.

RFC 4896 показала неопределённость без нарушения правил

RFC 4896 уточнила странный порядок приоритетов: 65535 — минимальный, затем 0 и дальше 1–65534. Приоритет относится к ссылке compartment на состояние, а не просто к глобальному набору байтов.

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

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

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

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

Sources