Linux.yaroslavl.ru

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

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

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

Во избежания этого бардака, pppd XORит (делает операцию XOR, иcключающее ИЛИ) такие байты с числом "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", в некоторых протоколах существуют управляющие коды, которые не укладываются в этот диапазон. Для успешной передачи байт данных, равных таким кодам, в 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.