Resumen

  • STRU P describía archivos discontinuos mediante páginas independientes con índices lógicos; esos índices no numeraban el orden de transmisión.
  • Las posiciones vacías de la tabla no se enviaban, y RFC 959 insistía en que un hueco no era equivalente a una página existente llena de ceros.
  • La función nació sobre todo para TOPS-20 y NLS. RFC 1123 dejó de recomendarla en general, pero exigió el formato común cuando un host realmente necesitara transferir archivos dispersos o de acceso aleatorio.

Lo que no llegó también formaba parte del archivo

RFC 959 llamó “holey files” a ciertos archivos discontinuos. Su estructura no podía describirse bien concatenando únicamente los bloques que contenían datos. Era preciso saber en qué posiciones lógicas estaban y cuáles no existían.

Por eso cada página llevaba un Page Index. La especificación aclara que era el número lógico de esa sección dentro del archivo, no el número de secuencia por el que atravesaba la red. Dos páginas consecutivas en la conexión podían dejar un hueco entre sus posiciones finales.

El apéndice de TOPS-20 formula el límite sin rodeos: las páginas vacías, los huecos, sencillamente no se enviaban, y un hueco no era lo mismo que una página de ceros. Una ausencia estructural y un contenido explícito pueden producir lecturas parecidas en alguna plataforma, pero no expresan el mismo archivo.

FTP preguntaba qué clase de cosa estaba transfiriendo

El protocolo separaba tres decisiones. TYPE indicaba cómo interpretar las unidades lógicas. STRU indicaba cómo se organizaban. MODE determinaba el encuadre de los bytes sobre la conexión de datos.

La estructura F, predeterminada, veía una secuencia continua de datos. La estructura R veía registros consecutivos. La estructura P veía páginas independientes con índice.

No era complejidad gratuita. Un mainframe IBM podía almacenar código fuente en registros fijos, mientras TOPS-20 lo presentaba normalmente como caracteres y líneas. Sin declarar la estructura, el receptor tenía que adivinar dónde terminaba el contenido y comenzaba una decisión local de almacenamiento.

La transformación estaba permitida, pero debía poder deshacerse. Si un host orientado a flujos recibía registros y los convertía, tenía que estar preparado para recuperar un archivo idéntico bajo la misma estructura. RFC 1123 pidió que la conversión entre registros y flujo fuera invertible hasta donde resultara posible y útil.

La advertencia general de RFC 959 era coherente: almacenar y recuperar con parámetros diferentes podía impedir obtener la misma versión. La evidencia de una transferencia no terminaba en su payload; incluía el estado de negociación.

Una cabecera para no confundir orden y posición

La cabecera mínima de una página contenía cuatro campos lógicos: longitud de cabecera, índice de página, longitud de datos y tipo de página. La anchura de cada campo dependía de TYPE.

El tipo daba contexto al tamaño. Last Page cerraba la transmisión paginada con una cabecera mínima y longitud de datos cero. Simple Page representaba datos normales. Descriptor Page podía transportar información que afectaba al archivo completo. Access Controlled Page añadía un campo asociado a esa página.

Así, una longitud cero no significaba siempre “no hay nada”. Podía ser una terminación positiva. Un índice que no aparecía podía ser un hueco. Una página de descriptor podía tener una función global. El significado se obtenía de la combinación, no de una cifra aislada.

También quedaban separadas la posición lógica y la llegada. Reordenar por recepción en vez de por Page Index podía construir otro mapa aun cuando todos los datos hubieran llegado intactos.

El caso concreto que impulsó STRU P

RFC 765 y su sucesora sitúan el origen principalmente en transferencias eficientes entre sistemas TOPS-20, sobre todo para archivos de NLS.

Un archivo de disco TOPS-20 incluía pathname, tabla de páginas, un conjunto posiblemente vacío de páginas y atributos. Las entradas de tabla podían estar vacías o apuntar a páginas, y las ocupadas podían incluir bits de acceso propios. El puntero de fin era un atributo numérico y no tenía obligación de coincidir con el último dato.

La discontinuidad era real: posiciones vacías podían separar páginas existentes. NLS utilizaba tanto archivos con huecos como punteros finales no situados al final físico.

El ejemplo normativo empleaba TYPE L 36, STRU P, MODE S. Los campos de cabecera eran palabras lógicas de 36 bits. Page Index se refería al mapa. Una página descriptor llevaba atributos generales. Una página de datos podía llevar su control asociado.

El diseño no declaraba que esa organización fuera universal. Buscaba que dos hosts que comprendían el caso pudieran conservarlo sin esconderlo dentro de una extensión privada.

Hueco, página nula y página acortada

El mismo apéndice permite descartar ceros finales dentro de una página existente reduciendo Data Length. Aparecen, por tanto, tres formas distintas de enviar menos material.

En un hueco no hay página en esa posición. En una página nula sí hay una página, aunque sus palabras valgan cero. En una página acortada hay página y contenido declarado, pero se transmite una extensión menor porque los ceros del final se omiten bajo una regla conocida.

Un hash calculado sobre la concatenación de datos puede perder estas diferencias. Para demostrar reconstrucción hacen falta índices, tipos, longitudes, descriptor, campos de control, terminación y política de conversión.

Tampoco conviene extrapolar. Las RFC no prometen que todo filesystem lea un hueco como ceros, que conserve los mismos atributos ni que aplique controles de página de otro sistema. STRU P describía información; no garantizaba una materialización idéntica en cualquier destino.

La rareza no justificaba un dialecto privado

RFC 1123 dijo que implementar page structure no era recomendable en general. El núcleo interoperable podía ser más pequeño, y la mayoría de hosts no necesitaba aquella maquinaria especializada.

Sin embargo, si un sistema necesitaba FTP para archivos de acceso aleatorio o con huecos, debía usar la estructura definida y no inventar un formato privado. La opción era no soportar la función o soportarla con el significado común; no apropiarse del nombre para otra semántica.

File structure seguía siendo obligatoria. Record structure lo era para hosts cuyos sistemas de archivos la admitían. Page structure era opcional. Que el comando STRU perteneciera al conjunto requerido no convertía todos sus códigos en capacidades universales.

Un registro no demuestra un servidor

RFC 5797 incluyó STRU entre los comandos base obligatorios. El registro IANA de comandos y extensiones FTP conserva “File Structure”, su clase de parametrización y la referencia a RFC 959.

Eso coordina vocabulario. No prueba que un servidor concreto acepte P, que un cliente sepa reconstruir el mapa, que sobrevivan los controles ni que exista uso actual.

La presencia en un registro y la capacidad desplegada son hechos distintos. Igual que la ausencia de una página transmitida y la presencia de una página de ceros eran hechos distintos.

No rellenar el silencio por comodidad

Muchos esquemas modernos juntan ausente, cero, desconocido, oculto y no aplicable porque una sola columna resulta cómoda. La conversión produce datos válidos y destruye la razón de la ausencia.

La vieja estructura P deja una regla vigente: declarar el vacío, separar índice de orden de llegada, conservar los metadatos de reconstrucción y hacer reversibles las transformaciones que prometen serlo.

La página que faltaba no necesitaba relleno. Necesitaba que alguien conservara su lugar vacío.

Fuentes