Jump to content

ЮМОДЕМ

ЮМОДЕМ
Протокол связи
Цель протокол передачи файлов
Разработчик(и) Чак Форсберг
Введение 1985 год ; 39 лет назад ( 1985 )
На основе ХМОДЕМ
Под влиянием Я БУДУ
Аппаратное обеспечение модемы

YMODEM протокол передачи файлов , используемый между микрокомпьютерами, соединенными между собой с помощью модемов . В основном он использовался для передачи файлов в системы досок объявлений и из них . YMODEM был разработан Чаком Форсбергом как расширение XMODEM и впервые был реализован в его CP/M YAM программе . Первоначально также известный как YAM, ему было официально присвоено название «YMODEM» в 1985 году Уордом Кристенсеном , автором оригинального XMODEM.

YMODEM расширил XMODEM тремя способами, объединив функции других расширенных разновидностей XMODEM. Как и XMODEM-CRC, YMODEM заменил 8-битную контрольную сумму 16-битной циклической избыточной проверкой (CRC), но сделал ее формой коррекции по умолчанию, а не необязательной. Из TeLink он добавил заголовок «блок 0», который отправлял имя и размер файла, что позволяло осуществлять пакетную передачу (несколько файлов за один сеанс) и устраняло необходимость добавлять поля в конце файла. Наконец, YMODEM позволил увеличить размер блока с исходных 128 байт данных до 1024, как в XMODEM-1k , что значительно улучшило пропускную способность на более быстрых модемах.

Форсберг создал стандарт со всеми этими функциями в качестве опций времени выполнения, позволяя одному драйверу протокола использовать XMODEM-CRC или даже XMODEM при подключении к системам, не поддерживающим YAM. Он считал, что программисты захотят реализовать как можно больше этих функций на любой конкретной платформе. Он был встревожен, обнаружив, что большинство реализаций на самом деле обеспечивали размер блока не более 1 КБ с CRC-16, не реализуя «блок 0», продолжая использовать имя YMODEM. Результатом стал выпуск множества взаимонесовместимых реализаций YMODEM и использование названия YMODEM Batch для четкого обозначения тех версий, которые поддерживали полный стандарт.

Первоначальный протокол XMODEM был очень простым, и в этом причина его успеха; его можно было реализовать практически на любой машине того времени, даже с очень ограниченными процессорами и памятью. Он работал путем разбиения отправляемых данных на 128-байтовые пакеты , добавления 3-байтового заголовка и 1-байтового нижнего колонтитула контрольной суммы и отправки полученных 132-байтовых пакетов по порядку. Принимающий компьютер пересчитывал контрольную сумму из 128 байт данных и, если она совпадала с контрольной суммой, отправленной в нижнем колонтитуле, отправлял обратно сообщение. ACK , и если оно не совпало, НАК . Когда отправитель получил ACK отправил следующий пакет, а NAK заставил его повторно отправить последнее.

С протоколом возник ряд проблем. Использование простой контрольной суммы означало, что некоторые распространенные ошибки могли остаться незамеченными. Небольшой размер пакета и необходимость ожидания ПОДТВЕРЖДЕНИЕ или NAK приводил к снижению производительности на высокоскоростных каналах или каналах со значительной задержкой. Наконец, поскольку при передаче не содержалось никаких сведений о файле, каждый файл приходилось запускать вручную, что могло быть утомительным занятием, когда переносилось много небольших файлов.

Решения этих проблем были разработаны в начале 1980-х годов. XMODEM-CRC заменил контрольную сумму 16-битной циклической избыточной проверкой (CRC), которая была гораздо более устойчивой к распространенным ошибкам. XMODEM-1k увеличил размер пакета со 128 байт до 1024, улучшив производительность при высокоскоростных соединениях, в то время как другие, такие как WXMODEM и SEAlink, вместо этого представили системы скользящих окон для борьбы как с производительностью, так и с задержкой, ценой некоторой сложности. Третьи, такие как TeLink и MODEM7, добавили информацию о файлах, чтобы одна передача могла содержать несколько файлов, что позволяло отправлять пакеты файлов с помощью одной команды.

Чак Форсберг , автор CP/M «Еще одна модемная программа», или YAM, решил написать единый драйвер протокола, который поддерживал бы множество функций по сравнению с XMODEM, и назвал его YMODEM. Когда пользователи начинали передачу, они могли указать, какие параметры им нужны, в командной строке, например, заявив, что они хотят использовать CRC. Протокол был написан так, чтобы он мог использовать этот стиль, но изящно отступал, чтобы соответствовать возможностям удаленного программного обеспечения.

Прервать

[ редактировать ]

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

В некоторых реализациях была добавлена ​​возможность отправлять МОЖЕТ вместо ПОДТВЕРЖДЕНИЕ или NAK в конце полученного пакета, указывающий на прерывание. К сожалению, существовала вероятность того, что CAN может быть сгенерирован шумом в линии и вызвать прерывание. Таким образом, YAM немного изменил это, чтобы потребовать два CAN s back-to-back, что немедленно выполнит «мягкое прерывание» на стороне отправителя.

Поддержка CRC была введена в XMODEM-CRC. Это было очень простое изменение исходного протокола; по запросу получатель попытается инициировать передачу, отправив начальное сообщение. С вместо а НАК . Если бы удаленный отправитель поддерживал опцию CRC, он начал бы отправлять пакеты как обычно, но с 16-битной CRC в нижнем колонтитуле, а не с 1-байтовой контрольной суммой. YAM поддержал этот вариант без изменений.

Пакеты размером 1024 байта были представлены в XMODEM-1k. В этой версии триггерный символ получателя не менялся, поэтому у отправителя не было возможности узнать, поддерживает ли получатель пакеты большего размера. Вместо этого XMODEM-1k был представлен как отдельный протокол на обоих концах соединения. Когда такое соединение было установлено, отправитель мог выбрать отправку либо 1024 байт в пакете, либо 128 байт, указывая больший размер с помощью значка. Символ STX в заголовке, а не обычный СОХ . Обычно только последние несколько пакетов используют пакеты меньшего размера, чтобы избежать отправки большого количества дополнений. 1k также предполагал CRC для всех соединений. YAM поддерживал 1k без изменений.

Нулевой пакет

[ редактировать ]

Для поддержки автоматической передачи почты FidoNet в MODEM7 появилась возможность отправлять имя файла в виде обычного текста перед отправкой первого блока данных. Это было ненадежно, и TeLink улучшила ситуацию, поместив имя файла и, при необходимости, другие данные, такие как дата создания и длина файла, в полный 128-байтовый пакет. XMODEM начал передачу с пакета номер один, поэтому TeLink отправил этот пакет под номером ноль. Этот «нулевой пакет» или «нулевой блок» стал обычным явлением в других системах FidoNet, таких как SEAlink и других.

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

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

В результате YMODEM и YMODEM Batch часто рассматривались как два отдельных протокола. Дополнительную путаницу создавало сходство между XMODEM-1k и этими несовместимыми YMODEM, которые были похожи до такой степени, что их часто ошибочно обозначали как одно и то же.

Поддержка потоковой передачи

[ редактировать ]

YMODEM-G — это вариант потоковой передачи, используемый для безошибочных соединений. Он не ожидает ACK получения перед отправкой следующего пакета. Этот протокол быстрее, чем YMODEM, поскольку между пакетами не возникает задержек , но он не имеет возможности исправлять ошибки. Он зависит от отсутствия ошибок в базовом соединении, что характерно, например, для модемов, поддерживающих MNP .

Обычно передача YMODEM начинается с того, что получатель отправляет C, чтобы указать, что он хочет использовать 128-байтовый формат с CRC, или NAK , если он хочет использовать исходную систему контрольных сумм. Если требуется g-протокол, передача запускается путем отправки Г . Если отправитель не поддерживает g-протокол, он считает это ошибкой и игнорирует ее, но если он поддерживает g, он начинает отправлять пакеты непрерывным потоком. Он ожидает только одного ACK после получения последнего пакета, на что указывает наличие Символ EOT в данных. YMODEM-g предполагает, что доступно 1 тыс. пакетов.

Однако, несмотря на то, что этот протокол потенциально был быстрее, чем ZMODEM, он все еще использовался редко. Частично это было связано с отсутствием других функций, но это также и более серьезная проблема. До появления UART 16550 существовал существенный риск переполнения буфера последовательного порта . Хотя это будет обнаружено YMODEM-g, исправить это невозможно, поскольку повторная передача блока невозможна. Получателю придется отменить и перезапустить всю передачу с самого начала. ZMODEM , с другой стороны, имеет возможность возобновления передачи, что делает его более привлекательным.


Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 24eafc4caed6f08a011a1440c39e1627__1679741340
URL1:https://arc.ask3.ru/arc/aa/24/27/24eafc4caed6f08a011a1440c39e1627.html
Заголовок, (Title) документа по адресу, URL1:
YMODEM - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)