Summary

  • В формате co_repair RFC 5225 CRC-7 охватывает всю восстановленную несжатую цепочку заголовков, а отдельный управляющий CRC-3 — применимые управляющие поля. Эти поля могли не участвовать в декомпрессии несущего их пакета.
  • Принятие текущего результата, продвижение постоянного состояния и положительная обратная связь должны быть разными решениями. Каждое решение опирается только на свидетельство, область которого действительно включает разрешаемое действие.

В одной успешной операции спрятаны два времени

Декомпрессор восстановил заголовок, CRC-7 совпал, пакет можно обрабатывать. Это факт о настоящем. Но тот же пакет может нести управляющие поля, меняющие общий контекст. Новый контекст станет основанием для интерпретации пакетов, которые ещё не пришли.

Поэтому в co_repair есть control_crc3_encoding. CRC-7 вычисляется по всей восстановленной несжатой цепочке заголовков. Управляющий CRC-3 вычисляется по объединению применимых управляющих полей. Это не две степени уверенности в одном объекте, а две проверки разных объектов.

RFC 5225 прямо объясняет разделение: обновляемые поля не всегда используются для декомпрессии заголовка, который их переносит, и потому не обязательно защищены CRC-7. Без отдельной проверки декомпрессия может пройти, положительная обратная связь — уйти, а управляющие поля — обновиться неправильно.

Контекст переносит риск через границу транзакции

ROHC экономит передачу, потому что компрессор и декомпрессор поддерживают общее состояние. То, что не отправлено в текущем пакете, должно быть достоверно восстановлено из контекста. Поэтому изменение состояния — обязательство перед последующими операциями.

В состоянии Repair Context пакеты уже могли успешно декомпрессироваться, хотя всему контексту ещё нельзя доверять. Пакет с предусмотренной проверкой CRC-7 или CRC-8 способен вернуть Full Context. Поздний по последовательности пакет может успешно декомпрессироваться, но не обновлять состояние и не получать ACK. Обнаружение повреждения контекста зависит от реализации.

Спецификация тем самым сохраняет неопределённость как явное состояние. Успешный выход и доверие к основе будущих выходов не сливаются в одну запись.

У каждой проверки есть подлежащее

Фраза «CRC прошёл» неполна без перечня данных, вошедших в вычисление. CRC-7 в co_repair говорит о восстановленном заголовке; CRC-3 — об управляющих полях. Ни один из них не является криптографической подписью и не доказывает источник, доставку приложению, качество связи или корректность названного продукта.

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

Отложенная ошибка наследует зелёную метку

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

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

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

Разделить использование, изменение и подтверждение

У операции с видимым результатом и скрытым состоянием должны быть три независимых ответа. Можно ли использовать результат? Нужно ли продвигать постоянное состояние? Следует ли посылать положительное подтверждение?

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

Что источники не устанавливают

RFC 5225 не сообщает о сбое конкретного телефона, модема, мобильной сети, оператора, поставщика или реализации. В нём нет текущей доли внедрения, инцидента, реальной трассы пакетов или показателя качества. Реестр IANA доказывает наличие идентификаторов, а не их использование.

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

Хранить двойную квитанцию успеха

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

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

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

Sources

Дополнительные записи стандарта

  1. RFC 5225 в текстовом формате
  2. Информационная запись RFC 5225
  3. Запись RFC 5225 в Datatracker
  4. История RFC 5225
  5. Исправления RFC 5225
  6. Встроенный просмотр исправлений RFC 5225