Résumé

  • BFTP enregistrait les paramètres d'un transfert sur un hôte de contrôle. Après le départ de l'utilisateur, un démon pouvait lancer ou reprendre un FTP entre deux serveurs ; l'entrée dans la file conservait l'intention, elle ne déplaçait aucun octet.
  • Pour plusieurs fichiers, la première liste NLST réussie fixait le périmètre et un pointeur gardait les succès acquis. La requête devenait « complète » après succès total, échec permanent ou épuisement des essais : seul le relevé par fichier indiquait l'issue.

La RFC 1068 part d'un geste banal : quitter son terminal avant la fin d'un gros transfert. Le FTP de premier plan demandait à l'utilisateur de rester présent et de recommencer après un échec. Avec des hôtes parfois indisponibles et un Internet plus chargé, cette présence humaine devenait une ressource du protocole.

BFTP a déplacé cette ressource vers un hôte de contrôle. Une interface recueillait la demande ; un démon de contrôle du transfert, le FTC, la réalisait plus tard. Aucun nouveau protocole de transport n'était inventé. L'innovation tenait à la conservation d'une instruction, de sa progression et de sa limite d'essais autour de serveurs FTP ordinaires.

La file gardait une description, pas le fichier

L'utilisateur indiquait un hôte source, un hôte destination, leurs identifiants, leurs mots de passe et les noms des fichiers. Il pouvait demander une copie, un déplacement ou une suppression, remplacer ou ajouter au fichier distant, choisir les paramètres FTP, employer un motif générique et fixer l'heure du premier essai. Une boîte aux lettres recevrait le rapport final.

La commande submit plaçait cet ensemble dans la file du démon. L'interface pouvait alors s'arrêter. Ce moment prouvait que BFTP avait accepté des paramètres pour un travail futur. Il ne prouvait ni la disponibilité des deux systèmes, ni l'ouverture d'un chemin de données, ni l'écriture du fichier à destination.

La commande verify resserrait certaines incertitudes. Si les machines répondaient, BFTP pouvait se connecter, ouvrir les sessions, vérifier des paramètres et constater la présence du fichier source. Mais l'inaccessibilité empêchait la vérification, et une vérification réussie restait antérieure à une soumission et à un transfert distincts. Elle ne réservait pas l'état futur.

L'hôte de contrôle ne portait pas les octets

Le mécanisme exploitait le FTP tiers défini par la RFC 959. Le démon ouvrait deux connexions de contrôle, obtenait une écoute avec PASV, la transmettait à l'autre serveur par PORT, puis associait RETR et STOR. La connexion de données allait directement de la source à la destination. Le contrôleur orchestrait un flux qu'il ne transportait pas.

Trois traces restaient donc séparées. La file consignait l'opération souhaitée. Les connexions de contrôle contenaient les commandes et réponses des deux serveurs. La connexion de données portait le contenu. La RFC 959 exigeait que les contrôles restent ouverts et que le processus attende une réponse terminale 226 ou 250. Une ouverture, une réponse préliminaire ou la seule fermeture du canal de données ne suffisait pas à établir le résultat.

BFTP dépendait aussi des variantes d'implémentation. Il fallait au moins un PASV. Le rapport mentionne des listes NLST non conformes, des réponses mal formées et des erreurs de communication classées à tort en 5xx permanent au lieu de 4xx transitoire. Une machine de reprise prend ses décisions dans le vocabulaire que lui donnent ses dépendances ; si ce vocabulaire ment, la file persiste dans la mauvaise direction.

La reprise appartenait au service, non à une session

Après un échec temporaire, le démon enregistrait l'événement et attendait. L'implémentation décrite commençait par un délai court, par exemple dix minutes, le doublait, puis le plafonnait, par exemple à quatre heures. Ces nombres illustrent une politique locale. Ils ne constituent pas des délais normatifs pour l'Internet.

La distinction 4yz/5yz de la RFC 959 devenait décisive. 4yz autorisait à répéter la même séquence sans changer la demande ; 5yz décourageait cette répétition. Le classement d'une réponse ne décrivait pas seulement l'erreur : il décidait si l'intention stockée aurait une autre chance.

Le démon s'arrêtait après succès, échec permanent ou nombre maximal d'essais. Puis il envoyait un courrier. Recevoir ce courrier prouvait qu'une phase terminale avait été atteinte. Le contenu du message devait encore dire laquelle.

Le premier inventaire réussi fermait le lot

Un motif générique pose un problème temporel. Pendant l'attente, des fichiers peuvent apparaître ou disparaître. Refaire NLST à chaque tentative transformerait discrètement une ancienne demande en une nouvelle. BFTP enregistrait donc la liste obtenue lors du premier NLST réussi. Aucun fichier créé ensuite n'entrait spontanément dans le lot.

Ce lot n'était pas atomique. Si plusieurs fichiers avaient déjà réussi, l'échec du suivant ne déclenchait pas leur suppression pour tout recommencer. Un pointeur de progression conservait les membres terminés ; les reprises ne concernaient que les autres. L'efficacité venait d'une mémoire du succès partiel, pas d'une transaction globale.

Le mot « complet » prend alors un sens précis et parfois trompeur. La RFC 1068 déclarait la requête complète lorsque tous les fichiers avaient réussi, lorsqu'un échec permanent survenait ou lorsque la limite d'essais était atteinte. « Complet » signifiait : le démon n'a plus de travail planifié. Le message listait les résultats individuels parce que le statut global ne disait pas si les fichiers étaient arrivés.

Le mot-clé n'était qu'un compromis d'autorité

Pour retrouver ou annuler une requête, l'utilisateur fournissait un mot-clé stocké avec elle. Les auteurs qualifiaient eux-mêmes ce mécanisme d'authentification faible. Deux personnes choisissant le même mot pouvaient voir ou annuler les travaux l'une de l'autre. Le courrier envoyé après annulation rendait l'action visible, sans la rendre légitime rétroactivement.

La RFC 2577 a ensuite expliqué comment l'autorité PORT du FTP mandataire pouvait servir à faire contacter un autre service par un serveur : l'attaque par rebond. Ce texte ultérieur ne documente aucun incident BFTP. Il borne toutefois l'interprétation : orchestrer une connexion directe entre tiers est une capacité de contrôle qu'une file pratique ne neutralise pas.

Sources et limites

La RFC 1068 rapporte quelques mois d'utilisation à l'ISI, pas un déploiement général. Elle ne prouve aucune filiation directe avec les files de travaux modernes. La RFC 959 établit le modèle serveur-serveur et les réponses FTP ; la RFC 2577 décrit plus tard un risque de ciblage. Aucune ne démontre un transfert nommé, une sécurité des identifiants ou un résultat présent.

L'apport historique est plus mesuré : conserver une intention permet de reprendre, mais ajoute un système dont chaque état doit rester lisible. La file dit ce qui doit être tenté. Le relevé par fichier dit ce qui s'est produit.