Resumo

  • STRU P representava arquivos descontínuos como páginas independentes e indexadas; Page Index indicava posição no arquivo, não ordem de transmissão.
  • Entradas vazias do mapa simplesmente não eram enviadas, enquanto uma página existente cheia de zeros continuava sendo conteúdo. A RFC 959 declarou expressamente que uma lacuna não era uma página de zeros.
  • A função nasceu sobretudo das necessidades de TOPS-20 e NLS. A RFC 1123 desaconselhou sua adoção geral, mas exigiu o formato comum quando arquivos esparsos ou de acesso aleatório realmente precisassem dele.

O intervalo não precisava ser um defeito

A RFC 959 definiu page structure para arquivos descontínuos, chamados também de random access ou holey files. Cada página transmitida levava um Page Index, o número lógico daquela parte do arquivo. A especificação avisava que não se tratava do número sequencial da transmissão.

Assim, páginas vizinhas na conexão podiam ocupar posições não vizinhas no destino. O apêndice de TOPS-20 fixa o sentido: páginas vazias, lacunas do mapa, não eram enviadas; uma lacuna não era igual a uma página de zeros.

Uma página zerada existe e ocupa um lugar. Uma lacuna afirma que não havia página naquele lugar. Um sistema pode devolver zeros ao ler ambos, mas alocação, custo, atributos e comportamento posterior podem divergir. Materializar a lacuna não é necessariamente recuperar o original.

Tipo, estrutura e modo não eram sinônimos

FTP separava a representação lógica em TYPE, a organização interna em STRU e o enquadramento de transmissão em MODE. A combinação importava, mas nenhuma dimensão substituía as outras.

File structure, o padrão, tratava o arquivo como sequência contínua de bytes. Record structure mantinha registros sequenciais. Page structure mantinha páginas independentes com localização lógica.

Essa escolha respondia a máquinas diferentes. A RFC 959 compara código-fonte armazenado em registros fixos num mainframe IBM e apresentado como fluxo de caracteres no TOPS-20. Para trocar algo útil, os dois lados precisavam declarar a suposição estrutural.

Conversões locais eram possíveis, desde que reversíveis. Um host orientado a fluxo podia transformar registros em uma forma útil, mas deveria recompor o mesmo arquivo quando ele fosse recuperado sob record structure. A RFC 1123 pediu que a transformação entre registros e fluxo fosse invertível tanto quanto possível.

Uma captura de payload, portanto, não fecha a prova. O conjunto de parâmetros ativos também pertence à evidência.

O cabeçalho dava sentido ao tamanho

O cabeçalho mínimo de cada página tinha Header Length, Page Index, Data Length e Page Type. Cada campo era um byte lógico cuja largura vinha de TYPE.

Page Type separava estados que um contador não distingue. Last Page encerrava a transmissão com cabeçalho mínimo e zero dados. Simple Page trazia dados comuns. Descriptor Page descrevia o arquivo inteiro. Access Controlled Page acrescentava informação associada àquela página.

Logo, Data Length zero podia ser uma terminação explícita. Um índice ausente podia ser uma lacuna. Uma página de descrição podia governar o conjunto. O significado dependia do tipo e da posição.

O índice também separava ordem lógica de ordem de chegada. Reorganizar pelo momento da recepção, em vez de pelo Page Index, podia produzir outro mapa mesmo com todos os bytes intactos.

O arquivo TOPS-20 que motivou o formato

A RFC 765 e a RFC 959 dizem que a necessidade veio principalmente da transferência eficiente entre sistemas TOPS-20, em especial dos arquivos usados pelo NLS.

Um arquivo de disco TOPS-20 reunia pathname, tabela de páginas, conjunto de páginas possivelmente vazio e atributos. Uma entrada da tabela podia estar EMPTY ou apontar para uma página. Entradas ocupadas também podiam carregar bits de acesso próprios. Os atributos incluíam tempos, tamanho lógico, ponteiro de fim, contadores e dados de backup.

A tabela não precisava ser contígua. Entradas vazias podiam aparecer entre páginas ocupadas. O ponteiro de fim também não precisava apontar para o último dado. Arquivos NLS usavam os dois casos.

O exemplo normativo empregava TYPE L 36, STRU P, MODE S. O byte lógico de 36 bits correspondia a uma palavra TOPS-20. O índice indicava o mapa; uma página descriptor levava atributos gerais; páginas de dados podiam levar controle por página.

O protocolo não obrigava outros hosts a adotar o armazenamento TOPS-20. Criava um idioma comum para quem precisava preservar aquelas diferenças.

Lacuna, página nula e página encurtada

O apêndice permitia ainda descartar zeros finais de uma página existente, reduzindo Data Length. Existem, portanto, três maneiras distintas de ver menos dados na conexão.

Na lacuna, a página não existe naquela posição. Na página nula, existe uma página de valores zero. Na página encurtada, a página existe, mas a extensão transmitida diminui segundo uma regra conhecida.

Um hash da concatenação dos payloads pode esconder a diferença. Uma verificação completa precisa de índices, tipos, comprimentos, descritores, controles, término e política de transformação.

Também há limites. As RFCs não afirmam que todo filesystem materializa lacunas do mesmo modo, que uma lacuna sempre é lida como zero ou que controles de página serão executados por um destino diferente. O formato carrega distinções; não promete uma implementação local universal.

Não recomendado não significava proprietário

A RFC 1123 não recomendou page structure em geral. Era uma capacidade especializada e não deveria ampliar o mínimo comum sem necessidade.

Mas, quando um host realmente precisasse transferir arquivos de acesso aleatório ou com lacunas, deveria usar o formato definido em vez de inventar um FTP privado. Podia recusar a função; não podia reutilizar o problema com significado incompatível.

File structure era obrigatória. Record structure era exigida de hosts cujos filesystems a suportavam. Page structure permanecia opcional. A presença obrigatória do comando STRU não provava suporte a todos os seus códigos.

A linha de IANA e seu limite

A RFC 5797 incluiu STRU no vocabulário base obrigatório. O registro FTP da IANA mantém File Structure como comando de parametrização com referência à RFC 959.

O registro coordena nome e papel. Não demonstra que um servidor aceita P, que um cliente recompõe a tabela, que metadados sobrevivem nem que haja implantação atual.

Uma ordem presente no registro não é uma capacidade presente no servidor. Uma página ausente da transmissão também não é uma página de zeros presente no arquivo.

A informação guardada por um espaço vazio

Formatos atuais ainda fundem ausente, zero, desconhecido, oculto e não aplicável numa única célula. A simplificação funciona até alguém precisar reconstruir a origem.

STRU P deixou uma disciplina: declarar ausência, separar posição de ordem de chegada, transportar metadados de reconstrução e testar se a conversão faz o caminho de volta.

A página ausente não aguardava preenchimento. O espaço vazio era parte do arquivo.

Fontes