Кратко

  • Ранний механизм связывал позицию отправителя с позицией получателя и сохранял необходимые сведения о записи и преобразовании данных.
  • В REST STREAM меткой стало число октетов, пропускаемых в следующей передаче. Такая координата принадлежит представлению, но не идентифицирует версию файла.
  • В примере RFC 3659 неизменность серверного файла проверяется до продолжения. Команда REST сама этого не устанавливает.

Принятая позиция не подтверждает происхождение

Загрузка оборвалась после 802816 октетов. Клиент соединяется снова, выбирает TYPE I, отправляет REST 802816, получает 350 и затем выполняет RETR. Сервер начинает с нужного места.

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

Когда у каждой стороны была своя координата

RFC 765 уже относил restart к восстановлению после сбоя. REST не передавал данные, а устанавливал серверную позицию перед немедленно следующим прерванным сервисным действием.

Непрозрачная метка соответствовала гетерогенной среде. Логический байт файла отличался от восьмибитного передаваемого октета; TYPE задавал представление, STRU — структуру, MODE — оформление потока. Разные размеры машинного слова, кодировки и записи не позволяли считать дисковый индекс универсальным.

RFC 959 сохранил режимы Stream, Block и Compressed. В форматированных Block и Compressed специальные блоки меток отличались от полезных данных. Отправитель создавал состояние, которое мог позже понять, а получатель сопоставлял его со своей сохраненной позицией. Общим было соответствие, не формат координат.

Устойчивое хранение и память преобразователя

RFC 1123 исправил описание ответа 110: ssss кодирует положение у отправителя, rrrr — соответствующее положение у получателя. Строки могли оставаться локальными, поскольку возвращались системе, которая их породила.

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

Иногда требовалось сохранить и состояние преобразования. При TYPE A последовательность CR LF из сети может стать одним LF на диске. Если метка оказалась между CR и LF, получатель должен помнить, что CR уже увиден и отброшен. Обычное файловое смещение такой информации не несет.

Поэтому RFC 1123 ввел 554 для неприменимой позиции и 555 для несовпадения TYPE или STRU с частично записанным файлом. Правильный синтаксис метки не гарантирует правильный контекст.

STREAM заменил непрозрачность счетчиком

Старый механизм был точен, но сложен. В 1989 году RFC 1123 называл Restart, ABOR и Block mode полезными, однако не широко реализованными средствами надежности и не включал REST в минимальный набор. Это историческое наблюдение, а не современная статистика.

В режиме Stream явную метку невозможно отличить от содержимого. RFC 3659 стандартизовал иное правило: десятичное значение REST STREAM определяет, сколько октетов не будет отправлено в начале следующей передачи.

Поддержка обнаруживается через FEAT, определенный RFC 2389. Строка REST STREAM подтверждает способность сервера, но не неизменность объекта по выбранному пути.

Счетчик все равно зависит от представления. Один текст в RFC 3659 имеет SIZE 1830 при TYPE I и 1942 при TYPE A из-за преобразования концов строк. Смещение относится к создаваемому сетевому потоку и не обязано совпадать с нативной позицией в хранилище.

При возобновлении отправки клиенту нужно узнать, сколько сервер действительно получил и сохранил. SIZE дает длину в текущем представлении, но не хеш уже лежащего префикса.

Условие, явно названное стандартом

Перед примером REST 802816 RFC 3659 указывает, что прежняя передача шла с TYPE I и что файл на сервере проверен как неизменившийся. Следовательно, тождество версии поступает не из числа.

При RETR клиент отвечает за соединение нового хвоста со своим фрагментом. При STOR сервер вставляет данные в существующий объект. Результат не определен, если операция не завершает прежнюю неудачную передачу, метка стоит не в конце сохраненных данных или новый хвост не восстанавливает хотя бы прежнюю длину. Разрешенный APPE после REST обязан действовать как STOR с выбранной позиции.

350 оставляет действие незавершенным

REST должен быть последней командой перед передачей. Сервер может принять число ответом 350, а невозможность позиционирования обнаружить лишь при RETR или STOR. Если следующая команда не ушла, клиенту следует повторить REST, а не полагаться на сохранение старого состояния.

Полный checkpoint распределен между фрагментом, параметрами, возможностями, устойчивой записью, меткой, порядком команд и внешней проверкой версии. Один offset — лишь заметная часть этого договора.

Границы источников

RFC 765 описывает исходный механизм, RFC 959 — режимы, RFC 1123 — парные позиции и устойчивую запись, RFC 2389 — обнаружение, RFC 3659 — STREAM и SIZE. Они не измеряют нынешнее развертывание и не обещают сохранение версий. FTP restart не является аутентификацией, хешем, снимком или доставкой exactly once.