XMODEM — это простой протокол передачи файлов , разработанный Уордом Кристенсеном в качестве быстрого хака для использования в его терминальной программе MODEM.ASM 1977 года . Он позволял пользователям передавать файлы между своими компьютерами, когда обе стороны использовали MODEM. Кит Петерсен сделал небольшое обновление, чтобы всегда включать «тихий режим», и назвал результат XMODEM. [3] [4]
XMODEM, как и большинство протоколов передачи файлов, разбивает исходные данные на ряд " пакетов ", которые отправляются получателю вместе с дополнительной информацией, позволяющей получателю определить, был ли пакет получен правильно. Если обнаружена ошибка, получатель запрашивает повторную отправку пакета. Последовательность плохих пакетов приводит к прерыванию передачи.
XMODEM стал чрезвычайно популярен на раннем рынке систем досок объявлений (BBS), в основном потому, что его было просто реализовать. Он также был довольно неэффективен, и по мере увеличения скорости модемов эта проблема привела к разработке ряда модифицированных версий XMODEM для повышения производительности или решения других проблем с протоколом. [4] Кристенсен считал, что его оригинальный XMODEM был «единственной наиболее модифицированной программой в истории вычислений». [5]
Чак Форсберг собрал ряд общих модификаций в своем протоколе YMODEM , но плохая реализация привела к дальнейшему раздроблению, прежде чем они были вновь объединены его более поздним протоколом ZMODEM . ZMODEM стал очень популярным, но так и не заменил XMODEM на рынке BBS.
Оригинальный XMODEM использовал 128-байтовый пакет данных, базовый размер блока, используемый на дискетах CP/M . Пакету предшествовал простой 3-байтовый заголовок, содержащий символ, «номер блока» от 1 до 255 и «обратный» номер блока — 255 минус номер блока. Нумерация блоков начинается с 1 для первого отправленного блока, а не с 0. За заголовком следовали 128 байт данных, а затем однобайтовая контрольная сумма . Контрольная сумма представляла собой сумму всех 128 байтов данных в пакете по модулю 256. Таким образом, полный пакет имел длину 132 байта, содержащую 128 байтов полезных данных , что обеспечивало общую эффективность канала около 97%.<SOH>
Файл был помечен как «завершенный» символом, отправленным после последнего блока. Этот символ не был в пакете, а отправлялся отдельно как один байт. Поскольку длина файла не отправлялась как часть протокола, последний пакет был дополнен «известным символом», который можно было отбросить. В исходной спецификации по умолчанию это было равно или 26 десятичным, что CP/M использовал в качестве маркера конца файла внутри своего собственного формата диска. Стандарт предполагал, что любой символ может быть использован для заполнения, но не было возможности изменить его в самом протоколе — если реализация изменяла символ заполнения, только клиенты, использующие ту же реализацию, могли правильно интерпретировать новый символ заполнения.<EOT><SUB>
Файлы передавались по одному пакету за раз. При получении получатель вычислял контрольную сумму пакета и сравнивал ее с полученной от отправителя в конце пакета. Если они совпадали, получатель отправлял сообщение отправителю , который затем отправлял следующий пакет по порядку. Если возникала проблема с контрольной суммой, получатель вместо этого отправлял . Если получался , отправитель повторно отправлял пакет [4] и продолжал попытки несколько раз, обычно десять, прежде чем прерывать передачу.<ACK><NAK><NAK>
A <NAK>также отправлялся, если получатель не получал действительный пакет в течение десяти секунд, все еще ожидая данные из-за отсутствия символа <EOT>. Семисекундный тайм-аут также использовался внутри пакета, защищая от разрывов соединений в середине пакета.
Номера блоков также проверялись простым способом на наличие ошибок. После успешного получения пакета следующий пакет должен был иметь номер на единицу больше. Если вместо этого он получал тот же номер блока, это не считалось серьезным, подразумевалось, что <ACK>отправитель не получил пакет, который затем повторно отправлял его. Любой другой номер пакета сигнализировал о том, что пакеты были потеряны.
Передачи управлялись приемником; передатчик не отправлял никаких данных, пока <NAK>получатель не отправлял начальные данные. Это было логическим результатом того, как пользователь взаимодействовал с отправляющей машиной, которая находилась удаленно. Пользователь переходил к запрошенному файлу на отправляющей машине, а затем просил эту машину передать его. После того, как эта команда была выдана, пользователь затем выполнял команду в своем локальном программном обеспечении, чтобы начать прием. Поскольку задержка между запросом файла у удаленной системы и выдачей локальной команды на прием была неизвестна, XMODEM позволял получателю до 90 секунд, чтобы начать выдавать запросы на пакеты данных.
Хотя протокол XMODEM был достаточно надёжен для того, чтобы журналист в 1982 году мог передавать материалы из Пакистана в США с помощью Osborne 1 и акустического соединителя по некачественным телефонным линиям [6] , у протокола было несколько недостатков.
XMODEM был написан для машин CP/M и несет на себе несколько признаков этой операционной системы . Примечательно, что файлы на CP/M всегда были кратны 128 байтам, и их конец отмечался внутри блока символом <EOT>. Эти характеристики были перенесены непосредственно в XMODEM. Однако другие операционные системы не обладали ни одной из этих особенностей, и широкое внедрение MS-DOS в начале 1980-х годов привело к необходимости обновления XMODEM, чтобы заметить или <EOT> как <EOF> маркер конца файла.
Некоторое время предполагалось, что отправка <CAN>символа вместо <ACK>или <NAK>должна поддерживаться для того, чтобы легко отменить передачу с принимающей стороны. Аналогично, <CAN>полученный вместо <SOH>указанного отправителем желал отменить передачу. Однако этот символ можно было легко «создать» с помощью простых ошибок, связанных с шумом, того, что должно было быть <ACK>или <NAK>. Двойной - <CAN>был предложен для того, чтобы избежать этой проблемы, но неясно, было ли это широко реализовано.
XMODEM был разработан для простоты, без особых знаний о других протоколах передачи файлов, которые и так были довольно редки. Из-за его простоты существовало несколько очень простых ошибок, которые могли привести к сбою передачи или, что еще хуже, к неправильному файлу, который оставался незамеченным протоколом. Большая часть этого была связана с использованием простой контрольной суммы для исправления ошибок, [4] которая подвержена пропуску ошибок в данных, если два бита перепутаны, что может произойти при достаточно коротком всплеске шума. Кроме того, аналогичное повреждение заголовка или контрольной суммы могло привести к сбою передачи в случаях, когда сами данные были неповрежденными.
Многие авторы ввели расширения XMODEM для решения этих и других проблем. Многие просили включить эти расширения в новый стандарт XMODEM. Однако Уорд Кристенсен отказался это сделать, поскольку именно отсутствие этих функций и связанного с ними кодирования, необходимого для их поддержки, привело к широкому использованию XMODEM. Как он объяснил:
Другая проблема с XMODEM заключалась в том, что он требовал, чтобы передача управлялась пользователем, а не была автоматизирована. [4] Обычно это означало, что пользователь перемещался по системе отправителя, чтобы выбрать нужный файл, а затем использовал команду, чтобы перевести эту систему в режим «готовности к отправке». Затем они запускали передачу со своей стороны, используя команду в своем эмуляторе терминала. Если пользователь хотел передать другой файл, ему приходилось повторять этот процесс снова.
Для автоматизированной передачи между двумя сайтами со временем были реализованы некоторые дополнения к протоколу XMODEM. Они обычно предполагали, что отправитель будет продолжать отправлять файл за файлом, а получатель будет пытаться запустить следующий файл, отправив NAKкак обычно в начале передачи. Когда NAKвремя ожидания s истекало, можно было предположить, что либо файлов больше нет, либо связь в любом случае была разорвана.
MODEM7 , также известный как MODEM7 batch или Batch XMODEM , был первым известным расширением протокола XMODEM. Обычная передача файлов XMODEM начинается с того, что получатель отправляет один NAKсимвол отправителю, который затем начинает отправлять один символ, SOHчтобы указать начало данных, а затем пакеты данных.
MODEM7 изменил это поведение лишь немного, отправив имя файла в формате имени файла 8.3 перед <SOH>. Каждый символ отправлялся индивидуально и должен был быть отражен приемником в качестве формы исправления ошибок. Для реализации XMODEM без поддержки эти данные просто игнорировались, пока ожидалось получение SOH, поэтому символы не отображались, и реализация могла вернуться к обычному XMODEM. С помощью «осведомленного» программного обеспечения имя файла можно было использовать для локального сохранения файла. Передачи могли продолжаться с другим <NAK>, каждый файл сохранялся под именем, отправляемым получателю.
Джерри Пурнелл в 1983 году описал MODEM7 как «вероятно самую популярную из существующих программ для микрокомпьютерной связи». [7]
MODEM7 отправлял имя файла как обычный текст, что означало, что он мог быть поврежден теми же проблемами, которых пытался избежать XMODEM. Это привело к появлению TeLink Томом Дженнингсом , автором оригинальных почтовых программ FidoNet .
TeLink избежал проблем MODEM7, стандартизировав новый «нулевой пакет», содержащий информацию об исходном файле. Он включал имя файла, размер и временную метку , которые были помещены в обычный 128-байтовый блок XMODEM. В то время как обычная передача XMODEM начиналась с того, что отправитель отправлял «блок 1» с <SOH>заголовком, пакет заголовка TeLink был помечен как «блок 0» и начинался с <SYN>. Пакет содержал дату и время создания файла, имя файла длиной до 16 символов, размер файла в виде 4-байтового значения и имя программы, отправившей файл. [8]
Обычная реализация XMODEM просто отбрасывала бы пакет, предполагая, что номер пакета был поврежден. Но это приводило к потенциальной задержке во времени, если пакет был отброшен, так как отправитель не мог определить, ответил ли получатель с помощью , <NAK>потому что он не понял нулевой пакет или потому что произошла ошибка передачи. Поскольку TeLink обычно использовался только программным обеспечением FidoNet , которое требовало этого как части стандартов FidoNet, это не представляло реальной проблемы, так как оба конца всегда поддерживали этот стандарт. [8]
Базовая система «блока 0» стала стандартом в сообществе FidoNet и была повторно использована рядом будущих протоколов, таких как SEAlink и YMODEM .
Контрольная сумма, используемая в исходном протоколе, была чрезвычайно проста, и ошибки в пакете могли остаться незамеченными. Это привело к введению XMODEM-CRC Джоном Бирнсом [9] [10] , который использовал 16-битную CRC вместо 8-битной контрольной суммы. [4] CRC кодируют не только данные в пакете, но и их местоположение, позволяя ему замечать ошибки замены битов, которые контрольная сумма пропустила бы. Статистически это сделало вероятность обнаружения ошибки длиной менее 16 бит 99,9969% и даже выше для более длинных строк битов ошибок. [11]
XMODEM-CRC был разработан для обратной совместимости с XMODEM. Для этого получатель отправлял Cсимвол (заглавная буква C) вместо a, <NAK>чтобы начать передачу. Если отправитель отвечал, отправляя пакет, предполагалось, что отправитель «знает» XMODEM-CRC, и получатель продолжал отправлять C's. Если пакет не поступал, получатель предполагал, что отправитель не знает протокол, и отправлял 's, <NAK>чтобы начать «традиционную» передачу XMODEM. [11]
К сожалению, эта попытка обратной совместимости имела и обратную сторону. Поскольку было возможно, что начальный Cсимвол будет утерян или поврежден, нельзя было предположить, что приемник не поддерживает XMODEM-CRC, если первая попытка запустить передачу не удалась. Таким образом, приемник пытался начать передачу три раза с C, ожидая три секунды между каждой попыткой. Это означало, что если пользователь выбирал XMODEM-CRC при попытке поговорить с любым XMODEM, как и предполагалось, перед началом передачи могла возникнуть задержка в 10 секунд. [11]
Чтобы избежать задержки, отправитель и получатель обычно перечисляли XMODEM-CRC отдельно от XMODEM, позволяя пользователю выбрать «базовый» XMODEM, если отправитель явно не перечислил его. Для обычного пользователя XMODEM-CRC был по сути «вторым протоколом» и рассматривался как таковой. Однако это не относилось к почтовым программам FidoNet, где CRC был определен как стандарт для всех передач TeLink. [8]
Поскольку протокол 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.
WXmodem , сокращение от "Windowed Xmodem", является вариантом XMODEM, разработанным Питером Босвеллом в 1986 году для использования на линиях с высокой задержкой, в частности, в общедоступных системах X.25 и PC Pursuit . Они имеют задержки, которые намного выше, чем у обычной телефонной службы , что приводит к очень низкой эффективности в XMODEM. Кроме того, эти сети часто используют управляющие символы для управления потоком и других задач, в частности, XON/XOFF остановит поток данных. Наконец, в случае ошибки, которая требовала повторной отправки, иногда было трудно узнать, SOHбыл ли a индикатором пакета или большим шумом. WXmodem адаптировал XMODEM-CRC для решения этих проблем. [11]
Одним из изменений было экранирование небольшого набора управляющих символов: DLE, XON, XOFFи SYN. Они экранировались путем вставки a DLEперед ними, а затем изменения символа путем XOR его с 64. Теоретически это означало, что пакет мог быть длиной до 264 байт, если он изначально состоял полностью из символов, которые требовали экранирования. Эти вставленные и измененные символы не являются частью расчета CRC, они удаляются и преобразуются на принимающей стороне перед расчетом CRC. [11]
Кроме того, все пакеты были снабжены префиксом в виде SYNсимвола, что означало, что лид-ин пакета был SYNSOH, что уменьшало вероятность того, что случайный символ SOHбудет принят за заголовок пакета в различных случаях ошибок. Неэкранированный символ, SYNнайденный в теле пакета, был ошибкой. [11]
Главным изменением в WXMODEM является использование скользящего окна для улучшения пропускной способности на каналах с высокой задержкой. Для этого ACKсообщения сопровождались номером пакета, который они ACKотправляли или NAKотправляли. Получатель не должен отправлять ACKкаждый пакет; ему разрешено отправлять ACKлюбое количество пакетов от одного до четырех. An ACKс четвертым порядковым номером пакета предполагается для ACKвсех четырех пакетов. Ошибка приводит к NAKнемедленной отправке a со всеми пакетами с этого номера и после повторной отправки. [11]
Требование ACKкаждых четырех пакетов заставляет систему работать так, как будто у нее есть пакет размером 512 байт, но в случае ошибки обычно требуется переслать только 128 байт. Более того, это уменьшает объем данных, передаваемых в обратном направлении, в четыре раза. Это не представляет большого интереса в полнодуплексной работе типичного модема, но важно в полудуплексных системах, таких как модели Telebit , которые имеют скорость 19 кБ в одном направлении и 75 бит/с в обратном канале.
Одним из первых сторонних почтовых программ для системы FidoNet был SEAdog , написанный тем же автором, что и популярный в то время формат сжатия данных .arc . SEAdog включал в себя широкий спектр усовершенствований, включая SEAlink , улучшенный протокол передачи, основанный на той же концепции скользящего окна, что и WXmodem. [12] Он отличался от WXmodem в основном деталями.
Одно из отличий заключается в том, что SEAlink поддерживал «нулевой пакет», введенный TeLink, который необходим для работы в качестве замены TeLink в системах FidoNet, где ожидался заголовок. ACKs и NAKs были расширены до трехбайтовых «пакетов», начинающихся с ACKили NAK, затем номер пакета, затем дополнение номера пакета, таким же образом, как и оригинальный заголовок пакета XMODEM. Размер окна обычно устанавливался в шесть пакетов. [12]
SEAlink не должен был работать по X.25 или аналогичным каналам, и поэтому не выполнял экранирование. Это также было необходимо для того, чтобы нулевой пакет работал правильно, так как этот стандарт использовал символ, SYNкоторый WXmodem переделал. [12] В дополнение к этим изменениям, он добавил режим «Overdrive» для полудуплексных каналов. Это подавляло ACK для пакетов, которые были успешно переданы, фактически делая окно бесконечным. Этот режим обозначался флагом в нулевом блоке. [12]
SEAlink позже добавил ряд других улучшений и стал полезным протоколом общего назначения. Однако он оставался редким за пределами мира FidoNet и редко встречался в программном обеспечении, ориентированном на пользователя.
Другой способ решения проблемы пропускной способности — увеличение размера пакета. Хотя фундаментальная проблема задержки остается, скорость, на которой она становится проблемой, выше. XMODEM-1K с пакетами по 1024 байта [4] был самым популярным таким решением. В этом случае пропускная способность при 9600 бит/с составляет 81%, учитывая те же предположения, что и выше.
XMODEM-1K был расширенной версией XMODEM-CRC, которая указывала более длинный размер блока в отправителе , начиная пакет с <STX>символа вместо <SOH>. Как и другие обратно совместимые расширения XMODEM, предполагалось, что передача -1K может быть начата с любой реализацией XMODEM на другом конце, отступая от функций по мере необходимости.
XMODEM-1K изначально был одним из многих улучшений XMODEM, представленных Чаком Форсбергом в его протоколе YMODEM . Форсберг предположил, что различные улучшения были необязательными, ожидая, что авторы программного обеспечения реализуют как можно больше из них. Вместо этого они, как правило, реализовывали самый минимум, что приводило к обилию полусовместимых реализаций и, в конечном итоге, разделению имени "YMODEM" на "XMODEM-1K" и множество YMODEM. Таким образом, XMODEM-1K фактически появился позже YMODEM, но в любом случае оставался довольно распространенным.
NMODEM — это протокол передачи файлов , разработанный LB Neal, который выпустил его в 1990 году. NMODEM по сути является версией XMODEM-CRC, использующей более крупные блоки по 2048 байт, в отличие от 128-байтовых блоков XMODEM. NMODEM был реализован как отдельная программа, написанная на Turbo Pascal 5.0 для семейства компьютеров , совместимых с IBM PC . Размер блока был выбран таким образом, чтобы соответствовать общему размеру кластера файловой системы MS-DOS FAT на современных жестких дисках , что упрощает буферизацию данных для записи. [13] [14]
В надежных (безошибочных) соединениях можно устранить задержку, «предварительно подтверждая» пакеты, метод, более известный как « подмена протокола ». Обычно это выполняется в аппаратном обеспечении связи, в частности, модемах Telebit. Модемы, когда опция включена, замечают заголовок XMODEM и немедленно отправляют ACK. Это заставляет отправляющую программу XMODEM немедленно отправлять следующий пакет, делая передачу непрерывной, как бесконечное окно. Модемы также подавляют отправку ACKпрограммного обеспечения XMODEM на дальнем конце, тем самым освобождая низкоскоростной обратный канал.
Система также может быть реализована в самом протоколе, и вариации XMODEM предлагали эту функцию. В этих случаях получатель отправлял бы ACKсразу после начала пакета, таким же образом, как модемы Telebit. Поскольку эта функция является только изменением поведения на стороне получателя, она не требует никаких изменений в протоколе на стороне отправителя. YMODEM формализовал эту систему.
Эту концепцию следует противопоставить концепции, используемой в SEAlink, которая изменяет поведение на обеих сторонах ссылки. В SEAlink получатель ACKполностью прекращает отправку, а отправитель меняет свое поведение, чтобы не ожидать их.