Resumen

  • FTP repartía una operación de archivo entre dos conexiones. Los bytes circulaban por datos; la orden y su estado quedaban en control. Una respuesta 1yz era preliminar y exigía otra respuesta.
  • El cierre del canal de datos podía corresponder al EOF normal, a ABOR, a un cambio de puerto, al cierre del control o a un error irrecuperable. El mismo síntoma TCP no elegía entre esos significados.
  • Si ABOR interrumpía una transferencia activa, 426 concluía negativamente la transferencia y el 226 posterior concluía positivamente la cancelación. El último código no era el resultado del primer trabajo.

Un único «terminado» borraba dos historias

Los sistemas de observación suelen preferir una casilla simple: en curso o terminado. FTP obligaba a resistirse a esa comodidad. El usuario veía una sesión, pero el protocolo mantenía una conversación persistente de control y abría conexiones de datos temporales para cada listado o archivo.

El proceso de datos podía observar apertura, bytes, EOF y cierre. El intérprete de protocolo sabía qué orden había originado ese canal, si sólo había emitido una respuesta preliminar y qué respuesta final correspondía. Al guardar una sola historia, se perdía la diferencia entre «ya no llegan bytes» y «la acción solicitada se completó».

No era una sutileza reservada a fallos exóticos. La separación permitía que el control siguiera vivo mientras una conexión de datos aparecía y desaparecía. Esa flexibilidad exigía que el significado permaneciera donde estaba el estado de la orden.

Antes de las familias modernas ya había dos cierres

La RFC 354, de julio de 1972, incluía 252 FTP transfer completed correctly. También incluía 452 FTP: File transfer incomplete, data connection closed.

Las dos respuestas podían acompañar a una conexión de datos ya cerrada. Una afirmaba que la transferencia había acabado correctamente; la otra afirmaba que el cierre la dejó incompleta. La distinción histórica muestra que el FIN nunca fue concebido como recibo suficiente de la acción FTP.

La razón arquitectónica era práctica. FTP conectaba sistemas con representaciones, estructuras y almacenamientos distintos. El servidor coordinaba su intérprete de protocolo con un proceso de transferencia y con una operación local sobre archivos. El número de octetos en la red no podía representar por sí solo todas esas decisiones.

Las frases de los servidores tampoco eran una base robusta para automatizar. Hacía falta que los dígitos indicasen si la aplicación podía seguir, debía esperar, aportar datos adicionales o considerar que la solicitud había terminado.

El primer dígito indicó qué podía ocurrir después

La RFC 640, publicada en 1974, reorganizó las respuestas. Una 1yz era positiva preliminar: la acción se había iniciado, pero seguía incompleta y vendría otra respuesta. Una 2yz era finalización positiva. Una 3yz esperaba información adicional. Las clases 4yz y 5yz cerraban negativamente la petición, una de manera transitoria y la otra de manera permanente para esa forma de solicitarla.

Así, «positivo» dejó de ser sinónimo de «hecho». 150 podía ser una buena noticia y, a la vez, una prohibición de marcar la orden como terminada.

La revisión también adelantó el momento de la respuesta preliminar. El servidor podía enviarla cuando el archivo era transferible y la conexión existía o estaba a punto de intentarse. La mejora evitaba esperas innecesarias, pero acotaba la evidencia: posibilidad e inicio no eran resultado.

Después de 125 o 150 faltaba el desenlace

La RFC 765 y la RFC 959 conservaron el modelo. La segunda limita cada orden a una respuesta 1yz como máximo y exige después una respuesta de finalización.

En las órdenes de archivo, 125 indica que la conexión de datos ya está abierta y empieza la transferencia. 150 indica que el estado del archivo es correcto y que el servidor va a abrir la conexión. Las salidas finales pueden ser 226 o 250, o errores pertinentes como 425, 426, 451, 551 y 552.

Por tanto, una captura que contenga 150 y todos los bytes esperados sigue sin tener el resultado FTP si falta el último mensaje de control. Y un código final negativo no se vuelve positivo porque el contador cuadre.

También se entiende por qué el cliente normalmente espera la respuesta final antes de enviar otra orden ordinaria. La petición anterior todavía posee el estado compartido. ABOR y STAT requieren reglas especiales porque deben interrumpir o consultar precisamente ese estado en curso.

El cierre no llevaba escrita la causa

La RFC 959 enumera varias razones por las que el servidor cierra la conexión de datos: final normal de una transferencia, petición de aborto, cambio de especificación de puerto, cierre legal o anormal del control y error irrecuperable.

Todas pueden verse como una desaparición del socket. No son el mismo resultado. Un cierre TCP ordenado no demuestra que se alcanzó el límite de archivo pretendido, que el servidor conservó el efecto local ni que no estaba obedeciendo una cancelación.

En modo Stream, el cierre puede marcar el fin del archivo. Ésa es una regla para delimitar datos, no una ampliación del recibo. La propia discusión de FTP sobre reanudación señala la debilidad: sin contexto de control, una terminación normal y una interrupción prematura pueden parecer idénticas.

Un registro útil debe separar dos entradas: «se observó EOF/cierre en datos» y «la orden FTP terminó con el código X». Que tengan la misma marca temporal no las convierte en la misma prueba.

Dos respuestas, dos acciones

La secuencia de ABOR impide leer el diálogo de atrás hacia delante. Si el servicio anterior ya acabó, la cancelación no tiene nada que detener. Aun así, el servidor puede responder 226 porque ha procesado correctamente la orden ABOR. No está certificando de nuevo el archivo.

Si la transferencia continúa, el servidor emite primero 426: la conexión se cerró y la transferencia original fue abortada. Después emite 226: la orden de aborto se tramitó con éxito.

El reparto correcto es:

  1. orden de transferencia → final negativo (426);
  2. orden ABOR → final positivo (226).

Guardar sólo «última respuesta = 226» concede éxito al trabajo equivocado. Asociar ambos códigos sólo con la transferencia borra, en sentido contrario, que la cancelación sí funcionó. La unidad de interpretación es la secuencia con propietario de acción.

El alcance del recibo terminaba en FTP

En una transferencia normal, 226 afirma que la conexión se cierra y que la acción de archivo solicitada ha sido satisfactoria. No incluye una suma criptográfica ni un identificador de versión. No garantiza escritura duradera, copia de seguridad, permisos futuros, consumo por otra aplicación o cumplimiento comercial.

Cada afirmación más fuerte necesita su propio comprobante: hash del contenido, confirmación de persistencia, identidad inmutable del objeto, acuse de la aplicación o estado del proceso de negocio.

El caso contrario también importa. Que el cliente no reciba 226 no prueba que el servidor no haya escrito. El control puede romperse después del efecto local. Repetir STOR sin mirar el estado remoto puede duplicar o sobrescribir. La conclusión correcta es incertidumbre sobre el resultado, no inexistencia del resultado.

Conservar el expediente, no una etiqueta

La auditoría mínima guarda la orden y su posición, 125 o 150, el extremo de datos, el resultado de apertura, los bytes, el EOF, la causa de cierre cuando se conoce, las respuestas finales en orden y la relación temporal de ABOR o STAT.

Además conserva hechos que FTP no promete: representación, modo, resolución de ruta, efecto en el sistema de archivos, persistencia, hash e identidad de versión. Son capas complementarias, no campos alternativos para un mismo «éxito».

Conviene modelar estados explícitos: preliminar aceptado, conexión pendiente, datos activos, datos cerrados a la espera del final, transferencia positiva, transferencia negativa, aborto solicitado, transferencia abortada, aborto procesado y resultado desconocido.

Reducirlos a done=true destruye la posibilidad de reconstruir quién terminó qué. La pérdida irreversible es la secuencia, no el socket.

Fuentes y frontera de la evidencia

La reconstrucción utiliza las RFC 354, RFC 542, RFC 640, RFC 765, RFC 959 y RFC 1123. Esas fuentes establecen las clases, los dos canales, los motivos de cierre y el comportamiento de ABOR.

La RFC 1123 señaló en 1989 que reanudación, ABOR y modo Block eran mecanismos útiles pero poco implementados. Es una constatación histórica, no una cifra actual. El conjunto no demuestra prevalencia, conformidad de productos ni propiedades de un almacenamiento moderno.