O пpотоколле ASL (Михаил Лихачев)
        
                         Все об ASL!
        
        DG>  Hаcколько я понял,  неапгpейженные Sportster'ы  14400  не  yмеют
        DG>  повышать cкоpоcть  пpи  pетpейнах.  Пpавда,  в некотоpых моделях
        DG>  можно включить ASL,  котоpый бyдет pаботать  только  c  модемами
        DG> USR.  Что  можно  cказать в отношении модемов Russian Courier по
        DG>  этомy поводy?  Умеют ли они повышать  cкоpоcть  пpи  pетpейне  c
        DG>  модемами дpyгих фиpм?  Имеетcя ли там cабж - Adaptive Speed Rate
        DG>  -  cпоcобноcть  динамичеcки  изменять  cкоpоcть  в   линии   без
        DG>  pетpейна (опять же пpи коннекте c модемами дpyгих фиpм)?
        
        
        Это довольно большой вопрос, на котором в полном объеме ответить не очень 
        легко.
        Попробую сделать это в доступной форме и не очень подробно.
        
        ASL, как и HST - это расширения протоколов V.42 (а последний еще - и MNP),
        которые используют высокоуровневое управление там, где обычные модемы
        управляются только по стандарту V.32, что имеет ряд существенных 
        приемуществ перед стандартной схемой. Вот некоторые из них:
        
        Точный подбор оптимальной скорости, вплоть до разных скоростей в разные стороны.
        Делается это так: принимающая сторона анализирует качество сигнала (Signal
        Quanity по команде ATY7 именно это и выводит, но имейте в виду, что во всех
        моделях 28800 эта команда выводит бред), и делает заключение о том, какая именно
        скорость оптимальна в настоящий момент. Затем, накопив некоторую статистику,эта
        информация передается удаленной стороне с требованием переключить скорость
        передачи на указанную. Вот фрагмент статистики реального времени от модема
        RC-21600 (+Req - наш запрос, *Ack - удаленный запрос):
        02:15:30.71 *ACK:2D:0001 -- Primary V32 connect established at 7200
        
        Это - свойство ASL-коннкетов - начинать соединение на низкой, более
        помехоустойчивой скорости.
        
        02:15:30.71 *ACK:03:0000 -- Transmit channel opened
        02:15:30.77 *ACK:02:0000 -- Receive channel opened
        02:15:30.77 +req:0A:0003 -- Set data receive mode
        02:15:30.77 *ACK:20:0007 -- New recommended speed is (1) 21600
        02:15:30.77 +req:44:003F -- Enable eV32
        
        Это - включение ASL. После чего (по логу не видно) был послан запрос поднятия
        скорости приема на удаленную сторону.
        02:15:32.82 +req:41:0007 -- Wait for receive speed shift at eV32 to 9600t
        02:15:32.82 *ACK:22:0000 -- Speed shift granted
        02:15:32.82 *ACK:02:0000 -- Receive channel opened
        
        
        
        Следующий запрос:
        02:15:34.33 +req:41:0008 -- Wait for receive speed shift at eV32 to 12000t
        02:15:34.38 *ACK:22:0000 -- Speed shift granted
        02:15:34.44 *ACK:02:0000 -- Receive channel opened
        
        А вот это с той стороны пришел запрос:
        02:15:34.88 +req:40:0007 -- Set new transmit speed at eV32 to 9600t
        
        Опять наш запрос:
        
        02:15:36.55 +req:41:0009 -- Wait for receive speed shift at eV32 to 14400t
        02:15:36.55 *ACK:22:0000 -- Speed shift granted
        02:15:36.55 *ACK:02:0000 -- Receive channel opened
        
        Это - опять с той стороны. Буква t означает тербовскую, более устойчивую
        модуляцию. Такое возможно только на связи RC-RC, поскольку у Роботиксов
        здесь ошибка, и вместо тербовской они используют устаревшую модуляцию на
        скоростях до 16800. Это касается всех модемов 28800 и выше в том числе.
        02:15:36.77 +req:40:0008 -- Set new transmit speed at eV32 to 12000t
        
        ----------------------------
        
        А в стандартном V.32 это выглядит вот как:
        01:36:36.16 *ACK:41:0000 -- Remote requests fallback
        
        Это удаленная сторона решила поменять скорость.
        01:36:36.16 +req:42:0FF1 -- Set valid speeds mask: 4800,7200,9600,12000,,,
        
        Это мы запретили все, выше _нашей_ рекомендуемой скорости,  поскольку требуется
        установить Min(наша, удаленная) допустимая скорость.
        
        01:36:36.27 *ACK:20:0006 -- New recommended speed is (1) 19200
        01:36:36.33 *ACK:20:0005 -- New recommended speed is (1) 16800
        
        А теперь мы обнаружили, что связь улучшилась, а удаленная сторона прислала в
        свое время маску, где сказано что она может работать и быстрее. Запрашиваем
        поднятие скорости:
        
        01:36:36.33 +req:42:0FF9 -- Set valid speeds mask: 4800,7200,9600,12000,14400,,
        01:36:36.33 +req:3E:003F -- FallBack request at sV32
        
        Hа слух это - короткое (доли секунды) попискивание, то есть голая несущая без
        модуляции.
        01:36:36.38 *ACK:42:0000 -- Our fallback request granted by remote
        
        Вот здесь - потенциальная дырка: по таймауту начинается длинный ретрейн.
        01:36:36.44 *ACK:2D:0003 -- Primary V32 connect established at 12000
        
        Облом. Удаленная сторона решила, что 14400 для нее слишком много, и вычеркнула
        из маски допустимых скоростей.
        
        01:36:36.44 *ACK:03:0000 -- Transmit channel opened
        01:36:36.44 *ACK:02:0000 -- Receive channel opened
        01:36:36.49 *ACK:20:0006 -- New recommended speed is (2) 19200
        01:36:36.55 *ACK:20:0007 -- New recommended speed is (1) 21600
        
        А хоть 115200 - у удаленной стороны нет таких скоростей, или она по крайней 
        мере не желает их показывать.
        
        ----------------------------------
        
        Как видно из вышеприведенного, может ли быть повышена скорость во время
        коннекта, полностью определяется удаленным модемом: спортстеры и курьеры все -
        могут. Практика показывает, что если с той стороны стоит кусок г.., то он один
        раз сползает до 7200, скажем, и дальше такую маску и ставит все время. Кроме
        того, о скорости _в его_ сторону он сам и должен забоиться. Если он этого не
        делает, то ничего хорошего не будет. Если же брать ASL, то там совсем другой,
        "мягкий" механизм изменения скорости, и впридачу еще и быстрые ретрейны, без
        настройки эхогашения. А HST - это практически то же самое, что и ASL, с разницей
        лишь в том что длинных ретрейнов не бывает в принципе, поскольку нет эхогашения
        как такового, так как обратный канал не перекрывает спектр частот прямого.
        Особенно смешно бывает читать высказывания [не будем показывать пальцем],
        которые говорят что в 28800 HST существенно лучше: он не может быть ни лучше, ни
        хуже по определению, так как иначе был бы просто несовместим. Может быть хуже
        (что и имеет место быть в 28800) сигнальная часть, занимающаяся модуляцией на
        нижнем уровне, что практически означает более низкую рекомендуемую (при прочих
        равных условиях) скорость, чем в моделях 14400. Это объясняется врожденной
        "глухотой" моделей 28800. А вот это свойство проявляется отнюдь не только на
        HST, а на всех протоколах вообще, поскольку с точки зрения модуляции протокол
        HST есть ни что иное как односторонний V.32, и в принципе не может быть лучше,
        как не может быть "лучше" таблица умножения: либо она верная, либо - нет. Он
        может либо врать из-за неправильно посчитанных сигнальных таблиц, как это
        делается в глюко-тербе (которую этот же автор одно время обещал "исправить"),
        либо быть глухим, как в 28800, и пропускать "мимо ушей" половину используемых
        при модуляции состояний. Точную причину этой глухоты мы сейчас и изучаем ...
        
        
        
                                    Михаил Лихачев.