Кратко

  • Обе стороны PPP должны были хранить одинаковую скользящую историю объёмом 8192 байта; 12-битный счётчик согласованности в каждом пакете MPPC обнаруживал потерю или неожиданный порядок.
  • При несовпадении получатель отбрасывал пакет и посылал Reset-Request. Отправитель очищал историю и ставил FLUSHED в следующем пакете; он очищал историю получателя и задавал новый счётчик без Reset-Ack.
  • Это узкое доказательство новой границы сжатия. Оно не возвращает потерянные данные и не доказывает надёжную доставку, целостность, личность, полномочие или завершение приложения.

Ответ управления заменили текущими данными

Общая процедура RFC 1962 выглядит как транзакция управления. После Reset-Request декомпрессор отбрасывает последующие сжатые пакеты, пока не придёт Reset-Ack с ожидаемым идентификатором; затем он возвращается в исходное состояние.

Профиль MPPC в RFC 2118 использует другую квитанцию. Если принятый счётчик отличается от ожидаемого, получатель отбрасывает пакет и отправляет запрос. Получив его, компрессор очищает историю и помечает следующий пакет MPPC флагом FLUSHED. Декомпрессор при его получении очищает свою историю и принимает счётчик из пакета. Синхронизация восстанавливается без Reset-Ack.

Следующий пакет не зависит от старой истории и потому служит действующим свидетельством новой эпохи. Но прошлое он не исправляет: пропуск остаётся, отдельной квитанции на Reset-Request нет, а передача приложению ещё не доказана.

Опция 18 разрешала конкретное преобразование

MPPC не был автоматическим свойством PPP. Его согласовывали опцией CCP типа 18 длиной 6; единственный бит выражал желание использовать алгоритм, а при окончательном разногласии сжатие не применялось. Реестр PPP IANA по-прежнему закрепляет тип 18 за Microsoft PPC.

Пакеты MPPC могли идти лишь после перехода PPP в фазу Network-Layer Protocol и CCP в Opened. Сжатые датаграммы имели PPP Protocol 0x00FD, тогда как сам CCP использовал 0x80FD. Первое значение классифицирует путь данных, но название алгоритма возникает из предшествующего согласования.

MPPC обрабатывал значения PPP Protocol от 0x0021 до 0x00FA. Остальные обходили компрессор. Принятая опция, следовательно, доказывала доступную способность, а не сжатие каждого пакета.

Память на 8192 байта связала пакеты

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

Бит A, названный FLUSHED, сообщал, что отправитель инициализировал историю до создания пакета. Бит B возвращал указатель в начало буфера и должен был появляться хотя бы раз на каждые 8192 сжатых байта. Бит C показывал, сжаты ли текущие данные. Эти признаки относятся к представлению и состоянию, но не к доставке услуги.

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

Двенадцать бит обнаруживали разрыв, а не проверяли содержимое

Счётчик начинался с нуля, увеличивался с каждым пакетом MPPC и возвращался к нулю после 4095. Несовпадение означало потерю или перестановку. Поэтому MPPC не требовал надёжной линии, хотя RFC 1663 определял надёжный режим PPP.

Одновременно RFC 2118 требовал последовательной доставки для успешной синхронизации. Отсутствие требования надёжной линии не означало безвредность произвольной перестановки. Совпавший счётчик не проверял байты. Раздел Security Considerations лишь говорит, что безопасность не обсуждается; конфиденциальность, криптографическая целостность, идентичность, авторизация и защита от повтора отсюда не возникают.

Информационный документ и историческая лицензия

RFC 2118 вышел в марте 1997 года со статусом Informational, а не Internet Standard. Раздел лицензирования ограничивал MPPC продуктами PPP для взаимодействия с MPPC/PPP и указывал на лицензии Stac Electronics. Это историческая запись, не вывод о современных лицензиях, патентах или развёртывании.

Дисциплину чтения задают Running-Code Primacy и Minimum Initial Specification: каждый сигнал должен нести только минимальное проверяемое утверждение. Опция фиксирует способность, счётчик — различие порядка, Reset-Request — просьбу о ремонте, а FLUSHED — новую историю. Ни один из них не объявляет результат чужого слоя.

Источники и граница доказательства

Первичный пакет включает RFC 2118 в HTML, текстовую версию, карточку RFC Editor и раздел исправлений, а также RFC 1962, RFC 1661, RFC 1663 и реестр IANA. Эссе Heng Lu направляют интерпретацию, но не заменяют источники протокола. Они устанавливают спецификацию и документальный статус, а не нынешнее применение, производительность, безопасность или исход конкретного пакета.