Кратко

  • Получить файл — не то же самое, что попросить другой компьютер запустить программу. В первом случае передают данные; во втором поручают узлу работу.
  • RFC 114 включал оба действия в ограниченный файловый протокол. RFC 171 и RFC 172 позднее отделили общий перенос данных от команд FTP; стандартной процедуры удалённого выполнения не появилось.

Получить файл от другого компьютера — одно. Попросить его запустить программу — другое. Теперь удалённый узел должен выполнить работу. В 1971 году авторы протоколов решали, должен ли один стандарт охватывать оба действия. Их выбор провёл границу между передачей данных и заданием для другого компьютера. RFC 114 показывает один подход, а последующие документы — другой. Это понятная и сегодня инженерная задача, но не утверждение о прямом происхождении современных сервисов от этих RFC.

В RFC 114 файл мог содержать инструкции, данные или и то и другое. Поэтому execute стоял рядом с получением и сохранением файлов. Это была ограниченная транзакция, а не универсальная удалённая оболочка. В заголовке RFC 114 стоит дата 16 апреля 1971 года, а каталог RFC Editor указывает 1 апреля. Документ описывает транзакции, с помощью которых взаимодействующие процессы могли пользоваться файловой системой другого узла.

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

Предполагалась конкретная, но ограниченная среда. RFC 114 сообщает, что протокол разрабатывался для немедленной реализации на двух узлах MIT — GE 645/Multics и PDP-10/DM/CG-ITS, возможно также на узле Гарварда. Промежуточная версия с ограниченными возможностями проходила отладку. Это свидетельствует об отдельной работе по реализации, но не доказывает, что работали все перечисленные транзакции или что протокол распространился по сети.

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

Сопутствующий RFC 172 использовал общий DTP для переноса данных, а файловые операции определял на уровне приложения. Узлам разрешалось реализовать лишь часть команд. В документе также сказано, что FTP можно расширить для удалённого выполнения программ, но стандартная процедура не предложена. Возможность оставалась, однако в стандартный порядок действий FTP она не вошла.

В комментариях RFC 141 практические вопросы названы прямо: локальный доступ к файлам, подмножества команд и возможное долгое ожидание при выполнении задания. Вместе с разрешением RFC 172 реализовывать лишь часть команд они показывают, сколько решений прикладной протокол оставлял отдельным узлам.

Аргумент RFC 171 в пользу общего DTP был отчасти попыткой сдержать размножение протоколов: несколько приложений могли использовать один механизм передачи вместо того, чтобы каждый раз определять свой. Подмножества команд в RFC 172 показывают цену такого решения. Транспорт можно было повторно использовать, но набор прикладных команд различался между узлами, а стандартной FTP-процедуры удалённого выполнения не появилось. Архитектура сокращала дублирование, но не делала поведение всех узлов одинаковым. RFC 114 при этом свидетельствует об ограниченной работе над реализацией, а не о широком использовании execute.

Источники