Персональный
сайт
Игоря
Сысоева


 
english
обо мне
 
sysoev.ru
 
nginx
 
mod_accel
mod_realip
mod_deflate
программирование
всякая всячина
windows
freebsd
apache
pppd
unix
web
 
 

Параметры asyncmap и escape

 

22.01.1999

Начнём издалека. Давным-давно был придуман способ программного управления потоком данных, получивший название XON/XOFF. Суть его заключается в следующем — когда принимающая сторона не успевает обработать приходящие данные, она посылает передающей стороне код XOFF и передающая сторона приостанавливает передачу. После того, как принимающая сторона управилась с пришедшими данными, она передаёт код XON и передающая сторона возобновляет передачу.

Хотя pppd, как и большинство коммуникационных пакетов и модемов, поддерживают программное управление потоком данных на участке между компьютером и модемом, сейчас оно уже почти не находит практического применения, и вместо него используется аппаратное управление потоком данных посредством сигналов RTS/CTS.

Тем не менее, рассмотрим случай использования программного управления потоком данных. Кодам XON и XOFF соответствуют численные значения 0x11 и 0x13. Предположим, в потоке данных, передаваемых удалённой стороне, есть байты, равные 0x11 и 0x13. Если pppd передаст эти байты в модем, модем воспримет их как управляющие коды XON/XOFF и не будет передавать их на другой удалённый модем. Кроме того, получив байт 0x13, он остановит передачу данных в компьютер до прихода байта 0x11, который, возможно, придёт совсем не скоро. Одним словом, случится бардак.

Во избежание этого бардака, pppd XORит (делает операцию XOR, исключающее ИЛИ) такие байты с числом 0x20. А для того, чтобы принимающая сторона восстановила их, pppd предваряет их управляющим символом 0x7D. Таким образом, байты данных, равные 0x11 и 0x13, будут передаваться как 0x7D 0x31 и 0x7D 0x33 и модем не будет обращать на них пристального внимания. Удалённая сторона, встретив код 0x7D, уберёт его из потока данных, а следующий за этим кодом байт отXORит с числом 0x20, вернув ему тем самым прежнее значение. Но что же теперь делать с байтами, равными 0x7D, ведь принимающая сторона вырезает их ? А то же самое. Байты 0x7D теперь будут передаваться как 0x7D 0x5D.

Теперь вернёмся к нашему барану asyncmap. С помощью этого параметра можно задать битовую карту для 32 управляющих кодов, значения которых находятся в интервале 0x00-0x1F. Все байты, значения которых заданы этим параметром, будут кодироваться описанным выше способом. Для кода 0x00 параметр будет выглядеть так — asyncmap 1, для кода 0x10 — asyncmap 10000 и так далее в том же духе. Например, для наших кодов XON и XOFF — asyncmap a0000.

Если Вы вообще не укажете этот параметр и удалённая сторона тоже не будет иметь на этот счёт никаких указаний, то все байты со значениями 0x00-0x1F будут передаваться как два байта, что равнозначно параметру asyncmap ffffffff. Например, в дистрибутиве MS Internet Explorer 3.02, размер которого 10 885 320 байт, такие байты составляют 13% и по линии передаётся 1 378 763 дополнительных байт, равных 0x7D. Конечно, какая-то их часть будет сжата протоколом V42.bis, а кроме того, увеличивается вдвое вероятность появления кодов 0x20-0x3F, кодов 0x00-0x1F вообще не будет, что также способствует сжатию. Но, тем не менее, объём передаваемых данных возрастает.

Поскольку мы не будем использовать программное управление потоком данных, а других управляющих кодов между модемом и pppd нет, то можно смело ставить asyncmap 0.

Надо заметить, что, хотя значения большинства управляющих кодов лежат в пределах от 0x00 до 0x1F, в некоторых протоколах существуют управляющие коды, которые не укладываются в этот диапазон. Для использовании подобного протокола в качестве среды для протокола PPP в pppd предусмотрен параметр escape. Например, параметр escape FF будет изменять байты данных, равные 0xFF. Кстати, сам протокол PPP использует два своих управляющих кода, один из них мы уже рассмотрели — это 0x7D, а второй — 0x7E. Никакие другие байты из диапазона 0x20-0xFF pppd по умолчанию изменять не будет.

Небольшая справка:
Windows 95/98 при PPP-соединении запрашивает у сервера asyncmap a0000, даже если сама Windows не использует программное управление потоком данных, но при этом легко соглашается на asyncmap 0.
Windows NT 4.0 сразу запрашивает asyncmap 0.

(C) Игорь Сысоев
http://sysoev.ru