Resumen

  • Bajo STRU R y MODE S, un byte de todos unos introducía un código: 1 señalaba EOR, 2 EOF y 3 ambas fronteras en la misma posición.
  • Si el byte reservado pertenecía realmente a los datos, se enviaba dos veces. Interpretarlo exigía conservar estado y conocer la estructura negociada.
  • FTP distinguió registros, líneas, bloques de lectura y segmentos TCP. Otros modos movían EOR/EOF a descriptores, y RFC 1123 redujo después qué hosts debían implementar registros nativos.

Una decisión pendiente durante un byte

Dos señales idénticas de todos unos no cerraban dos estructuras. Decodificaban un solo byte literal. La primera reservaba el siguiente lugar; la segunda decía que la reserva debía anularse y devolver el valor original al archivo.

La alternativa era estructural. Tras la señal, el valor 1 terminaba el registro, 2 terminaba el archivo y 3 hacía coincidir ambos finales. RFC 765 y RFC 959 documentaron esta pequeña gramática de STREAM.

Así, la señal no tenía significado aislado. El receptor necesitaba el byte siguiente y la memoria de STRU R. Un decodificador impaciente podía borrar un dato válido o entregar al archivo dos bytes donde el emisor había enviado una forma escapada de uno solo.

FTP no pidió a un flujo que inventara registros

La estructura contestaba qué clase de archivo se transfería. STRU F declaraba una secuencia continua; STRU R, una sucesión de registros. El modo contestaba cómo se representaba durante el viaje. MODE S ofrecía un flujo de bytes con poco armazón externo.

Para archivos con registros, todos los EOR eran explícitos, incluido el último. El host de origen traducía su marca local a la representación común y el destino la convertía a una forma útil en su propio sistema.

La separación evitaba exportar accidentes del almacenamiento. Un contador propio de un mainframe no era una frontera portátil. La declaración EOR sí podía ser entendida por dos implementaciones que guardaban los registros de manera diferente.

Citar un valor reservado

Reservar una señal dentro del mismo alfabeto que los datos crea una deuda: ¿cómo se envía literalmente ese valor? FTP la pagó repitiéndolo. La técnica mantiene completo el repertorio de bytes y hace reversible la inserción de control.

La longitud del flujo y la longitud de los datos reconstruidos dejan de ser equivalentes. Cada pareja duplicada consume dos posiciones de transferencia y produce una. Las otras parejas no producen datos: producen fronteras.

Un control combinado con valor 3 evitaba añadir un registro ficticio después del último. La distinción entre EOR, EOF y ambos permitía describir el final sin confundir la estructura de registros con la vida de la conexión.

El búfer podía cortar la pareja por la mitad

El analizador debía recordar una señal situada al final de una lectura. RFC 9293 ofrece a la aplicación un flujo TCP fiable y ordenado, no registros de FTP ni unidades iguales a cada llamada de recepción.

Por eso la señal podía llegar en un segmento y su segundo byte en otro, o ambos podían aparecer en una sola lectura. El significado era idéntico. Convertir una frontera de búfer o paquete en EOR inventaría estructura ajena al emisor.

Esta obligación parece pequeña—un estado pendiente—pero decide la integridad. Al cerrar con una señal incompleta, el receptor no tiene un archivo estructurado bien formado aunque todos los bytes anteriores sean correctos.

Con STRU F, el escape desaparecía

En estructura de archivo y modo STREAM, todos los bytes eran datos. EOF se indicaba al cerrar la conexión de datos. El valor de todos unos no necesitaba repetición ni interpretación especial.

La misma captura cambia, pues, de sentido cuando cambia STRU. Sin la cronología de parámetros no se puede afirmar si dos señales representan dos datos, uno solo, o si una pareja marca EOR. El plano de control forma parte de la prueba del plano de datos.

También importa cómo termina. Un cierre normal basta para EOF bajo STRU F. En un archivo con registros, el EOR final debe estar explícito. Registrar solamente el cierre oculta si llegó la última frontera lógica.

BLOCK y COMPRESSED usaron otra superficie

En BLOCK, cada bloque llevaba longitud y bits descriptores. Uno indicaba EOR, otro EOF, y podían coexistir. Había además bits para datos sospechosos y marcadores de reinicio.

COMPRESSED conservaba descriptores de frontera junto a formas para datos repetidos y relleno. El concepto de registro no dependía, por tanto, del byte escapado; aquella era la codificación propia de STREAM.

Una comparación rigurosa conserva los bytes crudos y una representación canónica de registros. Dos modos pueden expresar la misma estructura con octetos distintos. Dos negociaciones distintas pueden dar sentidos distintos a octetos iguales.

Una línea legible no demostraba un registro

FTP diferenciaba fin de línea de fin de registro. Sin estructura de registros, CRLF podía separar líneas ASCII y NL líneas EBCDIC. Bajo STRU R, EOR era una declaración propia.

Sustituir EOR por saltos de línea puede producir texto aparentemente correcto y, aun así, cambiar el archivo. Un registro puede contener varias líneas, una línea puede formar parte de una presentación y algunos registros no son texto.

RFC 959 exigía aceptar estructura de registros para textos ASCII y EBCDIC y pedía transformaciones útiles e invertibles entre sistemas orientados a archivos y a registros. Lo importante era poder recuperar la división declarada, no solo leer caracteres.

El mínimo de 1989 reconoció la diversidad

RFC 1123 hizo obligatoria la estructura de registros solo para hosts cuyos sistemas de archivos la soportaban. Otro host todavía podía aceptar STRU R guardando literalmente el flujo.

Guardar sintaxis y reconstruir semántica son promesas diferentes. El primer camino puede permitir una recuperación posterior; no demuestra que una aplicación local reciba registros. Aceptar, aplanar y reconstruir no deben compartir el mismo informe.

RFC 5797 y el registro IANA de comandos FTP mantienen STRU y MODE como parámetros del protocolo base. El registro no ejecuta la máquina de estados ni prueba que un servidor acepte R.

La evidencia vive a ambos lados del escape

Una auditoría conserva TYPE, STRU, MODE, hash del flujo, hash de datos decodificados, longitudes, posiciones EOR/EOF, estado final y resultado de ida y vuelta. Un hash único del archivo no puede demostrar que sus registros sobrevivieron.

Los canarios deben partir la pareja entre lecturas, rodear cada control con datos escapados y expresar la misma estructura en STREAM y BLOCK. Señales pendientes, discriminadores inesperados, último EOR ausente o estado conservado tras cambiar MODE requieren investigación.

El byte apareció dos veces para que el control no expulsara a un valor legítimo. FTP hizo reversible la ambigüedad, siempre que el receptor conservara el acuerdo completo.

Fuentes