Кратко

  • STRU P представляла прерывистые файлы как независимые индексированные страницы; Page Index обозначал логическое место, а не порядок передачи.
  • Пустые позиции таблицы не отправлялись. Существующая страница с нулевыми значениями оставалась данными; RFC 959 прямо отделяла дыру от страницы нулей.
  • Механизм возник главным образом для TOPS-20 и NLS. RFC 1123 не рекомендовала его повсеместно, но потребовала общего формата там, где случайный доступ или дырявые файлы действительно были нужны.

Отсутствие с точным адресом

RFC 959 определила Page Structure для прерывистых, random-access или «holey» файлов. Каждая переданная страница содержала Page Index — логический номер в файле, а не порядковый номер прохождения соединения.

Поэтому две соседние единицы передачи могли оставить между собой незанятое место в итоговой карте. Приложение о TOPS-20 говорит недвусмысленно: пустые страницы, дыры, просто не отправлялись; дыра не была страницей нулей.

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

Структура была отдельна от представления

FTP разделял TYPE, STRU и MODE. Первый задавал логическое представление, второй — организацию файла, третий — передачу по каналу данных.

File Structure по умолчанию считала файл непрерывной последовательностью байтов. Record Structure сохраняла последовательные записи. Page Structure сохраняла независимо индексируемые страницы.

Причиной были разные хосты. RFC 959 сопоставляет фиксированные записи исходного кода на IBM-мейнфрейме и символьный поток на TOPS-20. Без объявления структуры приёмник не мог отличить границы источника от своей локальной переработки.

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

Следовательно, доказательство передачи включает активные параметры, а не только полезную нагрузку.

Тип страницы объяснял нулевую длину

Минимальный заголовок содержал Header Length, Page Index, Data Length и Page Type. Каждый был логическим байтом ширины, заданной TYPE.

Page Type не позволял приписать нулевой длине один смысл. Last Page завершала передачу минимальным заголовком без данных. Simple Page несла обычные данные. Descriptor Page описывала файл в целом. Access Controlled Page добавляла связанное со страницей поле управления.

Не появившийся индекс мог быть дырой. Появившийся заголовок с нулём данных мог быть явным концом. Страница описания относилась ко всему файлу. Интерпретация зависела от сочетания признаков.

Логическое размещение также не совпадало с прибытием. Сортировка по времени получения вместо Page Index могла создать другой файл при полном наборе байтов.

Конкретный источник механизма

RFC 765 и RFC 959 связывают Page Structure прежде всего с эффективным обменом между TOPS-20, особенно файлами NLS.

Дисковый файл TOPS-20 включал pathname, таблицу страниц, возможно пустое множество страниц и атрибуты. Элемент таблицы мог быть EMPTY или ссылаться на страницу; занятые элементы могли иметь собственные биты доступа. Атрибуты включали времена, размер логического байта, EOF-указатель, счётчики и сведения резервирования.

Таблица могла быть разреженной. Между существующими страницами разрешались пустые элементы. EOF-указатель не обязан был указывать на последние данные. NLS использовал обе особенности.

Документированный набор был TYPE L 36, STRU P, MODE S. Логический байт соответствовал 36-битному слову TOPS-20. Индекс задавал позицию, Descriptor Page переносила общие атрибуты, а страница данных могла нести управление доступа.

Это не превращало остальные хосты в TOPS-20. Формат позволял понимающим сторонам сохранять значимые различия без частного соглашения.

Три вида экономии передачи

Приложение разрешало сократить существующую страницу, отбросив конечные нули и уменьшив Data Length. Получались три разных случая уменьшенного трафика.

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

Хеш объединённых payload может не различить эти карты. Нужны индексы, типы, длины, дескрипторы, поля управления, конец и политика преобразования.

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

Редкая функция без частного диалекта

RFC 1123 не рекомендовала общую реализацию Page Structure. Специализированный механизм не должен был расширять минимальное ядро каждого FTP-хоста.

Но хост, которому нужен FTP для random-access или дырявых файлов, обязан был применять определённую структуру страниц, а не изобретать частный FTP-формат. Отсутствие поддержки было допустимо, несовместимое переопределение — нет.

File Structure оставалась обязательной. Record Structure требовалась от хостов с поддерживающими её файловыми системами. Page Structure была необязательна. Обязательный глагол STRU не доказывал поддержку каждого аргумента.

Что сохраняет IANA

RFC 5797 включила STRU в обязательные базовые команды. Реестр команд и расширений FTP IANA сохраняет описание File Structure, класс настройки параметров и ссылку на RFC 959.

Запись координирует имя и роль. Она не подтверждает принятие P сервером, восстановление таблицы клиентом, сохранение атрибутов или современное использование.

Команда в реестре и возможность на сервере — разные факты. Отсутствующая передача страницы и присутствующая нулевая страница — тоже разные факты.

Не заполнять молчание автоматически

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

Наследие STRU P — явно представлять отсутствие, отделять позицию от прихода, переносить метаданные восстановления и проверять обратимость.

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

Источники