Кратко

  • Опция CCP описывает алгоритм, который получатель готов применять для распаковки; встречные направления могут выбрать разные методы, а неудачное согласование оставляет только одно направление без сжатия.
  • Configure-Ack подтверждает конкретный запрос, 0x00FD обозначает сжатую дейтаграмму без имени алгоритма, Reset-Ack подтверждает парный сброс. Ни один сигнал сам по себе не доказывает целостность, возврат потерянных данных или доставку приложению.

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

CCP начинает обмен только после перехода PPP в фазу протоколов сетевого уровня; ранние пакеты следует молча отбрасывать. Для сжатых данных требуется ещё и состояние Opened. Установленная линия не равна включённому сжатию.

Направление задаёт получатель

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

Неизвестная опция получает Configure-Reject. Известный метод с неприемлемыми значениями получает Configure-Nak с допустимыми значениями. Если отвергнуты все варианты, направление продолжает работу без сжатия. Локальное несовпадение не превращается в отказ всей связи.

Узкая квитанция Configure-Ack

По RFC 1661 Configure-Ack — положительный ответ на конкретный допустимый Configure-Request. Он фиксирует принятие этой последовательности опций в данном обмене. Для связи с будущим кадром нужны идентификатор, направление, параметры, эпоха состояния, Opened и отсутствие нового согласования.

RFC 2153 обобщила контейнер расширений поставщиков. OUI задаёт пространство имён, но не подтверждает одинаковый код. RFC 1915 фиксирует процедурную variance при работе с патентованными алгоритмами, а не их внедрение.

0x00FD не выбирает декодер

В открытом состоянии 0x00FD означает Compressed Datagram. При раздельном сжатии физических линий multilink данные используют 0x00FB, управление — 0x80FB. Реестр IANA подтверждает распределение номеров.

RFC 1962 прямо говорит, что 0x00FD не обозначает алгоритм. Получатель соединяет метку с текущим основным методом данного направления. Без протокола CCP и эпохи захваченный кадр нельзя уверенно приписать LZS, Predictor или частному расширению.

Сжатие может увеличить размер. Если результат не помещается в PPP Information, используется исходный пакет либо фрагментация профиля. Метка — категория обработки, не измерение экономии.

Рассинхронизацию обнаруживает профиль

При сжатии с историей одна потеря меняет последующие словари. Общий CCP не навязывает единый CRC. Алгоритм должен обнаруживать ненадёжную передачу либо требовать надёжный транспорт, например numbered mode из RFC 1663.

RFC 1974 предлагает для Stac LZS номера последовательности, LCB, CRC и несколько histories. RFC 1967 применяет собственные биты проверки и сброса. Эти сведения отсутствуют в 0x00FD. Классификация кадра и проверка распакованных байтов требуют разных свидетельств.

Сброс не возвращает отброшенное

Обнаружив ошибку, получатель посылает Reset-Request с кодом 14 и отбрасывает сжатые пакеты направления до Reset-Ack с кодом 15 и ожидаемым идентификатором. Партнёр очищает передающий компрессор и отвечает; получатель очищает декомпрессор. Обратное направление сохраняет своё состояние.

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

Подход Heng Lu о первичности работающего кода не позволяет сделать из документа или номера больше, чем они исполняют. Лестница доказательств такова: фаза, запрос направления, Ack, Opened, реальный компрессор, метка, проверка, сброс, первая верная распаковка, приём конечной системой, результат приложения. Устойчивость RFC 1962 — в сохранении этих границ.

Sources