Resumen

  • RFC 1068 separó la interfaz interactiva de un demonio de control. La primera reunía y ponía en cola los parámetros; el segundo programaba y repetía transferencias FTP entre servidores. La solicitud persistía antes de que se moviera el archivo.
  • En un lote, la primera lista NLST válida fijaba los miembros y un puntero recordaba cuáles habían tenido éxito. El trabajo podía terminar por éxito total, fallo permanente o límite de intentos, de modo que el informe por archivo era la verdadera prueba del resultado.

La innovación de RFC 1068 no fue un nuevo formato de paquete. Fue una espera que ya no pertenecía a una persona. El FTP ordinario se ejecutaba en primer plano: si el host remoto no respondía o la conexión se rompía, el usuario volvía a emitir la orden. BFTP colocó esa obligación en un proceso que podía seguir activo después de cerrar la sesión.

La interfaz recogía una descripción. El file transfer control daemon, o FTC, conservaba y ejecutaba esa descripción. El documento pretendía explorar un modo de servicio y decía expresamente que no añadía un protocolo nuevo. La historia se encuentra, por tanto, en el estado que rodeaba a FTP: cola, calendario, reintentos, avance parcial y aviso.

Una orden unía tres máquinas sin convertirlas en una

El host de control podía ser distinto tanto del origen como del destino. El usuario entregaba nombres de host, credenciales y rutas de ambos lados. Podía copiar, mover o borrar el origen; crear, sustituir o añadir en el destino; fijar tipo, modo y estructura FTP; usar comodines y elegir la hora del primer intento. También designaba un buzón para la notificación.

submit almacenaba esos parámetros en la cola. Después, la interfaz podía desaparecer. Ese hito demostraba que el controlador tenía una instrucción duradera. No demostraba que los servidores estuvieran disponibles, que las credenciales siguieran sirviendo, que el destino admitiera la escritura ni que un byte hubiera atravesado la conexión de datos.

verify ofrecía una observación anterior: conectar con los dos servidores, entrar, comprobar parámetros y localizar el archivo fuente cuando fuera posible. Un host caído impedía parte de la comprobación. Y aun cuando todo funcionara, el usuario debía enviar después la solicitud. La verificación describía un momento; no reservaba el siguiente.

El controlador veía respuestas, no necesariamente el archivo

BFTP reutilizó el modelo de terceros de RFC 959. El demonio abría controles hacia los dos servidores. Uno recibía PASV; su dirección y puerto llegaban al otro mediante PORT; RETR y STOR hacían que los procesos de datos se conectaran entre sí. El archivo viajaba de origen a destino sin pasar por el host que guardaba la cola.

Por eso no debe mezclarse el registro de intención con la ruta de datos. El controlador sabía qué comandos había enviado y qué contestaba cada servidor. La RFC 959 exigía mantener abiertos los controles y esperar las respuestas finales 226 o 250. Abrir una conexión, aceptar preliminarmente una orden o cerrar el socket de datos eran señales necesarias en algunos casos, pero no sustituían el resultado terminal.

La composición dependía de implementaciones heterogéneas. Al menos un servidor debía tener PASV. RFC 1068 describe NLST no estándar, respuestas sin formato y fallos de comunicación presentados como 5xx permanentes en lugar de 4xx transitorios. El demonio no observaba una verdad abstracta: actuaba según una clasificación emitida por sistemas que podían equivocarse.

Reintentar era memoria entre sesiones

Ante un fallo temporal, FTC registraba el suceso y esperaba. El ejemplo comenzaba con unos diez minutos, duplicaba la pausa y la limitaba a unas cuatro horas. Era una decisión del programa descrito, no una constante normativa.

La clasificación FTP gobernaba la próxima acción. Según RFC 959, 4yz indica que la acción no ocurrió pero puede pedirse otra vez sin modificar la solicitud. 5yz desalienta repetir exactamente lo mismo. Confundir ambas familias podía matar un trabajo recuperable o conservar uno que nunca progresaría.

Los intentos acababan al tener éxito, recibir un fallo permanente o alcanzar el máximo. Entonces llegaba el correo. La existencia de una notificación sólo probaba que FTC había cerrado su ciclo; el mensaje todavía debía explicar si celebraba una entrega o documentaba un abandono.

El primer listado válido puso una cerca temporal

Los comodines hacían inestable un lote. Mientras la solicitud esperaba, el directorio de origen podía cambiar. Si cada reintento ejecutaba un NLST nuevo, la misma orden adquiriría archivos recién creados o perdería otros. BFTP guardaba la primera lista obtenida con éxito. Esa instantánea definía el conjunto y excluía adiciones posteriores.

Tampoco intentaba una transacción atómica. Si varios archivos ya estaban copiados cuando fallaba el siguiente, borrarlos para reiniciar todo era ineficiente y quizá imposible con la ruta rota. Un puntero marcaba el progreso y los ciclos posteriores sólo atacaban los miembros pendientes.

Así, un lote podía contener éxito y fracaso al mismo tiempo. RFC 1068 lo llamaba completo si todos los elementos habían funcionado, si surgía un fallo permanente o si se agotaban los intentos. Completo significaba que no quedaba otro intento programado. El listado individual de la notificación era necesario para saber qué archivos existían realmente en el destino.

Una palabra clave no creó una identidad

La consulta y la cancelación usaban una palabra elegida al enviar el trabajo. El propio texto la llama autenticación débil. Dos usuarios con la misma palabra podían encontrar o cancelar solicitudes ajenas. Avisar por correo de la cancelación aportaba una huella posterior, no una autorización previa.

La capacidad de dirigir una conexión entre terceros tuvo además una frontera posterior. RFC 2577 explicó que PORT podía convertir un servidor FTP en origen de una conexión contra otro servicio, el ataque bounce, y que restringirlo podía eliminar el FTP proxy. No demuestra que BFTP sufriera un incidente; impide describir la orquestación como una facultad sin riesgo.

Fuentes y límites

RFC 1068 informa de algunos meses de uso en ISI. No acredita adopción general ni descendencia directa hacia colas modernas. RFC 959 sustenta el modelo FTP y sus respuestas; RFC 2577 añade el límite de seguridad posterior. Ninguna fuente prueba una transferencia concreta, credenciales protegidas, un despliegue actual o un resultado de aplicación.

La idea que permanece es operativa: persistir una petición mejora la posibilidad de volver a intentar, pero crea un sistema de control cuyos estados no son el resultado. La cola conserva lo que se quería hacer. El historial por archivo demuestra hasta dónde llegó.