38. Магическое число

Представьте ситуацию, когда ваша программа клиент шлет сообщения серверу, но последний располагается не на удаленном, а на вашем собственном компьютере. Вместо того чтобы сообщение вышло наружу и пошло по Интернет, а затем вернулось обратно на сервер, модуль РРР организует так называемую «петлю» (loop-back), о которой вскользь уже упоминалось. Соединение-петля позволяет приложениям типа клиент-сервер, находящимся на одном и том же компьютере, взаимодействовать, не передавая никаких данных по сети. Другими словами, программа делает вид, что посылает сетевые данные, а на самом деле просто оставляет их себе. Сетевое программное обеспечение должно уметь выяснить, что канал является петлей, и затем использовать его подобающим образом. Вариант конфигурации магического числа служит для распознавания канала-петли. В общем, магическое число — это уникальное в рамках сеанса число, используемое модулем РРР для распознавания канала-петли, а также некоторых других специальных случаев конфигурации уровня соединения. По умолчанию магическое число не устанавливается, а его полю присваивается значение 0.

Примечание:Магическое число и его использование подробно рассматривается в документе RFC 1661.

Схема конфигурации магического числа предполагает, что вероятность того, что оба ведущих сеанс связи компьютера выберут одно и то же число, пренебрежимо мала. Как правило, для выбора магического числа запрашивается функция генерации случайных величин. Схема конфигурации выглядит так: когда модуль РРР получает пакет «конфигурация-запрос» с вариантом конфигурации магического числа, он сравнивает его с предыдущим собственным пакетом «конфигурация-запрос» . Если магические числа различны, это значит, что канал-петля отсутствует.

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

Установив наличие канала-петли, модуль РРР продолжает описанный выше процесс снова и снова. Протокол РРР обеспечивает метод определения канала-петли, но ничего не говорит о том, как следует обрабатывать такую ситуацию. Таким образом, обработка ситуации наличия канала-петли целиком зависит от особенностей конкретной реализации протокола.

39. Сжатия данных поля протокола

Мы уже знаем, что РРР позволяет размещать обычно двухбайтовое поле протокола в одном байте. Вариант конфигурации сжатия данных поля протокола (Protocol Field Compression, PFC) позволяет РРР договориться с удаленным модулем о таком сжатии. Послав пакет «конфигурация-запрос» на установление сжатия данных поля протокола и получив положительный ответ, то есть пакет «конфигурация-подтверждено», оба модуля продолжают сеанс, размещая поле протокола в одном байте вместо двух. Однако любая реализация РРР обязана уметь работать и без такого сжатия, то есть используя нормальное двухбайтовое поле. Протокол РРР никогда не сжимает поле протокола в пакетах LCP. Пакеты LCP всегда имеют двухбайтовое поле протокола. Это необходимо, так как на стадии обмена пакетами LCP один модуль РРР может еще не знать, выбран ли тот или иной метод сжатия его партнером. Имейте также в виду, что, подсчитывая контрольную сумму CRC пакета и сжимая данные в поле протокола, модуль РРР исходит из того, что кадр РРР тоже сжат.