ХМОДЕМ

ХМОДЕМ

Протокол связи
Цель	протокол передачи файлов
Разработчик(и)	Уорд Кристенсен
Введение	1977 год ( 1977 )
Под влиянием	ЮМОДЕМ и многие другие.
Аппаратное обеспечение	модемы

XMODEM — это простой протокол передачи файлов качестве быстрого взлома в , разработанный Уордом Кристенсеном для использования в его MODEM.ASM терминальной программе 1977 года . Это позволяло пользователям передавать файлы между своими компьютерами, когда обе стороны использовали МОДЕМ. Кейт Петерсен внес небольшое обновление, чтобы всегда включать «тихий режим», и назвал результат XMODEM.

XMODEM, как и большинство протоколов передачи файлов, разбивает исходные данные на серию « пакетов », которые отправляются получателю вместе с дополнительной информацией, позволяющей получателю определить, был ли этот пакет правильно принят. Если обнаружена ошибка, получатель запрашивает повторную отправку пакета. Ряд плохих пакетов приводит к прерыванию передачи.

XMODEM стал чрезвычайно популярен на рынке первых систем досок объявлений (BBS), во многом потому, что его было просто реализовать. Это также было довольно неэффективно, и по мере увеличения скорости модемов эта проблема привела к разработке ряда модифицированных версий XMODEM для повышения производительности или решения других проблем с протоколом. Кристенсен считал, что его первоначальный XMODEM был «самой модифицированной программой в истории вычислений».

Чак Форсберг собрал ряд общих модификаций своего протокола YMODEM , но плохая реализация привела к дальнейшему расколу, прежде чем они были воссоединены в его более позднем ZMODEM протоколе . ZMODEM стал очень популярным, но так и не заменил XMODEM полностью на рынке BBS.

Структура пакета

Оригинальный XMODEM использовал пакет данных размером 128 байт — базовый размер блока, используемый на CP/M дискетах . Пакету предшествовал простой 3-байтовый заголовок, содержащий <SOH> символ, «номер блока» от 1 до 255 и «обратный» номер блока — 255 минус номер блока. Нумерация блоков начинается с 1 для первого отправленного блока, а не с 0. За заголовком следовали 128 байтов данных, а затем однобайтовая контрольная сумма . Контрольная сумма представляла собой сумму всех 128 байтов данных в пакете по модулю 256. Таким образом, полный пакет имел длину 132 байта и содержал 128 байтов полезных данных , что обеспечивало общую эффективность канала около 97%.

Файл был помечен как «завершенный» с помощью <EOT> символ, отправленный после последнего блока. Этот символ не был в пакете, а был отправлен отдельно в виде одного байта. Поскольку длина файла не была передана как часть протокола, последний пакет был дополнен «известным символом», который можно было отбросить. В исходной спецификации по умолчанию это значение <SUB> или 26-десятичный формат, который CP/M использовал в качестве маркера конца файла внутри своего собственного дискового формата. его нельзя было изменить Стандарт предполагал, что для заполнения можно использовать любой символ, но в самом протоколе — если реализация меняла символ заполнения, только клиенты, использующие ту же реализацию, могли правильно интерпретировать новый символ заполнения.

Детали трансфера

Файлы передавались по одному пакету за раз. При получении контрольная сумма пакета рассчитывается получателем и сравнивается с суммой, полученной от отправителя в конце пакета. Если они совпадают, получатель отправляет сообщение <ACK> сообщение обратно отправителю, который затем последовательно отправляет следующий пакет. Если была проблема с контрольной суммой, получатель вместо этого отправлял <NAK>. Если <NAK> был получен, отправитель повторно отправлял пакет и продолжал попытки несколько раз, обычно десять, прежде чем прервать передачу.

А <NAK> также было отправлено, если получатель не получил действительный пакет в течение десяти секунд, все еще ожидая данных из-за отсутствия <EOT> характер. также использовался семисекундный тайм-аут Внутри пакета для защиты от разрыва соединений в середине пакета.

Номера блоков также были проверены простым способом на предмет ошибок. После успешного получения пакета следующий пакет должен иметь номер на единицу больше. Если вместо этого он получал тот же номер блока, это не считалось серьезным, подразумевалось, что <ACK> не был получен отправителем, который затем повторно отправил пакет. Любой другой номер пакета сигнализировал о том, что пакеты потеряны.

Трансферы осуществлялись получателем; передатчик не будет отправлять никаких данных до тех пор, пока не будет <NAK> было отправлено получателем. Это было логичным результатом взаимодействия пользователя с отправляющим устройством, которое должно было располагаться удаленно. Пользователь перейдет к запрошенному файлу на отправляющем компьютере, а затем попросит этот компьютер передать его. После подачи этой команды пользователь должен был выполнить команду в своем локальном программном обеспечении, чтобы начать прием. Поскольку задержка между запросом файла у удаленной системы и выдачей локальной команды на получение была неизвестна, XMODEM давал получателю до 90 секунд, чтобы начать выдачу запросов на пакеты данных.

Проблемы

Хотя XMODEM был достаточно надежным, чтобы в 1982 году журналист мог передавать статьи из Пакистана в Соединенные Штаты с помощью Osborne 1 и акустического соединителя по телефонным линиям низкого качества, протокол имел несколько недостатков.

Незначительные проблемы

XMODEM был написан для машин CP/M и имеет несколько признаков этой операционной системы . Примечательно, что файлы на CP/M всегда были кратны 128 байтам, а их конец отмечался внутри блока знаком <EOT> характер. Эти характеристики были перенесены непосредственно в XMODEM. Однако другие операционные системы не имели ни одной из этих особенностей, а широкое распространение MS-DOS в начале 1980-х годов привело к необходимости обновления XMODEM, чтобы заметить либо <EOT> или <EOF> в качестве маркера конца файла.

Некоторое время предлагалось отправить <CAN> персонаж вместо <ACK> или <NAK> должен поддерживаться, чтобы можно было легко прервать передачу с принимающей стороны. Аналогично, <CAN> получен взамен <SOH> указывает, что отправитель желает отменить перевод. Однако этого персонажа можно было легко «создать» с помощью простых ошибок, связанных с шумом того, что должно было быть <ACK> или <NAK>. Двойной- <CAN> было предложено избежать этой проблемы, но неясно, было ли это широко реализовано.

Основные проблемы

XMODEM был разработан для простоты, без особых знаний других протоколов передачи файлов, которые и так были довольно редки. Из-за его простоты существовал ряд очень простых ошибок, которые могли привести к сбою передачи или, что еще хуже, к созданию неправильного файла, который остался незамеченным протоколом. Во многом это произошло из-за использования простой контрольной суммы для исправления ошибок, которая может привести к пропуску ошибок в данных, если два бита поменялись местами, что может произойти при достаточно коротком всплеске шума. Кроме того, подобное повреждение заголовка или контрольной суммы может привести к сбою передачи в тех случаях, когда сами данные не были повреждены.

Многие авторы представили расширения XMODEM для решения этих и других проблем. Многие просили включить эти расширения в новый стандарт XMODEM. Однако Уорд Кристенсен отказался это сделать, поскольку именно отсутствие этих функций и соответствующего кода, необходимого для их поддержки, привело к широкому использованию XMODEM. Как он объяснил:

Это был быстрый хак, который я придумал, совершенно незапланированный (как и все, что я делаю), чтобы удовлетворить личную потребность в общении с другими людьми. ТОЛЬКО тот факт, что это было сделано в 8/77, и что я немедленно выложил это в общественное достояние, сделало это стандартом, которым оно является...

...Люди, которые предлагают мне внести ЗНАЧИТЕЛЬНЫЕ изменения в протокол, такие как «полнодуплексный режим», «множество невыполненных блоков», «множество пунктов назначения» и т. д. и т. п., не понимают, что невероятная простота протокола является одной из причин. оно выжило.

Пакетные переводы

Другая проблема с XMODEM заключалась в том, что передача должна была осуществляться пользователем, а не автоматически. Обычно это означало, что пользователь перемещался по системе отправителя, чтобы выбрать нужный файл, а затем использовал команду, чтобы перевести эту систему в режим «готов к отправке». Затем они запускали передачу со своей стороны, используя команду в своем эмуляторе терминала. Если пользователь захочет передать другой файл, ему придется повторить этот процесс еще раз.

Для автоматической передачи между двумя сайтами со временем был реализован ряд дополнений к протоколу XMODEM. Обычно предполагалось, что отправитель продолжит отправлять файл за файлом, а получатель попытается инициировать следующий файл, отправив сообщение NAK как обычно в начале передачи. Когда NAKЕсли таймаут истек, можно было предположить, что либо файлов больше нет, либо ссылка все равно битая.

МОДЕМ7

MODEM7 , также известный как пакетный режим MODEM7 или пакетный XMODEM , был первым известным расширением протокола XMODEM. Обычная передача файла XMODEM начинается с отправки получателем одного NAK символ отправителю, который затем начинает отправлять одиночный SOH для обозначения начала данных, а затем пакетов данных.

MODEM7 лишь незначительно изменил это поведение, отправив имя файла в формате имени файла 8.3 перед <SOH>. Каждый символ отправлялся индивидуально и должен был быть повторен получателем в качестве формы исправления ошибок. Для неосведомленной реализации XMODEM эти данные будут просто игнорироваться, пока она ожидает SOH чтобы символы не отображались эхом и реализация могла вернуться к обычному XMODEM. При использовании «осведомленного» программного обеспечения имя файла можно использовать для локального сохранения файла. Трансферы могут продолжиться с другим <NAK>, каждый файл сохраняется под именем, отправляемым получателю.

Джерри Пурнель в 1983 году описал MODEM7 как «вероятно, самую популярную из существующих программ связи для микрокомпьютеров».

ТеЛинк

MODEM7 отправил имя файла в виде обычного текста, а это означало, что оно могло быть повреждено теми же проблемами, которых XMODEM пытался избежать. Это привело к появлению TeLink , автором Томом Дженнингсом оригинальных почтовых программ FidoNet .

TeLink избежал проблем MODEM7, стандартизировав новый «нулевой пакет», содержащий информацию об исходном файле. файла Сюда входило имя, размер и временная метка , которые помещались в обычный 128-байтовый блок XMODEM. В то время как обычная передача XMODEM начинается с отправки отправителем «блока 1» с <SOH> пакет заголовка TeLink был помечен как «блок 0» и начинался с <SYN>. Пакет содержал дату и время создания файла, имя файла длиной до 16 символов, размер файла в виде 4-байтового значения и имя программы, отправляющей файл.

Обычная реализация XMODEM просто отбрасывает пакет, предполагая, что номер пакета поврежден. Но это приводило к потенциальной задержке во времени, если пакет был отброшен, поскольку отправитель не мог определить, ответил ли получатель сообщением <NAK> потому что он не понял нулевой пакет или из-за ошибки передачи. Поскольку TeLink обычно использовался только программным обеспечением FidoNet , которое требовало его как часть стандартов FidoNet, это не представляло реальной проблемы, поскольку оба конца всегда поддерживали этот стандарт.

Базовая система «блока 0» стала стандартом в сообществе FidoNet и повторно использовалась в ряде будущих протоколов, таких как SEAlink и YMODEM .

XMODEM-CRC

Контрольная сумма, использованная в исходном протоколе, была чрезвычайно простой, и ошибки внутри пакета могли остаться незамеченными. Это привело к появлению XMODEM-CRC Джоном Бирнсом. который использовал 16-битную CRC вместо 8-битной контрольной суммы. CRC кодирует не только данные в пакете, но и его местоположение, позволяя замечать ошибки замены битов, которые может пропустить контрольная сумма. По статистике, это сделало вероятность обнаружения ошибки длиной менее 16 бит 99,9969%, а для более длинных строк битов ошибки даже выше.

XMODEM-CRC был разработан с учетом обратной совместимости с XMODEM. Для этого получатель отправил C (заглавная C) вместо буквы <NAK> чтобы начать передачу. Если отправитель ответил отправкой пакета, предполагалось, что отправитель «знал» XMODEM-CRC, и получатель продолжал отправлять. Cх. Если пакет не поступил, получатель предполагал, что отправитель не знает протокол, и отправлял сообщение. <NAK> чтобы начать «традиционную» передачу XMODEM.

К сожалению, эта попытка обратной совместимости имела и обратную сторону. Поскольку возможно, что первоначальный C символ будет потерян или поврежден, нельзя предположить, что получатель не поддерживает XMODEM-CRC, если первая попытка инициировать передачу не удалась. Таким образом, получатель трижды пытался начать передачу с C, ожидая три секунды между каждой попыткой. Это означало, что если пользователь выбирал XMODEM-CRC при попытке связаться с любым XMODEM, как и предполагалось, перед началом передачи произошла потенциальная задержка в 10 секунд.

Чтобы избежать задержки, отправитель и получатель обычно указывают XMODEM-CRC отдельно от XMODEM, позволяя пользователю выбрать «базовый» XMODEM, если отправитель не указал его явно. Для обычного пользователя XMODEM-CRC был по существу «вторым протоколом» и рассматривался как таковой. Однако это не относится к почтовым программам FidoNet, где CRC был определен как стандарт для всех передач TeLink.

Более высокая пропускная способность

Поскольку протокол XMODEM требовал от отправителя остановки и ожидания <ACK> или <NAK> сообщение от получателя, оно, как правило, было довольно медленным. В эпоху модемов со скоростью 300 бит/с для отправки всего 132-байтового пакета требовалось 4,4 секунды (132 байта * (8 бит на байт + 1 стартовый бит + 1 стоповый бит) / 300 бит в секунду). Предположим, что получателю требуется 0,2 секунды. <ACK> Чтобы вернуться к отправителю и следующий пакет начал попадать к получателю (0,1 секунды в обоих направлениях), общее время для одного пакета составит 4,6 секунды, что составляет чуть более 92% эффективности канала.

Время для <ACK>/ <NAK> Этот процесс был фиксированной функцией базовой сети связи, а не производительности модемов. По мере увеличения скорости модема фиксированная задержка росла пропорционально времени, необходимому для отправки пакета. Например, при скорости 2400 бит/с отправка пакетов занимала всего 0,55 секунды, поэтому, если <ACK>/ <NAK> по-прежнему требовалось 0,2 секунды, чтобы вернуться на компьютер пользователя, эффективность упала до 71%. При скорости 9600 бит/с это чуть меньше 40% — на ожидание ответа тратится больше времени, чем необходимо для отправки пакета.

Для решения этих проблем был представлен ряд новых версий XMODEM. Как и более ранние расширения, эти версии имели тенденцию быть обратно совместимыми с исходным XMODEM, и, как и эти расширения, это приводило к дальнейшему разрушению ландшафта XMODEM в эмуляторе пользовательского терминала. В итоге появились десятки версий XMODEM.

WXМодем

WXmodem , сокращение от «Windowed Xmodem», представляет собой вариант XMODEM, разработанный Питером Босвеллом в 1986 году для использования на линиях с высокой задержкой, в частности, в общедоступных системах X.25 и PC Pursuit . У них задержки намного выше, чем у старых добрых телефонных служб , что приводит к очень низкой эффективности XMODEM. Кроме того, в этих сетях часто используются управляющие символы для управления потоком и других задач, в частности, XON/XOFF останавливает поток данных. Наконец, в случае ошибки, требующей повторной отправки, иногда было трудно узнать, был ли SOH был индикатор пакета или еще шум. WXmodem адаптировал XMODEM-CRC для решения этих проблем.

Одним из изменений было экранирование небольшого набора управляющих символов: DLE, XON, XOFF и SYN. Они были экранированы путем вставки DLE перед ними, а затем модифицируя символ, выполняя для него операцию XOR с числом 64. Теоретически это означало, что длина пакета может достигать 264 байт, если он изначально полностью состоял из символов, требующих экранирования. Эти вставленные и измененные символы не являются частью расчета CRC, они удаляются и преобразуются на принимающей стороне перед расчетом CRC.

Кроме того, все пакеты имели префикс SYN символ, что означало, что вводный пакет был SYNSOH, уменьшая вероятность того, что случайный SOH в различных случаях ошибок можно было бы спутать с заголовком пакета. Несбежавший SYN В теле пакета обнаружена ошибка.

Основным изменением в WXMODEM является использование скользящего окна для повышения пропускной способности на каналах с высокой задержкой. Для этого ACK за сообщениями следовал номер пакета, в котором они были ACKили NAKинж. Получатель не обязан ACK каждый пакет; разрешено ACK любое количество от одного до четырех пакетов. Ан ACK с четвертым порядковым номером пакета предполагается ACK все четыре пакета. Ошибка вызывает NAK быть отправлено немедленно, со всеми пакетами с этого номера и после повторной отправки.

Требование ACK каждые четыре пакета заставляют систему работать так, как будто размер пакета составляет 512 байт, но в случае ошибки обычно для повторной отправки требуется только 128 байт. Более того, это уменьшает объем данных, передаваемых в обратном направлении, в четыре раза. Это малоинтересно для полнодуплексной работы типичного модема, но важно в полудуплексных системах, таких как модели Telebit , которые имеют скорость 19 КБ в одном направлении и 75 бит/с в обратном канале.

СЭАлинк

Одним из первых сторонних почтовых программ для системы FidoNet был SEAdog , написанный тем же автором, что и популярный в то время .arc формат сжатия данных . SEAdog включал в себя множество улучшений, в том числе SEAlink , улучшенный протокол передачи, основанный на той же концепции скользящего окна, что и WXmodem. От WXmodem он отличался главным образом деталями.

Единственное отличие состоит в том, что SEAlink поддерживает «нулевой пакет», представленный TeLink, который необходим для работы в качестве замены TeLink в системах FidoNet, где ожидался заголовок. ACKпесок NAKбыли расширены до трехбайтовых «пакетов», начиная с ACK или NAK, затем номер пакета, затем дополнение к номеру пакета, аналогично исходному заголовку пакета XMODEM. Размер окна обычно устанавливался равным шести пакетам.

Не предполагалось, что SEAlink будет работать через X.25 или аналогичные каналы, поэтому экранирование не выполнялось. Это также было необходимо для правильной работы нулевого пакета, поскольку в этом стандарте использовался SYN персонаж, который WXmodem изменил. Помимо этих изменений, был добавлен режим «Overdrive» для полудуплексных каналов. Это подавляло ACK для успешно переданных пакетов, что фактически делало окно бесконечного размера. Этот режим указывался флагом в нулевом блоке.

Позднее в SEAlink был добавлен ряд других улучшений, и он стал полезным протоколом общего назначения. Однако он оставался редким за пределами мира FidoNet и редко встречался в программном обеспечении, ориентированном на пользователя.

ХМОДЕМ-1К

Другой способ решить проблему пропускной способности — увеличить размер пакета. Хотя фундаментальная проблема задержки остается, скорость, с которой она становится проблемой, выше. XMODEM-1K с пакетами размером 1024 байта был самым популярным таким решением. В этом случае пропускная способность при 9600 бит/с составляет 81% при тех же предположениях, что и выше.

XMODEM-1K был расширенной версией XMODEM-CRC, которая указывала более длинный размер блока у отправителя , начиная пакет с <STX> персонаж вместо <SOH>. Как и другие обратно совместимые расширения XMODEM, предполагалось, что передачу -1K можно будет начать с любой реализации XMODEM на другом конце, отключая функции по мере необходимости.

XMODEM-1K изначально был одним из многих улучшений XMODEM, представленных Чаком Форсбергом в его YMODEM протоколе . Форсберг предположил, что различные улучшения не являются обязательными, ожидая, что авторы программного обеспечения реализуют как можно больше из них. Вместо этого они обычно реализовали минимум, что привело к множеству полусовместимых реализаций и, в конечном итоге, к разделению названия «YMODEM» на «XMODEM-1K» и множество YMODEM. Таким образом, XMODEM-1K фактически появился позже YMODEM, но все равно оставался довольно распространенным.

НМОДЕМ

NMODEM — это протокол передачи файлов , разработанный Л. Б. Нилом, который выпустил его в 1990 году. NMODEM — это, по сути, версия XMODEM-CRC, использующая более крупные блоки по 2048 байт, в отличие от блоков XMODEM по 128 байт.NMODEM был реализован как отдельная программа, написанная на Turbo Pascal 5.0 для семейства компьютеров , совместимых с IBM PC . Размер блока был выбран так, чтобы соответствовать обычному размеру кластера файловой системы MS-DOS FAT на современных жестких дисках , что упрощает буферизацию данных для записи.

Подмена протокола

При использовании надежных (безошибочных) соединений можно устранить задержку путем «предварительного подтверждения» пакетов — метода, более известного как « подмена протокола ». Обычно это достигается с помощью аппаратных средств связи, особенно модемов Telebit. Модемы, когда эта опция была включена, замечали заголовок XMODEM и немедленно отправляли сообщение. ACK. Это приведет к тому, что отправляющая программа XMODEM немедленно отправит следующий пакет, что сделает передачу непрерывной, как окно бесконечного размера. Модемы также подавляют ACK отправляется программным обеспечением XMODEM на дальнем конце, тем самым освобождая низкоскоростной обратный канал.

Система также может быть реализована в самом протоколе, и варианты XMODEM предлагают эту функцию. В этих случаях получатель отправляет ACK как только пакет стартовал, аналогично модемам Телебит. Поскольку эта функция представляет собой лишь изменение поведения на стороне получателя, она не требует каких-либо изменений в протоколе на стороне отправителя. YMODEM формализовал эту систему.

Эту концепцию следует противопоставить той, которая используется в SEAlink, которая меняет поведение по обе стороны ссылки. В SEAlink получатель прекращает отправку ACK полностью, и отправитель меняет свое поведение, чтобы не ожидать их.

См. также

• ВЗРЫВ (протокол)
• Кермит (протокол)

Ссылки

Библиография

• Буш, Рэнди (30 сентября 1995 г.). Технический стандарт FidoNet FTS-0001 (Технический отчет).
• Кристенсен, Уорд (1 января 1982 г.). «Обзор протокола XMODEM» .
• Форсберг, Чак (11 сентября 1986 г.). «ССЫЛКА НА ПРОТОКОЛ XMODEM/YMODEM» .
• Босуэлл, Питер (20 июня 1986 г.). «Протоколы передачи файлов XMODEM, CRC XMODEM, WXMODEM» . CRC ХМОДЕМ.
• Протокол передачи файлов SEALINK (Технический отчет). 24 августа 1987 года.

Внешние ссылки

• MODEM.ASM , исходный код, Уорд Кристенсен, 10 октября 1977 г.
• Справочник по протоколу XMODEM/YMODEM, Чак Форсберг , 10 октября 1985 г.
• Справочник по протоколу XMODEM/YMODEM, автор Чак Форсберг , 18 июня 1988 г. (документ переформатирован 14 октября 1988 г.) (HTML-версия с текстовыми проблемами)
• Протоколы передачи файлов XMODEM/XMODEM-CRC/WXMODEM , Synchro.net
• Расширения Adontec XMODEM/32k и XMODEM/64k , adontec.com