Кратко

  • XMODEM требовал общего понимания только для 128 байт данных, номера блока и его дополнения, простой контрольной суммы, ответов ACK/NAK под управлением приёмника и явного завершения. Соединение, диск и экран оставались вне протокола.
  • Небольшая граница удешевляла независимые реализации и их взаимную проверку. Слабый контроль ошибок, ожидание после каждого блока и отсутствие метаданных не исчезали, зато оставались видимыми и могли исправляться преемниками без превращения совместимости в собственность одного сервиса.

Разговор, который начинает получатель

В XMODEM первый служебный знак отправляет не тот, у кого есть файл. Приёмник после ожидания выдаёт NAK: он готов. Передатчик отвечает последовательностью SOH, номер блока, единичное дополнение номера, 128 байт данных и контрольная сумма. Приёмник повторяет вычисление и возвращает ACK при успехе либо NAK с требованием повторить.

Номер начинается с единицы и растёт. Дополнение помогает заметить повреждение заголовка. Контрольная сумма складывает байты данных, отбрасывая перенос. После последнего блока отправитель выдаёт EOT и ждёт финального подтверждения.

В этой схеме нет телефонного номера, имени файла, каталога, учётной записи, тарифа и индикатора выполнения. Протокол вступает в действие после появления соединения и заканчивается задолго до полного пользовательского продукта. Он определяет только то, что две программы обязаны одинаково понимать на линии.

Размер 128 байт происходил из конкретной среды — сектора дискеты CP/M, с которой работал Кристенсен. Постоянная длина упрощала буферы и код на малых компьютерах. Одновременно последний короткий блок приходилось дополнять, а точный размер файла исходный формат сам не сообщал.

Повторный блок как след потерянного ACK

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

Увидев предыдущий номер, он вновь подтверждает приём, однако не записывает те же данные второй раз. Любой иной неожиданный номер уже указывает на более серьёзную потерю синхронизации и может завершить обмен.

Для разрешения ограниченной неопределённости достаточно локальной памяти о прошлом состоянии. Центральный журнал не назначает правильную копию. Оба конца применяют одно решение к одному номеру. Надёжность здесь означает не отсутствие шума, а согласованную реакцию на конкретный сбой.

Позже Кристенсен называл работу 1977 года импровизацией для личной задачи. По его словам, ранняя готовность и немедленная передача в общественное достояние помогли протоколу стать стандартом. Это ретроспективное свидетельство автора, а не доказательство единственной причины успеха. Однако экономика реализации понятна: короткую программу можно было скопировать, изучить, перенести на другую машину и проверить с независимым партнёром без разрешения владельца сети.

RFC зафиксировал уже сложившуюся практику

Называть XMODEM стандартом, разработанным IETF, неверно. RFC 916 в 1984 году предлагал иной надёжный протокол для асинхронной связи, а MODEM/XMODEM поместил в приложение как уже распространённую среди микрокомпьютеров практику. Сначала возникло множество реализаций, затем их поведение попало в RFC.

Документ заодно перечислил ограничения. Поток данных шёл в одну сторону, пакет оставался фиксированным на 128 октетах, а отдельные концентраторы плохо справлялись даже с меньшими непрерывными порциями. Ожидание ACK после каждого блока сильнее снижает пропускную способность при большом времени кругового пути. Простая восьмибитная сумма пропускает некоторые искажения.

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

Расширение должно было встретить реального партнёра

В последующих соглашениях появились CRC-16, дополнительные блоки на 1K и нулевой блок с именем и размером файла. Свободно распространявшиеся программы Чака Форсберга помогли этим возможностям закрепиться под названиями вроде YMODEM. Узнаваемый базовый обмен позволял добавлять функции поэтапно.

Кристенсен сопротивлялся превращению самого ядра в полнодуплексную систему с несколькими неподтверждёнными блоками или множеством адресатов. Он не отрицал ценность более богатой передачи. Его довод касался долговечности: крайней простотой объяснялось присутствие протокола на стольких машинах и в стольких программах. Новшество, одномоментно объявляющее все старые конечные системы неправильными, меняет и распределение власти над общей основой.

Добровольное внедрение не гарантировало порядка. Исторические справочники предупреждали: продукты с одинаковым именем YMODEM могли вести себя несовместимо. Название не служило доказательством. Требовалась последовательность из предложения, работающего кода, тестовых файлов, ограниченного развёртывания, наблюдения сбоев, меток возможностей и честной документации.

CBBS был местом, XMODEM — переходом

После чикагской метели 1978 года Кристенсен совместно с Рэнди Сюссом создал CBBS: Сюсс отвечал за аппаратуру, Кристенсен — за программу. Система принимала звонки, сохраняла сообщения и создавала место, куда возвращались люди. Это важный социальный контекст, но не часть формата блока XMODEM.

BBS был сервисом, а XMODEM — узким проходом для файла. Благодаря разделению разные доски объявлений, терминальные программы и местные процессы могли добавить передачу, не становясь клиентами единой платформы. Общей оставалась линия, а не весь продукт.

Наследие не требует навсегда сохранить число 128. Оно предлагает способ провести границу: строго закрепить поведение там, где совместимость нуждается в совпадении, и оставить решение местным там, где совпадение не нужно. Конечные системы подчинялись порядку, проверке и завершению, но не обязаны были быть одинаковыми во всём остальном.

Источники