Кратко

  • RFC 1068 помещала параметры FTP-операции в постоянную очередь на управляющем узле. Демон FTC позднее устанавливал соединения с двумя серверами и возобновлял попытки. Команда submit сохраняла запрос, но не подтверждала перемещение данных.
  • Для нескольких файлов первый успешный NLST фиксировал состав набора, а указатель запоминал уже выполненные элементы. Запрос считался завершённым и при постоянной ошибке или исчерпании повторов, поэтому истинный результат находился в отчёте по каждому файлу.

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

BFTP перенёс эту обязанность в сохранённое состояние. Интерфейс собирал описание операции, а file transfer control daemon, FTC, исполнял её позже. Документ предназначался для обсуждения и не вводил нового протокола. Он добавлял вокруг существующего FTP очередь, расписание, повторы, частичный прогресс и уведомление.

В очереди находилась инструкция для будущего

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

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

Команда verify уменьшала лишь текущую неопределённость. Когда серверы были доступны, BFTP мог войти на них, проверить параметры и найти исходный файл. Недоступный узел оставлял часть проверок невыполненной. Даже удачная проверка происходила до отдельного submit и будущей передачи. Это было наблюдение момента, а не резервирование будущей связности, прав или состояния диска.

Управляющий узел не находился на пути файла

BFTP использовал передачу между серверами из RFC 959. FTC открывал по управляющему соединению к источнику и назначению. На одной стороне он запрашивал PASV, передавал адрес и порт другой стороне командой PORT, затем сочетал RETR и STOR. Канал данных соединял FTP-серверы напрямую; байты обходили компьютер с очередью.

Поэтому следы имели разный смысл. Очередь описывала желаемое действие. Два управляющих диалога показывали принятые и отвергнутые команды. Содержимое шло по третьему соединению. RFC 959 требовала сохранять управляющие каналы во время передачи и дождаться окончательного ответа 226 или 250 перед следующей командой. Предварительный ответ, установление сокета или закрытие канала данных сами по себе ещё не определяли судьбу файла.

Составная система зависела от несовпадающих реализаций. Хотя бы один сервер должен был поддерживать PASV. RFC 1068 отмечает нестандартный вывод NLST, неправильно оформленные ответы и серверы, которые сообщали об обрыве как о постоянном 5xx, а не временном 4xx. Планировщик повторов не может надёжно решить больше, чем позволяет словарь ошибок его зависимостей.

Повтор жил над несколькими FTP-сеансами

После временной ошибки FTC делал запись, выжидал и создавал новые соединения. В примере реализация начинала примерно с десяти минут, удваивала паузу и переставала увеличивать её около четырёх часов. Это местная политика, а не заданные для Интернета интервалы.

Семейства ответов 4yz и 5yz из RFC 959 управляли будущим задания. 4yz означало, что действие не выполнено, но тот же запрос можно повторить. 5yz не советовало делать ещё одну неизменённую попытку. Если обрыв ошибочно становился постоянной ошибкой, восстановимое задание лишалось следующего шанса. Обратная ошибка сохраняла бесперспективную работу.

Терпение имело предел: успех, постоянная ошибка или максимальное число попыток завершали цикл. Затем демон отправлял письмо. Письмо доказывало наступление конечного состояния процесса, но не само успешное получение. Для этого требовалось прочитать содержание отчёта.

Первый удачный список закреплял временную границу

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

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

Слово «complete» поэтому имело особый смысл. RFC 1068 называла запрос завершённым при успехе всех элементов, постоянной ошибке или исчерпании попыток. Завершение означало, что демон больше ничего не планирует. Оно не означало наличия всех копий в назначении. Итоговое письмо перечисляло файлы отдельно именно потому, что общий статус не раскрывал исход.

Ключевое слово помогало искать, но не удостоверяло личность

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

У выбора стороннего адресата позднее проявилась и другая граница. RFC 2577 объяснила, как PORT в proxy FTP позволял заставить сервер соединиться с иной службой — FTP bounce — и почему ограничения могли удалить саму proxy-функцию. Это не свидетельство инцидента BFTP. Это свидетельство того, что контроллер обладал значимым правом выбирать цель, даже не передавая байты через себя.

Исторический вывод имеет пределы

RFC 1068 описывает несколько месяцев использования в ISI, а не широкое распространение. Она не доказывает прямое происхождение современных очередей заданий. RFC 959 задаёт разделение управления и данных и смысл ответов; RFC 2577 добавляет более позднюю границу безопасности. Ни один источник не подтверждает конкретную успешную передачу, безопасность паролей или действующее сегодня развёртывание.

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