Наиболее часто используемой функцией коммуникационного программного обеспечения является функция передачи файлов. Она осуществляется с помощью специальных протоколов передачи файлов. Выбор и использование протокола передачи файлов может производится пользователем в явном виде, как это делается в терминальных программах, так и в неявном, например в игровых программах, поддерживающих модемную связь.
Основными задачами протоколов передачи файлов являются:
- обеспечение безошибочной передачи данных;
- управление потоком передаваемых данных;
- передача вспомогательной информации;
- защита соединения.
Первые протоколы передачи файлов появились задолго до модемов, поддерживающих аппаратное исправление ошибок. По этой причине задача обеспечения безошибочной передачи по сегодняшний день остается одной из их основных. Для ее реализации применяются в основном те же методы, что и в современных протоколах исправления ошибок. Передаваемые данные разбиваются на блоки (кадры) определенной длины, и в каждый из них включается проверочная комбинация (CRC) для обнаружения ошибок. Эта комбинация формируется по определенному правилу на основе передаваемых информационных битов блока. На приемной стороне производится повторное вычисление проверочной комбинации по тому же правилу и сравнение ее с принятой. При совпадении проверочных комбинаций принимающая сторона посылает подтверждение правильного приема блока (АСК), а при несовпадении — запрос на повторную передачу данного блока (NACK). Таким образом реализуется механизм автоматического запроса повторения (ARQ), аналогичный механизму ARQ в протоколах исправления ошибок типа MNP классов 1—4 и V.42. При этомARQ также может быть стартстопного типа (SAW), с возвратом на N шагов (GBN) или селективного повторения (SR).
При использовании ARQ типов GBN и SR непрерывная передача неподтвержденных блоков данных может привести к перегрузке буферов как приемника, так и передатчика. Что бы этого не происходило используется управление потоком передаваемых данных.
Перед непосредственной передачей файла необходимо установить соединение на уровне канала данных (уровень 2 модели OSI), передать информацию о имени файла, его размере, дате последней его модификации и т.п., а после передачи — произвести разъединение канала данных. Все это осуществляется при помощи вспомогательной служебной информации, передаваемой по каналу связи.
В последние годы в функции протоколов передачи файлов включают защиту соединения, например проверку пароля.
Среди протоколов, рассчитанных на отсутствие аппаратной защиты от ошибок можно выделить широко распространенные протоколы XModem, XModem-CRC, XModem-1 К, YModem, Kermit, ZModem и ряд других.
Если же применяются модемы с аппаратной коррекцией ошибок (поддерживающие протоколы типа MNP или V.42), то предпочтительнее использовать протоколы передачи файлов типа YModem-g и ZModem. В этом случае исключается потеря времени на повторный запрос данных, переданных с ошибками. Протокол Zmodem допускает оба варианта применения.
Известны специализированные протоколы, предназначенные для определенных служб и сетей, — такие как SEALink, Telnet, CompuServe Quick В. Практически все они являются модификациями протокола XModem.
Рассмотрим подробнее наиболее распространенные протоколы передачи файлов.
Протокол XModem, разработанный Бардом Христенсеном, благодаря широкому использованию в справочных службах и введению в недорогие связные программы для PC стал фактическим стандартом для связи между персональными компьютерами.
Последовательность операций, выполняемых приемником и передатчиком при передаче файла с помощью протокола XModem, показана в табл. 9.1.
Передающий компьютер начинает передачу файла только после приема от принимающего компьютера знака NAK (Negative AcKnowledge), представляющего собой последовательность <0010101> в кодировке ACSII. Принимающий компьютер передает эту последовательность до тех пор, пока не начнется передача собственно файла. Если передано девять знаков NAK, а передача файла не началась, процесс должен быть возобновлен вручную.
Таблица 9.1. Передача файла с помощью протокола XModem
| ПЕРЕДАТЧИК | Направление передачи | ПРИЕМНИК |
| <NAK> | ||
| <SOH> 01 FE <данныехС8> | ^ | , |
| < | <АСК> | |
| <SOH> 02 FD <данныехС8> | -* | (помеха в канале связи) |
| <NAK> | ||
| <SOH> 02 FD <данныехС8> | -* | |
| <- | ||
| <SOH> 03 FC <данные> <CS> (знак АСК искажен) | -* | |
| *- | <АСК> | |
| <SOH> 03 FC <данныехС8> | ||
| <АСК> | ||
| <ЕОТ> | -* | |
| <любой знак кроме АСК> | ||
| <ЕОТ> | , -t........... | |
| 4— | <АСК> | |
| Передача файла завершена | ||
После приема знака NAK передающий компьютер посылает знак начала блока SOH (Start Of Header) (Olh), два номера блока (сам номер и его двоичное дополнение по "единицам"), блок данных из 128 байт и контрольную сумму блока CS (Check Sum). Блоки нумеруются по модулю 256. Контрольная сумма размером в 1 байт представляет собой остаток от деления на 255 суммы значений кодов ASCII знаков, входящих в блок данных.
Принимающий компьютер тоже вычисляет контрольную сумму и сравнивает ее с принятой. Если сравниваемые значения различны либо прошло 10 с, а прием блока не завершен, принимающий компьютер посылает передатчику знак NAK, означающий запрос на повторную передачу последнего блока. Если блок принят правильно, приемник передает подтверждение его приема знаком АСК (06h). В случае, если следующий блок не поступил в течение 10с, то передача знака АСК повторяется до тех пор, пока блок не будет принят правильно. После девяти неудачных попыток передачи блока связь прерывается.
В протоколе используется двукратная передача номера. Это исключает повторную передачу одного и того же блока из-за потери подтверждающего сообщения. Принимающий компьютер контролирует уникальность номеров принимаемых блоков. Если блок ошибочно передан повторно, то он сбрасывается. После успешной передачи всех данных передающий компьютер посылает знак завершения передачи EOT (End Of Transmission) (04h), сообщающий об окончании передачи файла.
Перерыв в передаче блока свыше 1 с считается перерывом связи.
Преимущества данного протокола перед другими заключаются в его доступности для разработчиков программных средств, простоте реализации на языкахвысокого уровня, малом объеме приемного буфера (256 байт) и возможности передачи не только символьных (в кодах ACSII), но и исполняемых файлов (*.сот и *.ехе). Последнее возможно благодаря тому, что конец файла определяется подсчетом переданных байтов и использованием вместо знака файлового маркера (Ctrl-Z, "Z) специального сигнала завершения. Вероятность необнаруженной ошибки при передаче данных этим протоколом составляет PHO=0,0004 , что несколько ниже, чем при обычной асинхронной проверке паритета, где рно=0>05.
К основным недостаткам протокола Xmodem можно отнести низкую производительность, обусловленную в основном использованием'механизма ARQ типа SAW, большую вероятность необнаруженных ошибок, необходимость задания имени файла при приеме и относительно большой объем передаваемой служебной информации.
Последующие модификации протокола XModem были направлены на устранение этих и некоторых других его недостатков.
Протокол XModem-CRC представляет собой модификацию протокола XModem, в котором обнаружение ошибок производится с использованием циклического кода. Длина проверочной последовательности составляет 16 бит (CRC-16). Благодаря этому гарантируется обнаружение практически всех одиночных и двойных ошибок, всех нечетных ошибок, всех пакетов ошибок длиной до 16 знаков, а также всех 17-битовых ошибок с вероятностью 0,999969 и более длинных пакетов ошибок с вероятностью 0,999984.
В начале соединения вместо знака NAK приемник передает последовательность знаков "с" (63h). Если передатчик не поддерживает протокол XModem-CRC, он игнорирует эти знаки. Не получив ответа на передачу трех знаков "с", приемник переходит на работу по протоколу XModem и передает знаки NAK.
Протокол XModem-IK представляет собой модификацию протокола XModem-CRC с блоками длиной 1024 байт. Использование блоков длиной 1 Кбайт позволяет снизить задержки при передачи файлов по системам связи с временным уплотнением, с использованием современных модемов и в сетях с коммутацией пакетов, где длина пакета, как правило, равна величине 1024 байт либо кратна ей. Кроме того, по сравнению с обычным протоколом Xmodem, уменьшена относительная доля заголовков в общем объеме передаваемой информации.
Таблица 9.2. Передача файла с помощью протокола XModem-lK
| ПЕРЕДАТЧИК | Направление передачи | ПРИЕМНИК |
| *- | <s —kdoom.wad> | |
| <doom wad open x.x minutes > (файл doom.wad открыт в x.x минут) | ||
| <с> | ||
| <STX>01 РЕ<данные[1024]хСНС-16> | -* | |
| *- | <АСК> | |
| <STX> 02 FD <данные[1024]хСРС-16> | ||
| «- | <АСК> | |
| <STX> 03 FC <данные[1000]> <CPMEOF [24]> <CRC-16> | -» | |
| <АСК> | ||
| <ЕОТ> | -» | |
| «— | <АСК> | |
| Передача файла завершена | ||
Для передачи приемнику сообщения об увеличении длины передаваемогоблока вместо знака SOH (Olh) в начале блока ставится знак STX (02h). Номер блока, передаваемый во втором и третьем бантах увеличивается на единицу независимо от его длины.
Передатчик не должен изменять длину блока в диапазоне от 128 до 1024 байтами до тех пор, пока не будет принят знак АСК для текущего блока. Игнорирование этого ограничения может привести к необнаружению ошибок.
При использовании блоков по 1024 байт возможно увеличение длины передаваемого файла до значения, кратного 1024. Блоки длиной 1024 байт могут
Таблица 9.3. Передача блоков по 1024 и 128 байтов с помощью протокола XModem-lKприменяться при групповой или одиночной передаче файлов. Для сохранения целостности передаваемых данных с протоколом Х Modem-1 К необходимо использовать CRC-16.
| ПЕРЕДАТЧИК | Направление передачи | ПРИЕМНИК |
| ^ | <s—kdoom.wad> | |
| <doom,wad open x.x minutes > | - -» | |
| <с> | ||
| <STX> 01 FE <данные[1024]хСРС-16> | -* | |
| <- | <АСК> | |
| <STX> 02 FD <данные[1024]хСНС-16> | -* | |
| <АСК> | ||
| <STX> 03 FC <данные[128]хСПС-16> | ||
| <АСК> | ||
| <STX> 04 FB <данные[100]> <CPMEOF [24]> <CRC-16> | -» | |
| <АСК> | ||
| <EOT> | -» | |
| <АСК> | ||
| Передача файла завершена | ||
Процесс передачи блоков и управляющих сигналов между передатчиком и приемником при использовании протокола XModem-lK иллюстрируется табл. 9.2 и 9.3.
Протокол YModem представляет собой протокол XModem-CRC, в котором реализована групповая передача кадров. Все программы, реализующие протокол YModem, должны выполнять следующие функции:
^ передавать информацию о имени и пути файла в-блоке 0 в виде строки знаков ASCII, завершающейся знаком NUL (Oh);
- использовать эту информацию на приемной стороне в качестве имени и пути принятого файла, если иная реализация не оговорена специально;
- применять проверку CRC-16 при приеме знаков "с", в противном случае использовать 8-битовую контрольную сумму;
- принимать любую комбинацию из 128- и 1024-байтных блоков внутри каждого принимаемого файла;
- обеспечивать возможность переключения длины блоков в конце передачи файла (файлов) и (или) в случае частых повторных передач;
- передающая программа не должна изменять длину неподтвержденного блока;
- передавать в конце каждого файла знаки EOF до десяти раз, пока не будет принят знак АСК;
-• обозначать конец сеанса связи нулевым (пустым) именем пути.
Коммуникационные программы, в которых не реализованы все перечисленные функции, не совместимы с протоколом YModem. Выполнение этих минимальных требований, однако, не гарантирует надежной передачи файлов в условиях сильных помех.
Протокол YModem устраняет некоторые недостатки протокола XModem, в основном сохраняя его простоту. Процесс передачи файлов с использование протокола YModem иллюстрируется табл. 9.4 и 9.5.
Как и в случае передачи одного файла, приемник инициирует групповую передачу путем посылки знака "с" (для режима CRC-16).
Передатчик открывает файл и передает номер 0.
Для групповой передачи требуются только имена файлов. Для обеспечения совместимости "снизу вверх" все неиспользуемые байты блока 0 должны иметь значение 0.
Таблица 9.4. Групповая передача файлов с помощью протокола YModem
| ПЕРЕДАТЧИК | Направление передачи | ПРИЕМНИК |
| <- | <sbdoom."xCR> | |
| "Передача в групповом режиме! | -* | |
| «- | <с> (command:rb) | |
| <SOH> <00 FF doom.exe NUL[123]> <CRC-16> | -> | |
| *- | <с> | |
| <SOH> 01 FE <данные[1281><СПС-16> | -» | |
| «- • | <АСК> | |
| <SOH> 03 PC <данные[1024]хСРС-16> | -» | |
| <АСК> | ||
| <SOH> 04 FB <данные[1001> <СРМЕОР [28]> <CRC-16> | ^ | |
| <- | <АСК> | |
| <ЕОТ> | ||
| ^ | <NAK> | |
| <ЕОТ> | -» | |
| *- | <АСК> | |
| <- | <с> | |
| <SOH> <00 FF NUL[128]> <CRC-16> | -» | |
| «- | <АСК> | |
| Передача файла завершена | ||
Имя файла (возможно с указанием пути) передается как строка кодов ASCII, завершаемая знаком NUL. Этот формат имени файла используется в функциях, ориентированных на операционные системы типа MS-DOS, и в функции fopen библиотеки языка Си. В имя файла не включаются пробелы. Обычно передается только само имя без префикса справочника. Имя диска источника (например, А:, В: и т.д.) не передается. Если передатчик не поддерживает передачу знаков в обоих регистрах, имя передается в строчном регистре. Если в имя файла включен каталог, его название должно ограничиваться знаками "/".
Обозначения длины файла и каждого последующего поля произвольны. Длина файла представляется в блоке как десятичная строка, обозначающая количество байт в файле. В нее не должны входить знаки EOF ("Z) или другие знаки (garbage characters), используемые для заполнения последнего блока. Если передаваемый файл увеличивается во время передачи, то параметр "Длина файла" должен иметь значение, соответствующее максимально ожидаемому размеру или не передаваться вовсе.
Дата модификации файла является необязательным параметром, имя и длина файла могут передаваться без передачи даты модификации. Дата модификации представляется в виде восьмеричного числа, указывающего время
Таблица 9.5. Групповая передача файлов блоками по 1 Кбайт с помощью протокола YModem
| ПЕРЕДАТЧИК | Направление передачи | ПРИЕМНИК |
| 4 | ^ | <sb —k doom.«><CR> |
| "Передача в групповом режиме! | -* | |
| <- | <с> (corrimand:rb) | |
| <SOH> <00 FF doom.exe NUL[123]> <CRC-16> | ||
| «- | <с> | |
| <SOH> 01 FE <данные[12в]><СНС-16> | -* | |
| «- | <АСК> | |
| <SOH> 02 FC <данные[ 1024]><:CRC-16> | -» | |
| *- | <АСК> | |
| <SOH> 03 FB <данные[100]> <CPMEOF [28]> <CRC-16> | ||
| ^ | <АСК> | |
| <EOT> | -» | |
| *- | <NAK> | |
| <ЕОТ> | -* | |
| <- | <АСК> | |
| «- | <С> | |
| <SOH> <00 FF NUL[128]> <CRC-16> | ||
| <- | <АСК> | |
| Передача файла завершена | ||
последнего изменения файла, и измеряется в секундах по Гринвичу, начиная с 1 января 1970 г. Это время называется Универсальным Координационным Временем (Universal Coordinated Time). Дата 0 обозначает, что дата модификации неизвестна и должна быть оставлена дата приема файла. Этот формат используется для исключения неопределенности при передачах файлов между различными временными зонами. ,
Если передается параметр "Режим файла", то один пробел должен отделять этот параметр от даты модификации. Режим файла передается как восьмеричная строка. Во всех операционных системах, кроме UNIX, данный параметр устанавливается в "О".
Протокол YModem допускает возможность введения других полей заголовка без нарушения совместимости со своими прежними версиями. Оставшаяся часть блока устанавливается в "О". Это важно для сохранения совместимости "снизу вверх".
Если блок имени файла принят с ошибкой по проверочной последовательности, необходим запрос на повторную передачу. Прием блока с именем файла, успешно открытого для записи, подтверждается знаком АСК. Если файл не может быть открыт для записи, то приемник прерывает передачу с помощью знака CAN.
Далее приемник инициирует передачу содержимого файлов в соответствии с протоколом XModem-CRC. После того как содержимое файла передано, приемник запрашивает имя следующего файла.
Передача нулевого имени файла может означать, во-первых, что групповая передача завершена, и, во вторых, что запрошенные у передатчика файлы не могут быть открыты для чтения.
По умолчанию приемник запрашивает CRC-16.
Протокол YModem поддерживается большинством связных программ общего пользования, например YAM (в операционных системах СР/М, СР/М-86, СРРМ) или rz/sz (в операционных системах UNIX, Xenix, VMS). Из коммерческих приложений его содержат программы MTEZ, Telix и ряд других.
В настоящее время разработаны методы, обеспечивающие передачу данных с очень высокими скоростями и малой вероятностью ошибок. Эти методы реализованы в высокоскоростных модемах и некоторых коммуникационных программах. Применение этих методов позволяет достичь скорости передачи, близкой к теоретически возможной.
Вариант g протокола YModem обеспечивает высокую эффективность передачи данных. Он используется приемником, который инициирует групповую передачу путем посылки знака "g" вместо "с". Передатчик, распознавший этот знак, прекращает ожидание обычных подтверждений по каждому переданному блоку и передает последовательные блоки на полной скорости с использованием метода управления потоком, такого как XON/XOFF.
Прежде чем передавать файл, передатчик ожидает поступления последовательности знаков "g", а в конце передачи каждого файла — подтверждающего знака АСК. Такой способ синхронизации позволяет приемнику открывать и закрывать файлы в нужное время.
При обнаружении ошибки в случае использования протокола YModem-g приемник прерывает передачу, посылая последовательность, состоящую из последовательности знаков CAN. Пример сеанса передачи с использованием протокола YModem-g приведен на табл. 9.6. '
Расширение YModem-g протокола YModem позволяет значительно повысить скорость передачи данных в каналах, защищенных от ошибок. То есть при использовании модемов со встроенными протоколами защиты от ошибок. Это достигается за счет отказа от переспроса принятых с ошибками блоков — при обнаружении ошибки передача файла прерывается. Для повышения быстродействия в последующих модификациях протокола XModem (например, в протоколе ZModem) был применен так называемый "оконный" алгоритм (процедура GBN), при котором последующие блоки передаются подряд, без ожидания подтверждения правильного приема некоторого числа блоков.
Таблица 9.6. Групповая передача файлов с помощью протокола YModem-g
| ПЕРЕДАТЧИК | Направление передачи | ПРИЕМНИК |
| *- | <sb doom.'><CR> | |
| "Передача в групповом режиме" | ||
| <д> (command:rb — д) | ||
| <SOH> <00 FF foo.C NUL[123]> <CRC-16> | =± | |
| <= | <д> | |
| <SOH>01 РЕ<данные[128]хСНС-16> | ||
| <STX> 02 FD <данные[1024]><СРС-16> | -» | |
| <STX>.03 FC <данные[128]><СПС-16> | -^ | |
| <SOH> 04 FB <данные[100]> <CPMEOF[28]> <CRC-16> | ... . -».,.. | |
| <EOT> | ||
| ^ | <АСК> | |
| ———<=——— | <д> | |
| <SOH> <00 FF NUL[128]> <CRC-16> | -» | |
| Передача файла завершена | ||
Протокол ZModem введен в большинство связных программ и в настоящее время получил самое широкое распространение. Представляя собой развитие протоколов XModem и YModem, он устраняет их недостатки и при соблюдении совместимости имеет ряд преимуществ:
- высокое быстродействие благодаря использованию процедуры SBN;
- динамическая адаптация к качеству канала связи посредством изменения в широких пределах размера передаваемых блоков;
- возможность возобновления прерванной передачи файла с того места, на котором произошел сбой;
- повышенная достоверность передачи благодаря использованию 32-разрядной проверочной комбинации (CRC);
- возможность отключения функции контроля ошибок передаваемых блоков при использовании модемов с аппаратной коррекцией ошибок. Протокол ZModem явился результатом технического компромисса между следующими противоречивыми требованиями:
- простота использования;
- обеспечение высокой пропускной способности;
- сохранение целостности информации;
- достижение высокой надежности передачи;
- простота реализации.
Протокол позволяет или программно инициировать передачу файлов или передавать команды и (или) модификаторы другим программам. Названия файлов достаточно ввести только один раз. Возможен выбор файлов с помощью меню. При групповых передачах возможно задание файлов одной маской (например, "*.doc"). Организация передачи осуществляется путем введения минимального количества команд с клавиатуры.
При передаче файлов передается кадр ZRQINIT, который инициирует автоматический прием файлов.
Протокол ZModem может эмулировать режим протокола YModem, если процесс на удаленном компьютере не поддерживает протокол ZModem.
При разработке протокола ZModem особое внимание было уделено трем аспектам его применения:
- сетевым применениям в условиях больших задержек и малой вероятности ошибок;
- применениям в системах с временным уплотнением и буферированием, характеризующимися наличием значительных задержек и ухудшением пропускной способности при росте трафика обратного канала;
- обеспечение прямой связи между модемами при высокой вероятности ошибок в канале.
С момента начала сеанса связи протокол ZModem защищает передаваемые данные циклической проверочной комбинацией из 16 или 32 бит (CRC-16 или CRC-32). При применении протокола канального уровня ADCCP (версия HDLC - ANSI X3.66, FIPS PUB 71, FED-STD-1003) возможно использование CRC-32 в качестве проверочной последовательности блока. Использование 32-битной проверочной комбинации позволяет уменьшить вероятность необнаруженных ошибок не менее чем на пять порядков.
В протоколе реализован механизм защиты данных от сообщений, имитирующих разрешенные команды или передачу файлов (сообщения типа "Троянский конь").
Протокол ZModem может быть использован в различных типах вычислительных систем: в персональных компьютерах, которые не могут одновременно работать с накопителем на жестком диске и последовательным портом ввода-вывода; в компьютерах без возможности одновременной передачи и приема через последовательный порт; в компьютерах и сетях передачи данных, в которых реализовано управление потоком методом XON/XOFF.
Протокол ZModem адаптирован к задержкам в сетях передачи данных и v системах с временным уплотнением за счет непрерывной передачи данных. Передача данных продолжается до тех пор, пока приемник не прервет передатчик запросом на повторную передачу искаженных данных. Фактически протокол ZModem использует отдельный файл как "окно". Это упрощает управление буфером и позволяет исключить режим переполнения окна, которому подвержены такие протоколы, как MEGAlink, SuperKermit и др.
Протокол ZModem предназначен для организации передачи файлов любого формата и может быть использован либо отдельно, либо в сочетании с протоколами защиты от ошибок канального уровня, такими как MNP, V.42, HDLC и др. В случае сочетания с протоколом HDLC протокол ZModem дополнительно обеспечивает обнаружение и исправление ошибок в интерфейсах между DTE и DCE.
Протокол ZModem для общего применения был разработан в 1986 году компанией Telenet. Его описание и исходный код программы rz/sz для операционной системы UNIX являются общедоступными. На применение этого протокола и исходной программы rz/sz не распространяются лицензирование, торговые марки и ограничения на копирование.
Для реализации протокола ZModem требуется коммуникационная среда с октетной (8-битной) передачей. Протокол может удалять знаки управления для обеспечения передачи в сетях с коммутацией пакетов. Для поддержки полной потоковой (непрерывной) передачи в канале (streaming) требуется реализация метода управления потоком.
Протокол ZModem не накладывает никаких ограничений на информационное содержание файлов. Однако количество битов в файле должно быть кратно 8. Принцип действия протокола позволяет выполнять кодирование блоков для непрозрачных сред передачи данных. Возможно применение методов уп- , равления потоком XON/XOFF или управление по отдельному каналу, как это выполнено в сетях стандарта Х.25.
Так как протокол ZModem используется для передачи файлов между различными типами вычислительных систем, текстовые файлы должны удовлетворять требованию "читаемости" в широком диапазоне систем. Строки текста состоят из знаков кода ASCII, пробела (Space), табуляции (Tab) и возврата на одну позицию (Backspace).
Строка текста в кодах ASCII должна завершаться последовательностью CR/LF (13h, 10h) или знаком NUL (Oh). Строки, завершающиеся только знаком CR (13h) не являются текстом в кодах ASCII. Ввод знака CR без знака LF не прерывает вывод на данной строке и неприемлем в качестве логического разделителя строк. Содержимое таких строк должно выводится на следующем проходе для отображения на дисплее всего текста.
Блоки данных протокола ZModem носят название кадров (также как в протоколах канального уровня) и существенно отличаются от блоков протоколов XModem и YModem.
Протокол ZModem обеспечивает прозрачность передачи данных путем расширения набора 8-разрядных знаков (256 возможных знаков). Это осуществляется с помощью ESC-последовательностей перехода на основе знака ZDLE. Это позволяет передавать кадры данных переменной длины с помощью заголовков, содержащих одинаковое количество байтов. Это также позволяет обнаруживать начало кадров.
Применение последовательностей перехода приводит к увеличению служебного заголовка. В худшем случае, в файле, содержащем только знаки перехода, служебный заголовок составляет 50% размера кадра.
Знак ZDLE представляет последовательность определенного вида. Если этот знак появляется в двоичных данных, ему предшествует еще один знак ZDLE, a за ним передается знак ZDLEE. Знаку ZDLE соответствует шестнадцатеричное число 8h (знак CAN кода ASCII). Это частное значение знака выбрано для того, чтобы путем передачи 5 последовательных знаков CAN обеспечивать процедуру прекращения сеанса протокола ZModem, совместимого с протоколом YModem. Так как знак CAN не используется в обычных терминальных операциях, интерактивные службы и связные программы могут контролировать наличие знака ZDLE в потоке данных для обнаружения заголовка кадра ZRQINIT — приглашения для автоматического приема команд или файлов.
Прием 5 последовательных знаков CAN вызывает прекращение сеанса протокола ZModem. Для этого передается 8 знаков CAN. Принимающая программа декодирует любую последовательность, состоящую из знака ZDLE и байта, следующего за ним, в котором бит 6 установлен в "I", а бит 5 сброшен в "О". Декодирование таких последовательностей в управляющий знак осуществляется путем инвертирования бита 6. Это позволяет передатчику изменять любой управляющий знак, который не может быть передан через используемую систему передачи данных.
Все кадры протокола ZModem начинаются с заголовка кадра, который может передаваться в двоичной или восьмеричной форме. В протоколе используется процедура определения формата заголовка. В заголовке содержится одна и та же информация, не зависимо от формата:
- тип кадра;
- 4 байта флагов индикации данных и (или) числовые величины, зависящие от типа кадра.
Формат заголовка имеет следующий вид:
| TYPE | F3 | F2 | F1 | FO |
| TYPE | РО | Р1 | Р2 | РЗ |
где TYPE — тип кадра; FO — младший байт флага; РО — младший байт позиции файла; РЗ — старший байт позиции файла.
В двоичном заголовке кодирование ZDLE обеспечивает управление потоком по методу XON/XOFF. Двоичный заголовок начинается последовательностью ZPAD, ZDLE, ZBIN. Затем следует байт типа кадра, 4 байта позиции флага, 2 байта проверочной комбинации, кодированные с помощью ZDLE. В зависимости от типа кадра за заголовком могут следовать блоки пакетов данных, охваченные проверкой CRC-16:
| ZDLE | 1 А | TYPE | F3/PO | F2/P1 | F1/P3 | FO/P3 | CRC-16 |
Такой двоичный заголовок аналогичен заголовку с 16-разрядной проверочной комбинацией, за исключением того, что ZDLE (А) заменен на ZDLE (С) и передаются 4 знака (байта) проверочной комбинации:
| ZDLE | С | TYPE ¦ | F3/PO | F2/P1 | F1/P3 | FO/P3 | CRC-32 |
Приемник передает свои ответы в 16-ричных заголовках. В передатчике используется 16-ричный заголовок, когда за ним не следуют пакеты двоичных данных, 16-ричное представление защищает обратный канал от случайных управляющих знаков. Программой приема игнорируется проверка паритета знаков. Применение 16-ричных заголовков приемной программой позволяет использовать управляющие знаки для прерывания передатчика при обнаружении ошибок. Пакеты данных, следующие за таким заголовком, защищаются с помощью 16-разрядной проверочной комбинации.
16-ричный заголовок начинается последовательностью ZPAD, ZPAD, ZDLE, ZHEX. Дополнительный знак ZPAD позволяет передающей программе обнаруживать асинхронный заголовок и затем вызвать соответствующую подпрограмму для приема заголовка.
Тип кадра, байты флагов и CRC-16 передаются в 16-ричном формате с использованием набора знаков 0—9, а—Г. Не допускается передача знаков в верхнем регистре, так как они неправильно воспринимаются протоколами XModem и YModem. Знаки возврата каретки (CR) и перевода строки (LF) передаются с 16-ричными заголовками. Программой приема ожидается, по крайней мере, один из этих знаков или оба, если первый знак CR. При передаче знака CR/LF отпадает необходимость редактирования принятого файла при выводе на печать и исключаются проблемы, связанные с этими знаками в некоторых операционных системах.
Знак XON добавляется ко всем 16-рйчным комбинациям, за исключением ZACK и ZFIN. Это позволяет защититься от знака XOFF, в который могут случайно перейти другие знаки под воздействием ошибок в канале связи. Для защиты управления потоком при использовании метода непрерывной (потоковой) передачи знак XON не передается после заголовков ZACK. Для разрешения прекращения сеанса связи после заголовков ZFIN знак XON также не передается.
В зависимости от типа кадра за заголовком могут передаваться пакеты данных:
При передаче пакетов двоичных данных заполнение пробелов (padding) не используется. Байты данных кодируются методом ZDLE и затем передаются. Далее передается знак ZDLE и окончание кадра, за которым следуют 2 или 4 кодированных ZDLE проверочных байта (CRC-16 или CRC-32). Циклическая кодовая проверка охватывает байты данных и окончание кадра.
В настоящее время пакеты данных в коде ASCII не определены. Эти пакеты могут использоваться для команд серверов или для основных передач в системах с 7-разрядным форматом.
Посылается передающей программой для инициализации передачи заголовка ZRINIT программой приема. Позволяет устранить стартовые задержки, свойственные протоколам XModem и Kermit. Передающая программа может повторить приглашение приема (включая ZRQINIT), если ответ не получен после первой передачи данного кадра.
Передается программой приема. Байты ZFO и ZF1 содержат распределение битов или флаги, указывающие на возможности приемника (дешифрирование, передача и прием в дуплексном режиме, прием данных во время чтения-записи на диск, передач сигнала разрыва, декомпрессия, использование проверочной комбинации CRC-32, ожидание перехода управляющих знаков или 8-го бита).
Байты ZPO и ZP1 содержат размер буфера приемника в байтах или "О", если разрешен прием без остановки ввода-вывода.
Передатчик посылает флаги с следующим за ними пакетом двоичных данных, завершаемым ZCRCW. Пакет данных содержит последовательность ATTN, состоящую максимум из 32 байт, включая завершающий "О".
Подтверждение кадра ZSINIT, заголовка ZCHALLENGE, пакетов данных ZCRCQ или ZCRCW. Байты от ZPO до ZP3 содержат величину смещения в файле. Ответ на заголовок ZCHALLENGE содержит также 32 байта, как и принятый заголовок.
Обозначает начало передачи файла. Байты ZFO, ZF1 и ZF2 могут принимать различные значения, определяющие варианты преобразования, управления, передачи и др.
Передается приемником в ответ на ZFILE и заставляет передатчик перейти к передаче следующего файла.
Указывает на искажение последнего заголовка.
Передается приемником для прекращения групповой передачи файлов по запросу пользователя. Передатчик отвечает при этом кадром ZFIN.
Посылается передающей программой для завершения сеанса протокола ZModem. Приемник отвечает на этот кадр собственным кадром ZFIN.
Передается приемником для форсирования возобновления передачи файла с позиции смещения в файле, указанной в байтах ZPO—ZP3.
Байты ZPO—ZP3 содержат значение смещения в файле. За ними следует 1 или более пакетов данных.
Сообщение передатчика о завершении передачи файла. В байтах ZPO—ZP3 содержится конечное значение смещения в файле.
Свидетельствует об ошибке при чтении или записи файлов, протокольный эквивалент кадру ZABORT.
Запрос приемником и ответ передатчиком проверочной комбинации (полинома) файла. Проверочная комбинация содержится в байтах ZPO—ZP3.
Запрос эхо-возврата передатчиком случайного числа в байтах ZPO—ZP3 кадра ZACK. Посылается программой приема передающей программе для проверки соединения и его достоверности (осуществлено ли соединение под воздействием канальных ошибок или сообщения типа "Троянский конь").
Сообщает, что запрос в данный момент завершен.
Тип псевдокадра, возвращаемый программой в ответ на последовательность "Прекращения сеанса" (session abort sequence).
Запрос передающей программой кадра ZACK с байтами ZPO—ZP3, содержащими объем свободного дискового пространства в текущей файловой системе. Значение 0 соответствует неопределенному объему свободной памяти.
Кадр ZCOMMAND передается в двоичном кадре. В байте ZFO содержится "О" или ZCACK1.
За пакетом данных ZCRCW следует строка текста в коде ASCII, завершающаяся знаком NUL. Если команда предназначена для выполнения ее операционной системой, в которой работает протокол (например, при выходе в операционную систему по команде "shell escape" или "DOS shell"), первым знаком должен быть знак "!". В других случаях подразумевается, что команда должна выполняться прикладной программой. Если приемник обнаруживает недопустимую или неправильно сформированную команду, то он сразу же отвечает заголовком ZCOMPL с кодом ошибки, содержащимся в ZPO—ZP3. Если в ZFO содержится ZCACK1, приемник отвечает заголовком ZCOMPL с состоянием "О". В других случаях приемник отвечает заголовком ZCOMPL после завершения выполнения команды. Код "Состояния выхода" (exit) выполненнойкоманды хранится в ZPO—ZP3. Если код "Состояние выхода" равен "О", то это соответствует нормальному завершению выполнению команды.
Если команда инициирует передачу файла, передатчику команды от другого компьютера, пытающегося передавать данные, поступит кадр ZRQINIT. Передатчик выполняет проверку значения байта принятого заголовка ZRQINIT на предмет определения, не является ли этот кадр эхом его собственного кадра ZRQINIT. Передающей программе запрещено управление программой приема с целью инициализации ею передачи определенной команды.
Если программа приема не может выполнить принятую команду, она отображает ее в стандартном сообщении об ошибке и затем возвращает заголовок ZCOMPL.
Программа приема посылает последовательность ATTN в случае, если она обнаруживает ошибку и требует прерывания передающей программы. Строка ATTN по умолчанию пустая. По умолчанию перед каждым сеансом передачи программой приема производится сброс значения ATTN в значение "пусто". Передатчик задает последовательность ATTN в своем необязательном кадре ZSINIT. Строка последовательности ATTN завершается знаком NUL.
Протокол ZModem передает в нулевом кадре ZFILE ту же информацию, что передается в блоке 0 протокола YModem (YModem Batch).
Название пути (обычно входит в имя файла) передается как строка в коде ASCII, завершаемая знаком NUL. Это формат названий файлов операционной системы MS-DOS и функций библиотеки Си fopen. В название пути не допустимо включать пробелы. Пока передатчиком не будет выбран вариант YAM для передачи полного абсолютного или относительного пути, передается только название файла без префикса каталога. Имя диска обычно не передается.
Имена файлов должны состоять из символов нижнего регистра (набираться строчными буквами), так как не все программы поддерживают прием имен, набранных в верхнем регистре. Некоторые операционные системы, например UNIX, поддерживают имена файлов в верхнем и нижнем регистрах. Для работы в таких операционных системах коммуникационная программа должна принимать имена файлов в обоих регистрах.
При передаче файлов между различными операционными системами имена файлов должны быть понятны обеим системам. Если это не так, то требуется преобразование имен файлов. В случае неудачного преобразования программой приема могут использоваться другие имена файлов.
При включении имен каталогов они должны отделяться знаком "/", как принято в UNIX, а не "\", как это делается в DOS и Windows.
Передача длины файла и каждого последующего рассматриваемого поля является необязательной. Длина файла хранится в виде десятичного числа, равного количеству байт в файле.
Приемник протокола ZModem использует этот параметр только для оценки времени передачи и (или) возможности размещения принимаемого файла в свободном дисковом пространстве компьютера. Фактическая длина принятого файла определяется при передаче данных. Размер файла может измениться после начала передачи, но не смотря на это все данные должны быть переданы.
Дата модификации файла отделяется одним пробелом от длины файла. Этот параметр также является необязательным. Дата модификации файла передается в виде восьмеричного числа и определяет время последнего изменения файла относительно 1 января 1970 г. Такое представление даты модификации было выбрано для исключения неоднозначности при передаче файлов между разными временными зонами. Значение даты, равное 0, говорит о том, что дата изменения файла неизвестна, и в качестве ее должна быть взята дата приема файла.
Режим файла отделяется пробелом от даты модификации. Режим файла передается в восьмеричном виде. Если файл не передан системой UNIX, режим файла равен 0.
Номер программы отделяется от режима файла пробелом. Номер передающей программы хранится в виде восьмеричного числа. Программы, не имеющие номера, пропускают это поле или устанавливают его в 0. Использование приемником этого поля необязательно.
Информация о файле завершается знаком NUL. Если передается только имя файла, то помещается 2 знака NUL. Длина пакета информации о файле, включая завершающий нуль, не должна превышать 1024 байт. Типовая же длина меньше 64 байт.
Так же как в протоколе XModem, в протоколе ZModem синхронизация задается приемником. Тайм-аут передатчика вообще не задается, за исключением функции прерывания работы программы при отсутствии приема заголовка кадров в течение длительного периода времени, например, одной минуты.
Для начала сеанса передачи файла с использованием протокола ZModem осуществляется вызов передающей программы с указанием имени требуемого файла (файлов) и варианта работы. Перед передачей послается соответствующая строка ("rz" с последующим возвратом каретки) приемной программе для запуска ее. Указанная строка активизирует приемную программу протокола. Затем передающая программа выводит сообщение для пользователя (например, список файлов для передачи).
Далее передатчик передает заголовок ZRQINIT, который заставляет предварительно запущенную программу приема без задержки послать заголовок ZRINIT, команду приема данных или внешнюю команду. В интерактивном режиме или режиме "переговоров" приемная прикладная программа контролирует поток данных на наличие ZDLE. Следующие за ними знаки могут быть командами управления приемом файла или данных.
Передающая программа ожидает команды начала передачи файлов от программы приема. Прием символов "с", "g" или знака NAK указывает на передачу файла в соответствии с протоколами XModem или Ymodem. В этом случае передача файла ведется с использованием протокола YModem.
В случае искажения данных передающая программа повторяет приглашение приема несколько раз, пока сеанс не начнется.
При старте программы протокола ZModem передается кадр ZRINIT для начала передачи файла или кадр ZCHALLENGE для верификации передающей программы. Программа приема повторяет передачу кадра с интервалом 10 с (по умолчанию) и в течение 40 с.
При обнаружении кадра ZRQINIT программа приема повторно передает кадр ZRINIT. Передающая программа, приняв кадр ZCHALLENGE, помещает данные в байты ZPO—ZP3 ответного заголовка ZACK.
Получение программой приема кадра ZRINIT, являющегося эхо-возвратом означает, что программа передачи не функционирует. При приеме программой передачи кадра ZRINIT передатчик послает необязательный кадр ZSINIT для определения служебной последовательности "Внимание" (ATTN) программы приема или для задания полного варианта замены управляющих знаков. Если в кадре ZSINIT помещены знаки ESCCTL или ESC8, прежде чем считывать последующий пакет данных приемник активирует требуемые режимы использования управляющих знаков ESC.
В ответ приемник посылает заголовок ZACK, который может содержать номер программы приема, присвоенный изготовителем, или 0.
Передатчик посылает кадр ZFILE с параметрами протокола ZModem, за которыми следует пакет данных ZCRCW, содержащий имя, длину и дату модификации файла, а также другую информацию, аналогичную используемой в протоколе YModem.
Приемник анализирует эту служебную информацию и определяет требуемый режим передачи, текущее состояние файловых систем и требования к местной защите информации. Программа приема должна убедиться в совместимости этих требований режимов и имен файлов с операционной системой в месте приема и с местными требованиями к защите информации. Приемник отвечает заголовком ZSKIP, заставляющим передатчик перейти к обработке и передаче следующего файла в группе (если он есть).
Если в приемном компьютере имеется файл с тем же именем и той же длины, приемная программа может ответить кадром ZCRC, который требует от передатчика вычислить 32-разрядную проверочную комбинацию для данного файла и передать приемнику ее дополнение в кадре ZACK. Приемник использует эту информацию для принятия решения о приеме или пропуске данного файла.
Передача кадра ZRPOS вызывает начало передачи файла, причем в этом заголовке указывается смещение по длине файла, с которым он должен быть передан. Под смещением понимается число принятых знаков файла. Обычно при первоначальной передаче это смещение равно 0. Приемник может инициировать передачу файла не с начала. Это позволяет возобновить прерванную передачу данного файла с любого места, т.е. без повторной передачи уже принятых данных. Передатчик посылает двоичный кадр ZDATA и затем один или несколько пакетов данных. Приемник производит сравнение значения позиции внутри файла, содержащемся в кадре ZDATA, с числом успешно принятых знаков данного файла. Если эти числа не совпадают, формируется ответ, свидетельствующий об ошибке, и передатчик повторно передает значение позиции внутри файла.
Пакет данных завершается последовательностью ZCRCG. Проверки по коду не вызывают формирование ответа до тех пор, пока не будет обнаружена ошибка. Последовательно может быть передано большое число пакетов. При отсутствии ошибок на каждый переданный пакет ZCRCQ ожидается ответ ZACK (подтверждение) с указанием смещения в файле приемника. В противном случае передается ответ ZRPOS со смещением, соответствующим последнему принятому без ошибок пакету. Другие пакеты данных передаются непрерывно. Пакеты ZCRCQ не используются, если приемник не указал на возможность полного дуплекса битом CANFDX.
В случае временного отсутствия данных у передатчика для предотвращения тайм-аута приемника передатчик передает кадры нулевой длины.
В конце файла при отсутствии ошибки передатчик посылает сигнал об окончании файла. Если файл заканчивается внутри кадра, то кадр завершается пакетом ZCRCE, который не требует подтверждения за исключением случаев обнаружения ошибки.
Передатчик посылает кадр ZEOF, содержащий конечное значение смещения, равное числу знаков в файле. В приемнике производится сравнение этого числа с числом принятых знаков. Если принят весь файл, приемник закрывает файл. При удачном закрытии файла приемник отвечает кадром ZRINIT. Еслипринят не весь файл (продолжается поступление новых кадров ZDATA), приемник игнорирует кадр ZEOF. При невозможности правильного закрытия файла приемником посылается заголовок ZFERR.
Передатчик завершает сеанс кадром ZFIN. Приемник подтверждает его прием передачей своего кадра ZFIN. После приема кадра подтверждения передатчик посылает 2 знака 00 (Over and Out) и осуществляет выход в операционную систему или прикладную программу, вызвавшую работу протокола. Приемник некоторое время ожидает приема знаков "О", а затем прекращает работу независимо от того, приняты эти знаки или нет.
В случае приема данных в потоковом режиме до передачи последовательности знаков CAN для прерывания передачи данных выполняется последовательность ATTN ("Внимание"). Последовательность прерывания содержит 8 знаков CAN и 10 знаков забоя (Backspace). Протоколу ZModem требуется только 5 знаков CAN, а остальные 3 передаются для большей надежности. Замыкающие знаки забоя предназначены для устранения ошибочной интерпретации знаков CAN.
Ниже приводятся два примера сеансов передачи при помощи протокола ZModem. Табл. 9.7 соответствует передаче одного файла при отсутствии ошибок, при этом кадры типа ZCHALLENGE и совмещение операций приема-передачи не используются. Табл. 9.8 иллюстрирует прием и выполнение команды.
К сожалению, ни один из известных методов потоковой передачи данных (streaming) не является универсальным для применения в большинстве современных вычислительных систем и сетей. В протоколе ZModem реализовано несколько методов потоковой передачи, выбираемых в зависимости от ограничений, налагаемых системами передачи данных.
Если приемник может совмещать ввод-вывод по последовательному порту с записью-чтением диска, а передатчик принимать данные из обратного канала, может быть реализована полная потоковая передача. В этом режиме работа начинается с передачи кадра ZCRCG. При обнаружении приемником ошибки передатчик выполняет последовательность ATTN и посылает кадр ZRPOS с указанием правильной позиции в файле.
Таблица 9.7. Простая передача файла с помощью протокола ZModem
| ПЕРЕДАТЧИК | Направление передачи | ПРИЕМНИК |
| "rz\ri | ||
| <- | ZRQINIT(O) | |
| ZRINIT | ||
| < | ZFILE | |
| 2RPOS | ^ | |
| <- | ZDATA | |
| <Данные> | -» | |
| ZEOF | -* | |
| - «- | ZRINIT | |
| ZFIN | ||
| ZFIN | ||
| 00 | ||
| Передача файла завершена | ||
Таблица 9.8. Выбор и прием команды с помощью протокола ZModemзнаков ZPAD или CAN. Эти знаки обрабатываются, и выполняются предписываемые ими действия.
| ПЕРЕДАТЧИК | Направление передачи | ПРИЕМНИК |
| "rz\r" | ||
| ZRQIMIT(O) | >. | |
| <- | ZCHALLENQE (случайное число) | |
| ZACK (то же самое число^ ' | -> | |
| «- | ZRINIT | |
| ZCOMMAND, ZDATA | -> | |
| ZCOMPL | ||
| ZFIN | -» | |
| <- | ZFIN | |
| 00 | ||
| Выполнение команды завершено | ||
Другие знаки, появление которых обусловлено наличием канальных ошибок, увеличивают содержание счетчика, предназначенного для контроля числа принятых ошибочных кадров. После безошибочного приема очередного кадра счетчик сбрасывается. При переполнении счетчика передатчик посылает следующий пакет данных как ZCRCW и ожидает ответа.
Знак ZPAD указывает на тип ошибки на приемной стороне. Знак CAN свидетельствует о том, что пользователь пытается прекратить передачу путем ввода с клавиатуры этого знака. Если принят один из указанных знаков, посылается пустой пакет данных ZCRCE. В нормальном режиме для того, чтобы заставить передатчик возобновить передачу по другому адресу, приемник передает кадр ZRPOS. При внезапном появлении знаков ZPAD или CAN вследствие действия помех приемник генерирует тайм-аут и посылает кадр ZRPOS. Затем считывается и обрабатывается ответный заголовок приемника. Кадр ZRPOS устанавливает правильное значение смещения в передаваемом файле. Для того чтобы минимизировать передачу ненужных приемнику данных передатчик должен очистить свой буфер передачи и (или) сбросить еще не переданные данные. Следующим передаваемым кадром данных является кадр ZCRW. За этим'кадром следует интервал ожидания на время, необходимое для полного освобождения буферной памяти.
Если в кадре ZACK, переданном приемником, помещен адрес, отличный от адреса передатчика, то он игнорируется. Прием кадров ZFIN, ZABORT или TIMEOUT вызывает завершение сеанса, а прием заголовка ZSKIP — завершение передачи данного файла.
После завершения передачи файла производится проверка обратного канала на предмет наличия другого кадра от приемника. Если один из кадров обнаружен, вызывается соответствующая функция для его обработки. В противном случае, передача возобновляется со сбросом значения смещения в файле путем использования кадра ZDATA с последующей передачей пакетов данных.
При работе в сети передачи данных пользовательская информация может буферироваться в отдельных узлах этой сети (до 7 Кбайт и более). В результате этого может сложиться ситуация, когда передатчик уже передал значительный объем данных, а приемник еще не начал их принимать. Такая ситуация не опасна для протокола ZModem, использующего метод "оконной" передачи. Однако это замедляет процесс исправление ошибок.
Для управления размером "окна" передающей программой используются пакеты данных ZCRCQ. Возвращаемые приемником кадры ZACK информируют передатчик о состоянии приемника. Когда размер "окна", равный текущему смещению в файле передатчика, превышает заданное значение, передатчик прекращает передачу и ожидает от приемника пакета ZACK со смещением в файле приемника. Это приводит к уменьшению размера окна. Такие версии протокола ZModem, как sz, Professional Jam, ZCOMM и DSZ совместимы с предыдущими версиями протокола по методу управления "окном".
Описанный выше метод управления потоком не может применяться, если поступающие по обратному каналу данные не могут обрабатываться одновременно с передачей очередного кадра по прямому каналу. При обнаружении ошибки приемником передающей программе выдаются команды прерывания передачи. Приемник может прервать передатчик с помощью управляющего знака, сигнала прерывания или их комбинации, как это определено в последовательности ATTN. После выполнения последовательности ATTN для инициирования повторной передачи потерянных данных приемник передает 16-ричный кадр ZRPOS.
Отвечая на это прерывание, передающая программа, она считывает 16-ричный кадр ZRPOS приемника и выполняет операции, описанные выше.
Если ни один из описанных выше методов управления потоком неприемлем, можно использовать метод скользящего окна. Если передатчик способен накапливать ответы приемника, то для получения подтверждений от приемника без прерывания процесса передачи данных он может использовать пакеты данных ZCRCQ. После того, как передано достаточное число пакетов данных ZCRCQ, передатчик может считать один из заголовков, которые поступили в его приемный буфер.
Недостатком этого метода являются большие затраты времени на повторную передачу искаженного кадра. Для уменьшения временных затрат существует возможность запрограммировать последовательность ATTN на очистку буфера прерываний передатчика до передачи заголовка ZRPOS.
В условиях канала без помех передатчиком протокола ZModem может быть передан одиночный файл в одном кадре без контроля обратного потока. Если этот канал полностью прозрачный, необходимо удалять только знаки ZDLE. Результирующий заголовок протокола для файлов средней длины составляет менее 1 % от длины файла.
Если приемник может совмещать ввод-вывод по последовательному порту с записью-чтением диска, он использует кадр ZRINIT для задания длины буфера, который не должен переполняться передатчиком. Передающая программа посылает пакет данных ZCRCW и, прежде чем передавать следующий сегмента файла, ожидает кадр ZACK.
Если передающая программа поддерживает обработку обратного потока данных или прерываний, то исправление ошибок будет выполняться быстрее, чем при использовании протоколов, передающих блоки данных большой длины (как, например, YModem).
При достаточно большом объеме приемного буфера обеспечивается пропускная способность, очень близкая к той, которая достигается при полной потоковой передаче. Например, сегментированная потоковая передача блоками по 16 Кбайт при круговом времени задержки канала (по шлейфу), равном 5 с, увеличивает время передачи файла только на 3%.
Протокол Kermit предназначен для передачи файлов между компьютерами разных типов, включая большие и миникомпьютеры. Он рассчитан на работу в условиях сильных помех и при больших задержках в канале связи. В отличие от протоколов XModem и Ymodem, в протоколе Kermit используются блоки переменной длины, максимальное значение которых 94 байта. Также как протоколы YModem и Zmodem, протокол Kermit обеспечивает групповую передачу файлов.
Наряду со стандартным протоколом Kermit в ряде программ реализован более эффективный протокол Super Kermit, предусматривающий для уменьшения задержек передачи использовать механизм переменного "окна". В этом "окне" может содержаться от 1 до 32 блоков. На приемном конце канала осуществляется обнаружение ошибок, но повторная передача не запрашивается до тех пор, пока не будут переданы все блоки "окна". Кроме того, в протоколе реализован простой метод сжатия данных, позволяющий дополнительно сократить время передачи. Если удаленный компьютер поддерживает протокол Kermit, то переключение на работу с ним происходит автоматически.
Передача файлов является одной из наиболее трудных задач для пользователя при работе со связной программой. Это объясняется не только многовариантностью выбора, но и тем, что одни и те же протоколы часто имеют разные наименования, иногда для различных протоколов используется одно и то же название. Поэтому, в первую очередь, необходимо убедится в том, что взаимодействующие компьютеры используют один и тот же протокол.
Не рассмотренный здесь протокол ASCII фактически не является протоколом передачи файлов. Он не поддерживает координацию между передающей и приемной системами, исправление ошибок и передачу двоичных файлов. Его можно использовать для передачи текстовых файлов компьютеру, уже подключенному к каналу связи, как альтернативу печати сообщения в режиме on-line. В режиме приема его полезно использовать в случае необходимости документировать на диске весь сеанс связи или его часть. Однако для передачи файлов этот протокол использовать не рекомендуется.
Протокол XModem с контрольной суммой имеется практически в любой связной программе. Метод обнаружения ошибок с помощью контрольной суммы, по сравнению с более совершенным способом проверки с использованием циклического кодирования (CRC), является более быстрым и не требует больших вычислительных ресурсов и объема служебной информации. Модернизированный протокол XModem-CRC устраняет ряд недостатков базового протокола.
Протокол XModem-lK (в ряде программ, например в Procomm, он называется YModem) аналогичен классическому протоколу XModem, отличаясь от него только объемом передаваемых блоков — 1 Кбайт вместо 128 байт. Благодаря большим размерам блока, уменьшается относительная доля передаваемой служебной информации, в том числе и обеспечивающей обнаружение ошибок. Однако, если обнаружена ошибка, требуется повторная передача большого объема данных. При хорошем качестве канала связи протокол XModem-1 К обеспечивает более высокую скорость передачи, чем XModem. Если же качество соединения плохое, то быстродействие протокола XModem оказывается выше.
Для передачи нескольких файлов необходимо использовать протокол YMo-dem, во многих коммуникационных программах называемый как YModem Batch.
При использовании модемов с аппаратной коррекцией ошибок следует применять протокол YModem-g (в ряде программ он называется YModem-g Batch). В этом потоковом протоколе передающая сторона не ожидает подтверждения правильного приема блока данных. В случае обнаружения ошибки принимающая сторона просто прерывает прием. Если установлено соединение с аппаратным исправлением ошибок (например, с помощью модема с протоколом MNP4 или V.42), то протокол YModem-g обеспечивает более высокую скорость передачи файлов, чем варианты протокола XModem или протокол YModem.
Протокол ZModem также представляет собой один из вариантов потокового протокола, не прерывающего передачу в случае обнаружения ошибки. При обнаружении ошибки приемная сторона посылает запрос на повторную передачу поврежденных данных. ZModem позволяет передавать данные через спутниковые каналы и сети с пакетной коммутацией. Им можно пользоваться на больших, мини- и персональных компьютерах с обычными модемами и модемами с аппаратным исправлением ошибок. Экономное использование протоколом пропускной способности обратного канала позволяет оптимальным образом работать модемам с динамическим распределением пропускной способности между двумя направлениями передачи.
Благодаря своим свойствам протокол ZModem можно считать наилучшим выбором независимо от того, установлено ли модемом соединение с исправлением ошибок или нет. Кроме того, стоит иметь в виду, что данный протокол явился основой для большого числа других протоколов, улучшающих те или иные его свойства и, как правило, ориентированных на работу в определенных условиях. К таким протоколам относятся SeaLink, MEGALink, WXModem и ряд других.
Протокол Kermit разработан для передачи информации между большими и миникомпьютерами, которые могут обрабатывать только 7-битовые знаки. При передаче двоичных (бинарных) файлов в протоколе используется метод под названием "8-bit quoting" для передачи восьмого бита отдельно. Однако не все версии протокола Kermit поддерживают этот метод, что существенно ограничивает его применение. Для увеличения реальной скорости обмена протокол Kermit использует предварительную компрессию данных. Недостатком этого протокола является его сложность: для его использования требуется детальное ознакомление с режимами и особенностями его работы. Кроме того, Kermit — относительно медленный протокол и использовать его рекомендуется только в случаях, когда другие варианты отсутствуют. Разновидность этого протокола,известная под названием Super Kermit и предназначенная для использования в сетях типа Telenet или Tymnet, характеризующиеся большими задержками передачи данных.
Таблица 9.9. Сравнительные характеристики распространенных протоколов передачи файлов
| Параметр | XModem | XModem-CRC | XMode-IK | YModem | YModem-g |
| CS-8 | + | ||||
| CS-16 | |||||
| CRC-16 | + | + | + | + | |
| CRC-32 | |||||
| 7 бит | |||||
| 8 бит | + | + | + | + | + |
| RTS/CTS | + | + | + | + | + |
| XON/XOFF | |||||
| Сжатие данных | |||||
| Длина файла | + | + | |||
| Дата модификации файла | |||||
| Минимальный размер блока, байт | 128 | 128 | 128 | 128 | |
| Максимальный размер блока, байт | 128 | 128 | 1К | 1К | |
| Масштабирование блоков | |||||
| ARQ типа SAW | + | + | + | + | |
| ARQ типа QBN | |||||
| ARQ типа SR | |||||
| Запрос файлов | |||||
| Групповая передача | + | + | |||
| Восстановление | |||||
| Переименование | + | + | + | ||
| Прерывание передачи | + | + | + | + | + |
| Прерывание передачи отдельного файла | |||||
| Протоколирование | |||||
| Дуплексная передача | |||||
| Дуплексный Chat | |||||
| Скорость при соединении DTE—DTE, Кбит/с | 19,2 | 19,2 | 19,2 | 19,2 | 19,2 |
В табл. 9.9 приведены сравнительные характеристики наиболее распространенных протоколов передачи файлов. Эта информация может оказать дополнительную помощь при выборе наиболее подходящего для ваших условии протокола.
Продолжение таблицы 9.9
| ZModem | Kermit | SeaLInk | HyperProtocol | BIModem | HS/LInk | Hydra |
| + | ||||||
| + | + | |||||
| + | + | + | + | + | ||
| + | + | + | + | |||
| + | + | |||||
| •i- | + | + | + | + | + | + |
| + | + | + | + | + | + | |
| + | + | + | + | + | ||
| + | + | |||||
| + | + | + | + | + | + | + |
| + | + | + | + | + | ||
| 64 | 10 | 128 | 128 | 16 | 64 | 64 |
| 8К | 9К | 128 | 2К | 4К | 4К | 2К |
| + | + | + | + | |||
| + | + | + | + | + | + | + |
| + | + | + | + | + | + | |
| + | + | + | + | |||
| + | + | + | + | |||
| + | + | + | + | + | + | |
| + | + | + | + | |||
| + | + | + | + | + | + | + |
| + - | + | + | + | + | + | + |
| + | + | ,' + | + | + | ||
| + | + | + | + | + | ||
| + | + | + | ||||
| + | + | + | ||||
| 38,4 | 19,2 | 19,2 | 115,2 | 115,2 | 115,2 | 57,6 |
Одним из самых быстрых является протокол HyperProtocol. Как и Zmodem, он является потоковым протоколом, но помимо этого может сжимать передаваемые данные, как и протокол Kermit. Согласно протокола HyperProtocol приемник посылает подтвержение не после каждого файла, а в конце всего сеанса передачи. Он может быть с успехом использован для передачи информации по высрокоскоростньтм каналам.
Особенность протокола BiModem состоит в том, что он является дуплексным, т.е. позволяет одновременно передавать файлы во встречных направлениях. Протокол BiModem также предусматривает возобновление передачи после обрыва связи и гибкое изменение размера блока от 16 байт до 16 Кбайт.
Однако Bi Modem недостаточно устойчиво работает по каналам с высоким уровнем помех.
Близким по функциональным возможностям к протоколу Bi Modem является дуплексный протокол HS/Link. Также как и протокол BiModem, он предоставляет возможность пользователям во время предачи файлов общаться в режиме Chat.
Высокоскоростной дуплексный протокол Hydra отличается хорошей ус-тойчивочтью работы на линиях низкого качества и каналах с большими задержками передачи.
Часто выбор протокола передачи файлов ограничен возможностями используемой коммуникационной программы. Тем не менее, существует возможность подключения некоторых протоколов передачи файлов к отдельным терминальным программам, которые штатно не предусматривают их использование. Это возможно в основном для большинства программ для DOS. Подключаемые внешние протоколы в таком случае должны быть в виде ис-полнямых (*.ехе) файлов.
|
|
 |
