Кратко

  • RFC 1440 позволял отправителю без учётной записи на целевом хосте передать не почтовый файл принимающему демону.
  • NULL ACK подтверждал одну команду, а EOF или закрытие соединения завершали поток, но не доказывали принятие или использование файла адресатом.
  • Удобство отправителя переносило на принимающую сторону решения о ёмкости, сроке хранения, аутентификации, карантине и запуске задания через псевдопользователя.

Передачу начинал не получатель

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

Источником идеи служили сети NJE, в том числе BITNET. Там файл можно было послать вне почтовой переписки. Автор сравнивал такую услугу с посылкой, а не письмом. Отправителю не требовалась регистрация на целевой машине, а получатель мог забрать объект позднее.

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

В одном соединении шли две сущности

Демон слушал TCP-порт 608. По одному сокету проходили текстовые команды ASCII и двоичные данные. RFC предлагал мыслить поток как сцепление управляющего файла и тела данных.

FILE сообщал отправителя, точный или приблизительный размер и необязательный билет аутентификации. USER выбирал локального пользователя или службу, TYPE — представление. Все три команды должны были предшествовать DATA. NAME и DATE добавляли описание. EOF закрывал файл, ABORT велел удалить недописанный объект, QUIT завершал работу.

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

Нулевой байт подтверждал только один шаг

Положительный ответ начинался с октета ноль. Такой NULL ACK принимал одну команду. Он не распространялся на весь обмен и не выражал волю адресата.

Размер FILE помогал ответить, достаточно ли места, но мог быть неточным. Сервер мог принять FILE, а затем отклонить USER из-за отсутствия имени. Он мог подтвердить метаданные и исчерпать место во время записи. Первое решение о допуске оставалось предварительным.

Сразу после соединения сервер отправлял приветствие с именем хоста, уровнем UFT и версией реализации. Оно синхронизировало стороны и сообщало совместимость. Удостоверенной личностью оно не было. Поле auth в FILE оставалось нереализованным, а документ прямо говорил, что аутентификация не обеспечена.

После сети начинался срок хранения

Принятый файл попадал в общую область, например /usr/spool/uft. Там он ждал, пока адресат примет или отклонит его, либо пока система не удалит его по возрасту. Общая область не означала неограниченный доступ. Размер и срок определяла местная администрация.

В результате возникали три времени: конец транспорта, период опеки хоста и момент решения пользователя. Соединение могло закрыться сегодня, файл — пролежать несколько дней, а пользователь — так и не появиться.

Удаление по сроку не было отказом адресата. Отсутствие объекта позднее также не доказывало использование: причиной могли стать очистка, карантин, сбой или отказ. Нужна отдельная запись о распоряжении с субъектом и временем.

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

Размер блока возвращал управление

В обычном режиме DATA содержал длину порции. Сервер читал ровно столько октетов, записывал их и возвращался к командам. Файл мог состоять из множества порций, соединение — переносить несколько файлов. После каждой порции снова появлялась точка для ACK или ABORT.

В быстром режиме длина отсутствовала. Приём продолжался до закрытия клиентом соединения; EOF и QUIT не посылались. Во время потока ABORT был невозможен. Граница данных совпадала с жизнью сокета.

Меньше обменов означало меньше контрольных точек. Преднамеренное окончание и неожиданный обрыв выглядели одинаково. Для вывода о полноте требовались заявленный и измеренный объём, хеш и причина закрытия; одного состояния TCP было недостаточно.

USER мог обозначать программу

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

Но существование имени не давало права на запуск. Личность отправителя, разрешение на подачу, проверка формата, лимит ресурсов, карантин, выполнение и результат оставались самостоятельными решениями. Синтаксически принятый USER не был полномочием.

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

При переносе через MIME менялась история наблюдений

Не все хосты имели прямой IP, хотели ещё один демон или находились за межсетевым экраном, пропускающим только почту. Поэтому UFT можно было вложить в MIME. Команды становились параметрами application/octet-stream, тело кодировалось Base64.

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

Протокол оставался Experimental. RFC 1499 сохранил это описание, а IANA и сейчас содержит имя sift-uft и порт 608. Регистрация доказывает наличие записи, но не развёртывание или популярность.

У каждого глагола свой владелец

RFC 1440 оставил последовательность: отправитель начинает, listener допускает, хост принимает байты, spool хранит, адресат принимает или отвергает, приложение может выполнить дальнейшее действие. Ранний этап не получает полномочий последнего.

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

Источники