ZMODEM: Протокол передачи файлов нового поколения

Введение

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

ZMODEM — это протокол передачи файлов, разработанный Чаком Форсбергом в 1986 году в рамках проекта, финансируемого компанией Telenet, для повышения эффективности передачи файлов в их сети X.25. Помимо значительно улучшенной производительности по сравнению со старыми протоколами, ZMODEM обеспечивал возобновляемые передачи, автоматический запуск передатчиком, расширенный 32-битный CRC и экранирование управляющих символов, поддерживающее чистую 8-битную передачу, что позволяло использовать его в сетях, которые не пропускали управляющие символы. В отличие от большинства протоколов передачи, разработанных для систем электронных досок объявлений (BBS), ZMODEM не был напрямую основан на XMODEM и не был с ним совместим. Было разработано множество вариантов XMODEM для устранения одного или нескольких его недостатков, и большинство из них сохраняли обратную совместимость и успешно завершали передачу с «классическими» реализациями XMODEM. В этот список входит YMODEM, также разработанный Форсбергом. ZMODEM отказался от обратной совместимости ради создания принципиально улучшенного протокола. Он работал так же хорошо или лучше, чем любые высокопроизводительные варианты XMODEM, обеспечивал работу по каналам, которые ранее не работали вообще, например X.25, или имели низкую производительность, например модемы Telebit, и включал полезные функции, которые редко встречались в других протоколах. В начале 1990-х годов ZMODEM стал чрезвычайно популярным в системах BBS, став стандартом, столь же распространенным, как XMODEM до него.

Потоковое вещание

Как правило, протоколы передачи файлов разбивают файл на серию пакетов, а затем отправляют их по одному получателю. Основная часть пакета, полезная нагрузка, представляет собой определенное количество байтов из передаваемого файла. За полезной нагрузкой следует контрольная сумма или циклическая проверка избыточности (CRC), которая может быть использована для определения, была ли полезная нагрузка получена правильно. Если пакет получен правильно, получатель отправляет подтверждение, а отправитель начинает отправлять следующий пакет. Телефонная система вносит небольшую задержку, известную как латентность, которая мешает этому процессу. Даже если получатель отправляет подтверждение немедленно, задержка в телефонных линиях означает, что всегда будет некоторое время, прежде чем отправитель получит его и отправит следующий пакет. По мере увеличения скорости модема эта задержка представляет собой все большее и большее количество пакетов, которые могли быть отправлены во время задержки, снижая эффективность канала. 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, даже небольшое количество подтверждений могло перегрузить обратный канал и приостановить передачу. ZMODEM решил эти проблемы, устранив необходимость в подтверждениях вообще, позволяя отправителю отправлять данные непрерывно, пока получатель не обнаружит ошибок. Подтверждения требовалось отправлять только в случае возникновения проблемы. Поскольку ZMODEM часто использовался на каналах со встроенной коррекцией ошибок, таких как X.25, получатель часто не отправлял никаких сообщений отправителю. В результате система отправляла весь файл непрерывным потоком, и ZMODEM называл себя "потоковым протоколом". Производительность ZMODEM была значительно улучшена по сравнению с предыдущими распространенными протоколами, что привело к его замене даже специализированных протоколов, таких как YMODEM g, которые не включали коррекцию ошибок и полагались на безошибочные соединения, поддерживаемые модемами. Хотя YMODEM g был быстрее (и, следовательно, популярен среди опытных пользователей), отсутствие других функций, таких как возможность возобновления передачи, делало его менее привлекательным.

Generally, file transfer protocols break down a file into a series of packets, and then send them one at a time to the receiver. The main portion of the packet, the payload, is a certain number of bytes from the file being sent. After the payload comes a checksum or cyclic redundancy check (CRC) that can be used to determine if the payload was received correctly. If the packet is received correctly, the receiver sends an message and the sender then starts sending the next packet. The telephone system introduces a small delay known as latency that interferes with this process. Even if the receiver sends the immediately, the delay in the phone lines means there will always be some time before the sender receives it and sends the next packet. As modem speeds increase, this delay represents a larger and larger number of packets that could have been sent during the delay, decreasing the channel efficiency. XMODEM used 128 byte payloads with a three byte header and one byte checksum for a total of 132 bytes per packet. In the era of 300 bit/s modems, a packet took about four seconds to send, and typical latencies were on the order of 1/10 of a second, so the performance overhead was not significant. As speeds increase the problem becomes more problematic; at 2400 bit/s a packet takes about 1/2 to send, so about 1/5 of the available bandwidth is wasted waiting for s. At 9600 bit/s a packet requires only 0.13 seconds to send, so about 1/2 of the bandwidth is wasted. One solution to this problem is the use of a sliding window. These protocols address latency by allowing the sender to continue sending a number of packets without waiting for an The number of packets that it allows to continue is the "window", which was typically between two and sixteen packets in most implementations. A number of new versions of XMODEM with sliding window support appeared in the early 1980s. Sliding windows are useful for latencies on the order of several packet lengths, which is the case for XMODEM on conventional phone lines. However, it is not enough to address longer latencies found on overseas phone calls, satellite connections, or X.25 services such as PC Pursuit, where the latencies are on the order of a second or longer. In other cases, where the reverse channel was much slower than the sending one, as was the case for Telebit or US Robotics modems, even the small number of s might overwhelm the return channel and cause the transfer to pause. ZMODEM addressed these problems by removing the need for s at all, allowing the sender to send data continually as long as the receiver detected no errors. Only s had to be sent, if and only if there was a problem. Since ZMODEM was often used on links with built in error correction, like X.25, the receiver would often not send a single message back to the sender. As a result, the system would send the entire file in a continual stream, and ZMODEM referred to itself as a "streaming protocol". ZMODEM's performance was so improved over previous common protocols that it generally replaced even special protocols such as YMODEM g, which included no error correction at all and instead relied on error free links maintained by the modems. Although YMODEM g was faster (and thus popular among "power users"), the lack of other features such as restartable transfers made it less appealing.

Перезагрузить

XMODEM и большинство протоколов, основанных на нем, управляли порядком пакетов, добавляя к данным номер пакета от 1 до 255. В версиях с использованием окна этот номер пакета использовался для указания, какие пакеты были получены успешно, или для обозначения тех, которые не были получены. Поскольку пакеты имели длину 128 байт, это означало, что максимальный объем данных, который можно было передать до повторения номеров пакетов, составлял 32 кБ. ZMODEM заменил номер пакета на фактическое положение в файле, указанное 32-битовым числом. Это позволило ему отправлять сообщения, которые возвращали передачу к точке сбоя, независимо от размера файла. Эта же функция использовалась и для возобновления передачи в случае сбоя или преднамеренного прерывания. В этом случае приемник определял, какой объем данных был получен ранее, и отправлял сообщение с указанием этого положения, автоматически запуская передатчик для начала с этой точки.

Автоматический запуск

Автоматический запуск упрощает управление, позволяя отправляющему компьютеру начать передачу. Раньше пользователю сначала нужно было запросить файл у отправителя, переводя его в состояние "ожидания", затем вернуться в свою локальную программу и выполнить команду для запуска передачи. С автоматической передачей пользователь просто запрашивает файл, после чего отправитель автоматически инициирует передачу в программе пользователя.

Вариации

Появилось несколько модифицированных версий ZMODEM. ZedZap был вариантом ZMODEM с блоками по 8 кбайт для повышения производительности на высокоскоростных модемах. LeechZmodem был вредоносным вариантом ZMODEM (вместе с похожими производными XMODEM и YMODEM), который обходил ограничения на скачивание в BBS. В 2002 и 2007 годах компания ADONTEC создала обратно совместимое расширение ZMODEM с блоками длиной 32 и 64 кбайт для увеличения производительности на высокоскоростных соединениях без ошибок, таких как ISDN или сети TCP/IP. Наиболее известными реализациями ZMODEM были разработки компании Chuck Forsberg's 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 ГБ. Несмотря на то, что протокол теоретически допускает это, эталонная реализация lrzsz не может кодировать произвольные символы управления, отличные от управляющих (например, '~'), которые часто используются программами TCP/IP-соединения, такими как telnet и ssh, в качестве символов "экранирования терминала" на стороне клиента. Пользователям необходимо отключить функцию экранирования терминала для обеспечения надёжной передачи данных по таким соединениям, например, ssh -e none user@hostname.