9.6.1. Требования протокола zModem
Для реализации протокола ZModem требуется коммуникационная среда с октетной (8-битной) передачей. Протокол может удалять знаки управления для обеспечения передачи в сетях с коммутацией пакетов. Для поддержки полной потоковой (непрерывной) передачи в канале (streaming) требуется реализация метода управления потоком.
Содержимое двоичных файлов
Протокол ZModem не накладывает никаких ограничений на информационное содержание файлов. Однако количество битов в файле должно быть кратно 8. Принцип действия протокола позволяет выполнять кодирование блоков для непрозрачных сред передачи данных. Возможно применение методов уп- , равления потоком XON/XOFF или управление по отдельному каналу, как это выполнено в сетях стандарта Х.25.
Содержимое текстовых файлов
Так как протокол ZModem используется для передачи файлов между различными типами вычислительных систем, текстовые файлы должны удовлетворять требованию "читаемости" в широком диапазоне систем. Строки текста состоят из знаков кода ASCII, пробела (Space), табуляции (Tab) и возврата на одну позицию (Backspace).
Конец строки в коде ASCII
Строка текста в кодах ASCII должна завершаться последовательностью CR/LF (13h, 10h) или знаком NUL (Oh). Строки, завершающиеся только знаком CR (13h) не являются текстом в кодах ASCII. Ввод знака CR без знака LF не прерывает вывод на данной строке и неприемлем в качестве логического разделителя строк. Содержимое таких строк должно выводится на следующем проходе для отображения на дисплее всего текста.
9.6.2. Формат кадров протокола zModem
Блоки данных протокола 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 — младший байт флага; РО — младший байт позиции файла; РЗ — старший байт позиции файла.
Двоичный заголовок с проверочной комбинацией CRC-16
В двоичном заголовке кодирование ZDLE обеспечивает управление потоком по методу XON/XOFF. Двоичный заголовок начинается последовательностью ZPAD, ZDLE, ZBIN. Затем следует байт типа кадра, 4 байта позиции флага, 2 байта проверочной комбинации, кодированные с помощью ZDLE. В зависимости от типа кадра за заголовком могут следовать блоки пакетов данных, охваченные проверкой CRC-16:
ZDLE |
1 А |
TYPE |
F3/PO |
F2/P1 |
F1/P3 |
FO/P3 |
CRC-16 |
Двоичный заголовок с проверочной комбинацией CRC-32
Такой двоичный заголовок аналогичен заголовку с 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
В настоящее время пакеты данных в коде ASCII не определены. Эти пакеты могут использоваться для команд серверов или для основных передач в системах с 7-разрядным форматом.