Resumen

  • El reinicio original de FTP insertaba marcadores en los modos bloque o comprimido y relacionaba dos estados locales mediante 110 MARK ssss = rrrr.
  • El receptor debía hacer duraderos los datos previos antes de emitir su marcador, que podía incluir estado de conversión y no sólo posición de archivo.
  • RFC 3659 hizo práctico el reinicio en modo STREAM mediante un número de octetos para la transferencia inmediatamente posterior, pero dejó fuera la identidad de versión y la integridad del archivo reconstruido.

El signo igual no expresaba equivalencia numérica

RFC 1123 corrigió una descripción confusa de la respuesta 110. ssss era una cadena vista en el flujo de datos y codificaba una posición en el sistema del emisor. rrrr codificaba la posición correspondiente en el sistema del receptor. Cada parte generaba y volvía a interpretar su propio valor.

Esto permitía que dos máquinas con almacenamiento distinto compartieran un punto de recuperación sin revelar ni normalizar sus coordenadas internas. El cliente conservaba la pareja, no una fórmula para traducir un valor en el otro. Cuando llegara la hora de reanudar, devolvería a cada sistema el marcador que ese sistema entendía.

Además, el emisor no podía esperar cada 110 como si fuera un acuse síncrono. Debía continuar enviando. La respuesta viajaba por la conexión de control mientras el archivo avanzaba por la conexión de datos. El mecanismo admitía que la prueba recuperable fuera por detrás del progreso instantáneo.

Un indicador de interfaz puede mostrar el último byte leído. El marcador respondía otra pregunta: ¿hasta qué estado anterior pueden volver ambos extremos sin inventar lo que ocurrió durante la interrupción?

El modo de transferencia daba forma al checkpoint

RFC 959 separa tipo de representación, estructura de archivo y modo de transmisión. En STREAM, el cierre de la conexión de datos indica normalmente EOF. El documento advierte que esa señal no distingue por sí sola una finalización normal de un cierre prematuro.

El modo bloque sí tenía encuadre propio. Un encabezado de tres octetos incluía un descriptor de ocho bits y una longitud de dieciséis. El bit de valor 16 declaraba un bloque de marcador de reinicio. A continuación aparecía una cadena de caracteres imprimibles, sin espacios, integrada en la representación FTP y diferenciada de los datos del usuario.

Los modos bloque y comprimido podían insertar esos hitos y expresar el final sin depender del cierre TCP. Por ello RFC 1123 vinculó el reinicio original a esos modos. Los números de secuencia de TCP no bastaban: describían entrega de una conexión, no la posición recuperable dentro de la representación ni del almacenamiento.

El checkpoint era una pieza de semántica de aplicación. Si un intermediario sólo guardaba un recuento de paquetes, no poseía el estado que los dos procesos de transferencia habían acordado conservar.

Primero persistir, después nombrar

RFC 1123 pide que el receptor fuerce a almacenamiento estable todos los datos anteriores al marcador antes de generar rrrr. El orden evita prometer una posición que sólo existe en búferes volátiles. El valor del receptor queda respaldado por la capacidad local de volver a esa frontera.

“Estable” no significa inmortal ni replicado en todo lugar. El estándar no concede una garantía de conservación universal. Exige coherencia entre el token y las acciones del sistema que lo emite. Ese mismo sistema debe poder utilizarlo más adelante.

El User-FTP también debía conservar la pareja tras una caída. RFC 1123 propone un archivo de control creado vacío al comenzar, ampliado con los pares recibidos y borrado al finalizar correctamente. Así, una recuperación arranca desde el último par íntegro, no desde el mayor número que alcanzó una barra de progreso.

Borrar el registro al terminar forma parte de la seguridad. Un marcador huérfano, sin archivo, dirección ni parámetros asociados, puede parecer vigente cuando ya no describe nada.

La posición podía contener una conversión incompleta

El ejemplo decisivo de RFC 1123 es un salto de línea. FTP podía enviar texto ASCII con CRLF mientras el receptor lo almacenaba como un solo LF. Si el marcador caía después de CR y antes de LF, el proceso receptor debía recordar que ya había consumido CR.

Su rrrr tenía que codificar ese estado además de la posición física. Reanudar sólo desde un desplazamiento de disco podía duplicar o perder parte de la conversión. La posición correcta era una combinación de lugar y memoria del transformador.

FTP nació para sistemas con códigos de caracteres, tamaños de palabra y formas de almacenamiento diferentes. La representación común de red no convertía sus archivos internos en iguales. Los tokens opacos permitían coordinar sin exigir un mapa universal que habría sido falso en los casos interesantes.

Esa opacidad limitaba el poder del protocolo. El emisor no interpretaba la posición del receptor. El receptor no infería el estado del emisor. La igualdad sólo preservaba la correspondencia observada.

La misma pareja cambiaba de uso según la dirección

En una carga del usuario al servidor, el cliente insertaba el marcador del emisor. El servidor persistía el prefijo, producía su marcador y devolvía ambos. Para reanudar, el cliente restauraba su propio estado y enviaba al servidor REST con el valor del servidor.

En una descarga, los papeles se invertían. El servidor ponía marcas en el flujo; el cliente estabilizaba su copia y guardaba su posición local. Después devolvía al servidor el token que éste había creado y utilizaba localmente el suyo.

El tercer caso era una transferencia entre dos servidores dirigida por un proceso usuario. El coordinador guardaba dos coordenadas que no entendía y devolvía cada una a su dueño. No necesitaba conocer los sistemas de archivos remotos; sí necesitaba evitar que una pareja se mezclara con otra operación.

La autoridad residía en los extremos y la custodia de la relación en el controlador. Esa distribución hacía posible la recuperación heterogénea, pero convertía el contexto en un requisito tan importante como el token.

REST sólo preparaba el siguiente verbo

Una respuesta 350 a REST no completaba nada. Indicaba que el servidor había guardado un parámetro y esperaba una acción de transferencia. En el modelo de RFC 959, RETR, STOR o APPE consumían ese estado.

RFC 1123 añadió errores que separaban causas. 554 podía indicar que el sistema no conseguía reposicionarse según REST. 555 señalaba que el tipo o la estructura actuales no eran compatibles con el archivo existente. Una posición válida bajo una representación podía ser inválida bajo otra.

El diseño en dos pasos también podía dejar estado residual. Si REST tenía éxito pero el cliente no lograba enviar la orden de datos prevista, otra operación podía encontrarse con un marcador viejo. La especificación posterior convirtió la adyacencia en una regla explícita.

REST STREAM eligió una coordenada común

RFC 3659 definió una forma de reiniciar en STREAM sin marcadores dentro del flujo. El parámetro pasó a ser un entero decimal. Indica cuántos octetos de la transferencia inmediatamente posterior no se enviarán. REST 0 elimina la omisión y vuelve al archivo completo.

El ejemplo del RFC usa TYPE I, comprueba que el archivo remoto no ha cambiado, envía REST 802816, recibe 350 y a continuación ejecuta RETR. Para un flujo de octetos binarios, la operación coincide con la intuición moderna de continuar desde un offset.

Pero el número no hereda las capacidades del par antiguo. No conserva el estado de una traducción de caracteres, no identifica la versión remota, no demuestra que el cliente aún tenga el prefijo correcto y no verifica la concatenación final.

Por eso REST debe ser la última orden antes de RETR o STOR. Si el cliente no consigue emitir la segunda, debe repetir REST; si quiere una transferencia completa, debe usar REST 0. Un valor puede ser sintácticamente correcto y resultar fuera de rango sólo cuando la orden posterior aporta el archivo y la operación concreta.

Reanudar STOR era más que ahorrar descarga

En RETR, el cliente decide cómo unir el sufijo recibido con su copia parcial. En STOR, el servidor escribe en un objeto existente. Un offset equivocado puede sobrescribir, truncar o combinar datos bajo un nombre que aparenta continuidad.

RFC 3659 limita REST con STOR al objetivo de completar un envío fallido. Declara indefinidos los resultados cuando el marcador no coincide con el final del contenido parcial que el servidor comunica, o cuando la continuación no vuelve a extender el destino hasta su tamaño anterior. Si se admite APPE, debe comportarse como STOR en el punto elegido, no añadir al final sin más.

La norma no promete atomicidad. Otra interrupción puede dejar una nueva versión parcial. La operación necesita una política local para permisos, nombres temporales, visibilidad, limpieza y sustitución del destino final.

La capacidad técnica de posicionar una escritura no concede por sí sola autoridad para modificar ese objeto. El dueño del destino sigue decidiendo si el contexto es suficiente.

El archivo podía cambiar mientras el offset seguía siendo válido

RFC 3659 recomienda observar la modificación antes del primer RETR y volver a compararla antes de reanudar. Para STOR, permite examinar la antigüedad del parcial frente a la fuente. MLST puede aportar una indicación más rica.

La prudencia del texto importa. Los relojes no tienen que estar sincronizados. Una modificación puede cambiar sin que el contenido final sea distinto; un archivo puede cambiar y regresar a sus bytes anteriores. El dato sirve para detectar riesgo, no como hash ni identidad absoluta.

Tamaño y offset tienen el mismo límite. SIZE describe el tamaño de transferencia bajo el tipo actual. Dos objetos del mismo tamaño pueden ser diferentes. Una transferencia que llega a la longitud esperada puede mezclar un prefijo de ayer con un sufijo de hoy.

Cuando la integridad importa, la recuperación termina con una verificación del objeto completo. Ni 110, ni 350, ni 226 sustituyen esa prueba de extremo a extremo.

FEAT declaraba gramática, no estado del fichero

Un servidor que aplica RFC 3659 anuncia exactamente REST STREAM mediante FEAT. Esto deja al cliente distinguir el offset decimal de los marcadores disponibles sólo en bloque o comprimido.

El registro de comandos y extensiones FTP de IANA mantiene REST como orden base y REST+ como modificación STREAM. Son registros de normalización, no estadísticas de uso ni certificados de implementación.

La respuesta FEAT prueba que el servidor declara comprender una forma. No prueba que el archivo continúe siendo el mismo, que el marcador esté dentro de rango, que el usuario pueda escribir o que el resultado tenga los bytes esperados.

La recuperación tenía que seguir siendo revocable

El mecanismo antiguo almacenaba más contexto porque permitía más transformaciones. El mecanismo STREAM almacenaba menos porque escogía un caso frecuente y una coordenada simple. En ambos, la instrucción de continuar era más estrecha que la autoridad sobre el archivo terminado.

Un checkpoint útil debe poder invalidarse cuando cambia su objeto, su representación, su dueño o su entorno. Si un sistema conserva offsets durante más tiempo que las versiones a las que apuntan, la facilidad de reanudar se convierte en una forma de combinar estados incompatibles.

FTP enseñó que el ahorro de repetir trabajo sólo es seguro cuando también se conserva la evidencia necesaria para saber qué trabajo se está reutilizando.

Fuentes y límites de la evidencia

Las fuentes cerradas describen los mecanismos estandarizados. No miden compatibilidad actual, despliegue, éxito operativo ni integridad de productos concretos. El artículo no deduce una reanudación segura de una entrada IANA o de una línea FEAT.