Я БУДУ
 | Эта статья включает список литературы , связанную литературу или внешние ссылки , но ее источники остаются неясными, поскольку в ней отсутствуют встроенные цитаты . ( Май 2018 г. ) |
| Протокол связи | |
| Цель | протокол передачи файлов |
|---|---|
| Разработчик(и) | Чак Форсберг |
| Введение | 1986 год |
| Порт(ы) | Никто |
| Аппаратное обеспечение | модемы |
ZMODEM — это встроенный протокол передачи файлов, разработанный Чаком Форсбергом в 1986 году в рамках проекта, финансируемого Telenet, с целью улучшения передачи файлов в их X.25 сети . Помимо значительно улучшенной производительности по сравнению со старыми протоколами, ZMODEM предлагал перезапуск передачи, автоматический запуск отправителем, расширенную 32-битную CRC и кавычки управляющих символов, поддерживающие 8-битную чистую передачу, что позволяло использовать его в сетях, которые не передавать управляющие символы.
В отличие от большинства протоколов передачи, разработанных для систем досок объявлений (BBS), ZMODEM не был напрямую основан на оригинальном XMODEM и не был совместим с ним . Многие варианты XMODEM были разработаны для устранения одного или нескольких его недостатков, и большинство из них остались обратно совместимыми и могли успешно выполнять передачу с «классическими» реализациями XMODEM. Форсберга В этот список входит собственный YMODEM .
ZMODEM отказался от обратной совместимости в пользу создания радикально улучшенного протокола. Он работал так же хорошо или лучше, чем любой из высокопроизводительных вариантов XMODEM, делал это по каналам, которые раньше вообще не работали, например X.25, или имели плохую производительность, как модемы Telebit , и включал полезные функции, найденные в мало или вообще нет других протоколов. ZMODEM стал чрезвычайно популярным в системах досок объявлений (BBS) в начале 1990-х годов, став столь же распространенным стандартом, как и XMODEM до него.
Улучшения
[ редактировать ]Потоковое вещание
[ редактировать ]Обычно протоколы передачи файлов разбивают файл на серию пакетов , а затем отправляют их получателю по одному. Основная часть пакета, полезная нагрузка , представляет собой определенное количество байтов из отправляемого файла. После полезных данных идет контрольная сумма или проверка циклическим избыточным кодом (CRC), которую можно использовать для определения правильности получения полезных данных. Если пакет принят правильно, получатель отправляет сообщение ACK , и отправитель начинает отправку следующего пакета.
Телефонная система вносит небольшую задержку, известную как задержка , которая мешает этому процессу. Даже если получатель отправляет ACK немедленно, задержка в телефонных линиях означает, что всегда будет некоторое время, прежде чем отправитель получит его и отправит следующий пакет. По мере увеличения скорости модема эта задержка представляет собой все большее и большее количество пакетов, которые могли быть отправлены во время задержки, что снижает эффективность канала .
XMODEM использовал 128-байтовые полезные данные с трехбайтовым заголовком и однобайтовой контрольной суммой, всего 132 байта на пакет. В эпоху модемов со скоростью 300 бит/с отправка пакета занимала около четырех секунд, а типичные задержки были порядка 1/10 секунды , поэтому потери производительности были незначительными. По мере увеличения скорости проблема становится более проблематичной; при скорости 2400 бит/с пакет занимает около 1 ⁄ 2 на отправку, так примерно 1/5 пропускной способности доступной тратится впустую в ожидании АКК с. При скорости 9600 бит/с для отправки пакета требуется всего 0,13 секунды, т. е. примерно 1/2 пропускания полосы тратится впустую.
Одним из решений этой проблемы является использование раздвижного окна . Эти протоколы устраняют задержку, позволяя отправителю продолжать отправку определенного количества пакетов, не дожидаясь ответа. ПОДТВЕРЖДЕНИЕ . Количество пакетов, которые он позволяет продолжить, представляет собой «окно», которое в большинстве реализаций обычно составляло от двух до шестнадцати пакетов. В начале 1980-х годов появилось несколько новых версий XMODEM с поддержкой скользящих окон.
Скользящие окна полезны при задержках порядка нескольких длин пакетов, что характерно для XMODEM на обычных телефонных линиях. Однако этого недостаточно для устранения более длительных задержек, возникающих при телефонных звонках за границу, спутниковых соединениях или службах X.25, таких как PC Pursuit , где задержки составляют порядка секунды или больше. В других случаях, когда обратный канал был намного медленнее передающего, как это было в случае с модемами Telebit или US Robotics , даже небольшое количество ACK может перегрузить обратный канал и привести к приостановке передачи.
ZMODEM решил эти проблемы, устранив необходимость в ACK вообще позволяет отправителю отправлять данные непрерывно, пока получатель не обнаружил ошибок. Только NAK нужно было отправлять тогда и только тогда, когда возникала проблема. Поскольку ZMODEM часто использовался на каналах со встроенной коррекцией ошибок, таких как X.25, получатель часто не отправлял отправителю ни одного сообщения. В результате система отправляла весь файл непрерывным потоком, а ZMODEM называл себя «протоколом потоковой передачи».
Производительность ZMODEM была настолько улучшена по сравнению с предыдущими распространенными протоколами, что он обычно заменял даже специальные протоколы, такие как YMODEM-g , которые вообще не включали исправление ошибок и вместо этого полагались на безошибочные каналы, поддерживаемые модемами. Хотя YMODEM-g был быстрее (и, следовательно, популярен среди «опытных пользователей»), отсутствие других функций, таких как возможность перезапуска передачи, сделало его менее привлекательным.
Перезапуск
[ редактировать ]XMODEM и большинство основанных на нем протоколов управляли порядком пакетов, добавляя к данным префикс номера пакета от 1 до 255. Оконные версии использовали этот номер пакета, чтобы указать, какие пакеты были получены правильно, или указать тот, который не был получен. Поскольку длина пакетов составляла 128 байт, это означало, что максимальный объем данных, который можно было передать до смены номеров пакетов, составлял 32 КБ.
ZMODEM заменил номер пакета фактическим местоположением в файле, обозначенным 32-битным числом. Это позволило ему отправить Сообщения NAK , которые повторно завершают передачу до точки сбоя, независимо от того, какой длины может быть файл. Эта же функция также использовалась для повторного запуска передачи, если она не удалась или была намеренно прервана. В этом случае получатель будет проверять, сколько данных было получено ранее, а затем отправлять сообщение. NAK с этим местоположением, автоматически заставляя отправителя начать с этой точки.
Автозапуск
[ редактировать ]Автоматический запуск упрощает управление, позволяя отправителю начать передачу. Раньше пользователю приходилось сначала запрашивать файл у отправителя, переводя его в состояние «ожидания», затем возвращаться в свою локальную программу и вызывать команду для начала передачи. При автоматической передаче они просто запрашивали файл, а отправитель автоматически запускал передачу в программе пользователя.
Вариации
[ редактировать ]Появился ряд модифицированных версий ZMODEM. ZedZap представлял собой вариант ZMODEM с блоками по 8 Кбайт для лучшей производительности на высокоскоростных модемах. LeechZmodem был озорным вариантом ZMODEM (среди аналогичных производных XMODEM и YMODEM), который обманывал квоты загрузки BBS . Обратно совместимое расширение ZMODEM с длиной блоков 32 и 64 кбайт было создано ADONTEC в 2002 и 2007 годах для повышения производительности высокоскоростных безошибочных соединений, таких как сети ISDN или TCP/IP.
Наиболее известные реализации ZMODEM были разработаны компанией Omen Technology, Inc. Чака Форсберга. К ним относятся DSZ (DOS Send ZMODEM), GSZ (Graphical Send ZMODEM) и вездесущий (l)rzsz для вариантов Unix.
В настоящее время разработчики Synchronet создали современную реализацию X/Y/ZMODEM под названием SEXYZ, основанную на пакете zmtx/zmrx, который изначально работает в вариантах Windows и Unix, поддерживает длинные имена файлов и более быструю и надежную передачу данных. . Реализация ZMODEM от SEXYZ также была включена в проект SyncTERM. Synchronet, SEXYZ и SyncTERM — это кроссплатформенные проекты с открытым исходным кодом, ориентированные на BBS.
Сам Форсберг собрал в ZMODEM-90 ряд усовершенствований. Первым из них является MobyTurbo, в котором удалено контрольное квотирование для дальнейшего повышения производительности примерно на 15%. Даже в сетях, которые «поедают» управляющие символы, ZMODEM-90 можно настроить так, чтобы цитировать только те символы, которые действительно потребляются сетью, а не все возможные. Подобное улучшение позволяет ZMODEM-90 работать в 7-битных сетях, тогда как более ранние протоколы (за заметным исключением Kermit ) в той или иной степени требовали 8-бит. Наконец, ZMODEM-90 включает в себя базовую систему сжатия с кодированием по длине для дальнейшего повышения производительности при работе с несжатыми файлами.
Ограничения
[ редактировать ]- Некоторые пакеты ZMODEM (например, ZACK, ZRPOS) включают в передаваемый файл смещение байтов в виде 32-битного целого числа без знака. Такая конструкция ограничивает возможность ZMODEM надежно передавать только файлы размером менее 4 ГБ.
- Несмотря на то, что протокол может это разрешать, эталонная реализация (l)rzsz не может кодировать произвольные неуправляющие символы (например, «~»), которые часто используются программами подключения TCP/IP, такими как telnet и ssh, в качестве «экранирования терминала» на стороне клиента. персонажи. Пользователи должны отключить функцию выхода терминала, чтобы обеспечить надежную передачу по таким типам ссылок, например ssh -e none user@hostname.
Ссылки
[ редактировать ]- Протокол передачи файлов между приложениями ZMODEM
- Драйвер протокола передачи файлов Synchronet внешнего X/Y/Zmodem (SEXYZ)