Кратко

  • Исходный FTP помещал метки возобновления в кадры блочного или сжатого режима, а ответ 110 MARK связывал позицию отправителя с локальным состоянием получателя после устойчивой записи.
  • Значения принадлежали разным системам и могли включать состояние преобразования. Получателю иногда требовалось помнить даже уже обработанный CR перед ещё не преобразованным LF.
  • RFC 3659 определил REST STREAM как число октетов, пропускаемых только в следующей передаче, но смещение не стало доказательством версии, правильности частичной копии или целостности результата.

Равенство обозначало встречу, а не одно число

FTP использует постоянное управляющее соединение для команд и нумерованных ответов, а содержимое файла переносит по отдельному соединению данных. Поэтому отчёт о восстановимой границе мог идти независимо от самого файла.

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

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

Отправитель не должен был ждать ответа 110. Спецификация запрещала считать ответы синхронными с потоком. Передача шла дальше, и последний надёжный checkpoint мог отставать от максимума индикатора прогресса. Наблюдавшееся движение и воспроизводимое состояние — разные доказательства.

Метке требовался режим с собственными границами

RFC 959 раздельно задаёт тип представления, структуру файла и режим передачи. STREAM передаёт последовательность и обычно обозначает EOF закрытием соединения данных. Документ отмечает слабость: одно закрытие не показывает, был ли это нормальный конец или преждевременный обрыв.

В блочном режиме у каждой единицы есть трёхоктетный заголовок: восемь бит дескриптора и шестнадцать бит длины. Значение дескриптора 16 означает блок с меткой возобновления. Внутри находится строка печатных символов без пробела — элемент представления FTP, а не пользовательский файл.

Это не номер последовательности TCP и не зарезервированный символ содержимого. Метка принадлежит прикладному протоколу. Блочный и сжатый режимы также умеют показать EOF без закрытия соединения, поэтому могли нести исходный механизм восстановления.

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

Сначала запись, потом обещание

Получив метку, реализация по RFC 1123 должна принудительно записать предшествующие данные в устойчивое хранилище и лишь затем кодировать rrrr. Токен означает не «прочитано сокетом», а «предыдущая часть переживёт сбой, для которого предназначено моё восстановление».

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

User-FTP тоже должен был сохранять пары. RFC 1123 предлагает создать пустой контрольный файл в начале, добавлять полные пары по мере ответов и удалить его после успеха. После падения последняя полная запись важнее самого большого временного счётчика.

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

Положение могло находиться посередине перевода строки

RFC 1123 приводит точный пример. TYPE ASCII переносит CRLF, а целевая система может сохранять один LF. Если метка попадает между CR и LF, получатель уже увидел и отбросил CR, но ещё не завершил локальное представление новой строки.

Тогда rrrr должен включать не только позицию файла, но и состояние «CR уже встречен». Возврат к одному смещению диска способен удвоить или потерять часть преобразования. Восстановимое положение складывается из координаты и памяти преобразователя.

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

Непрозрачность ограничивала полномочия. Отправитель понимал свой токен, получатель — свой, а протокол сохранял только установленное соответствие.

Направление определяло, кому вернуть значение

При загрузке от пользователя на сервер пользователь вставлял ssss. Сервер фиксировал префикс, создавал rrrr и сообщал пару. Для возобновления клиент восстанавливал своё состояние по ssss и передавал серверу REST rrrr.

При скачивании метку потока создавал сервер. Клиент делал частичную копию устойчивой и сохранял локальное состояние. Позднее он восстанавливался локально и возвращал серверу серверный токен.

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

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

REST готовил следующую операцию

Ответ 350 на REST не переносил данные. Сервер лишь сохранял параметр и ожидал команду передачи. Целостность, завершённость и новые байты ещё не были подтверждены.

В модели RFC 959 после REST идут RETR, STOR или в некоторых случаях APPE. RFC 1123 разделил ошибки: 554 для неприменимого положения и 555 для несовпадения TYPE или STRU с существующим файлом. Координата и представление могли оказаться несовместимыми независимо.

Между командами оставалось состояние. Если REST принят, а запланированная передача не отправлена, старая настройка могла попасть в следующую операцию. Поздняя спецификация STREAM сделала непосредственное соседство обязательным.

REST STREAM выбрал общую координату октетов

RFC 3659 описал возобновление в STREAM без вставки меток в поток данных. Аргумент REST стал десятичным числом: столько октетов не отправляет непосредственно следующая передача. REST 0 снимает эффект и возвращает полный файл.

Пример устанавливает TYPE I, проверяет, что серверный файл не изменился, отправляет REST 802816, получает 350 и сразу выполняет RETR. Для бинарного октетного потока это удобная общая координата.

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

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

Возобновление STOR давало смещению силу записи

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

RFC 3659 ограничивает такое использование завершением ранее оборванной передачи. Если маркер не находится в конце текущих серверных данных, результат не определён. То же верно, если продолжение не расширяет место назначения хотя бы до прежнего размера. APPE после REST, если разрешён, должен вести себя как STOR в выбранной позиции, а не просто дописывать в конец.

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

Умение применить позицию не предоставляет полномочие изменять объект.

Верное смещение могло принадлежать неверной версии

RFC 3659 рекомендует получить время модификации перед первым RETR и сравнить его перед продолжением. Для STOR клиент может сопоставить текущий источник с удалённым частичным файлом. Факты MLST способны дать более богатый сигнал.

Время не становится хэшем. Часы могут расходиться; отметка может измениться без окончательного различия содержимого; содержимое может измениться и вернуться. Это основание для инвалидирования, но не доказательство идентичности.

SIZE зависит от текущего TYPE и описывает размер передачи. Разные файлы бывают одинаковой длины. Достижение ожидаемого размера не доказывает, что префикс и суффикс относятся к одной версии.

Если целостность существенна, после продолжения нужно проверить весь объект. Успешные 350 и 226 подтверждают прохождение протокольного пути, но не равенство собранных данных источнику.

FEAT объявлял форму, а не состояние файла

Сервер с поведением RFC 3659 публикует точную строку REST STREAM в FEAT. Клиент отличает десятичное смещение от поддержки, доступной лишь в блочном или сжатом режиме.

Реестр IANA FTP Commands and Extensions отдельно сохраняет базовый REST и изменённый REST+ для STREAM. Реестр документирует стандартизованный словарь и класс соответствия, но не текущую распространённость или качество реализации.

FEAT отвечает, какую грамматику сервер заявляет. Он не отвечает, остался ли файл прежним, верна ли часть, разрешена ли запись и совпал ли итог.

Полномочие checkpoint оставалось уже полномочия файла

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

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

Экономия повторной передачи создаёт управляемое промежуточное состояние. Если offset переживает версию, которую описывал, удобство превращается в незаметное соединение разных эпох.

Источники и границы доказательств

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