Résumé

  • Archie a converti des inventaires de répertoires FTP distants en noms et emplacements consultables ; les fichiers eux-mêmes ne se trouvaient pas dans l’index.
  • Le manuel de mai 1991 décrit des collectes nocturnes sur une partie des sites, mais une actualisation d’environ un mois par site : l’âge de l’observation faisait donc partie du résultat.

Un résultat avait une date, même si elle se voyait peu

Une réponse de recherche semble parler du présent. Dans Archie, elle ressemblait plutôt à une note datée : ce nom figurait à cet emplacement sur cette archive lors du dernier relevé de ses répertoires. La nuance pouvait échapper à l’utilisateur qui prenait une correspondance plausible pour la preuve que le fichier était encore accessible.

Archie construisait son index à partir du FTP anonyme. Un manuel daté du 20 mai 1991 indique que sa base connaissait environ 600 sites d’archives FTP. Chaque nuit, le système se connectait à une partie d’entre eux pour en récupérer la liste récursive des répertoires, ou un fichier contenant déjà cette liste lorsque le site en fournissait un. Chaque site était mis à jour à peu près une fois par mois. Les listes compressées étaient conservées sur quiche.cs.mcgill.ca, à McGill, où la communauté Internet pouvait aussi les télécharger par FTP anonyme. McGill n’avait donc pas à rapatrier tous les logiciels, documents et jeux de données des archives : Archie recueillait les noms et chemins qui rendaient ces collections distantes plus faciles à trouver. (Manuel d’Archie, 1991)

Les commandes rendaient visible la différence entre un index de noms et un serveur de fichiers. prog recherchait des noms et pouvait renvoyer l’hôte, le chemin, la taille et la date de modification. site affichait la liste complète d’une archive connue. La commande list indiquait la date de la dernière mise à jour d’un site. Une fois la correspondance trouvée, il fallait encore se connecter à l’archive pour transférer le fichier. En 1992, la RFC 1325 décrit la même séquence : Archie fournit le nom de l’archive, son adresse IP et l’emplacement ; l’étape suivante se déroule sur le site distant. En 1994, la RFC 1689 qualifie Archie de source secondaire et précise que l’utilisateur télécharge le fichier par FTP depuis l’archive elle-même. (RFC 1325 ; RFC 1689)

Cette séparation donnait une horloge à l’index. Un répertoire pouvait changer entre deux collectes. Un fichier pouvait être déplacé, renommé ou supprimé pendant qu’Archie continuait d’afficher la dernière liste recueillie. Le manuel de mai 1991 ne dissimulait pas entièrement cet âge : il exposait la date de mise à jour du site. Mais il ne prétendait pas non plus qu’une réponse équivalait à une vérification en direct. Elle prouvait qu’un nom et un emplacement avaient été observés ; seul l’état actuel de l’archive, suivi d’un transfert réussi, pouvait établir que le fichier s’y trouvait encore et restait utilisable.

La couverture du système avait elle aussi des limites visibles. Le manuel citait les « sites UNIX seulement » et signalait qu’il était impossible de restreindre une recherche à certains sites. Ce ne sont pas de simples détails d’interface : ces choix déterminaient les archives représentées et les questions que l’utilisateur pouvait poser. Un répertoire central simplifiait l’exploration, sans pour autant constituer l’ensemble des fichiers de l’Internet ni rendre les archives identiques entre elles.

En mai 1991, ce service avait déjà un coût informatique notable. Le manuel estimait sa base à environ 70 Mo et indiquait que les mises à jour comme les recherches chargeaient sensiblement le Sun 4/280 qui l’hébergeait. Archie était encore un projet expérimental ; le logiciel n’était pas distribué à l’extérieur et la multiplication de serveurs restait un objectif à long terme. Fréquence de collecte, stockage et charge des requêtes relevaient donc d’un même problème de conception.

Accélérer les mises à jour aurait pu réduire l’âge des observations, mais chaque passage aurait aussi mobilisé le réseau des archives et les ressources de la machine qui indexait les listes.

Les chiffres évoluent vite, à condition de ne pas les confondre. Le tableau de l’article d’Alan Emtage et Peter Deutsch présenté à la conférence USENIX de l’hiver 1992 est daté du 30 octobre 1991 : il compte 1 025 sites connus, 886 indexés, 1 502 976 références de fichiers et 686 104 noms uniques. Les références dépassent les noms distincts : un même libellé ne désignait donc pas nécessairement un seul objet sur le réseau. La RFC 1325, en mai 1992, parle ensuite d’environ 1,5 million de noms dans quelque 900 archives et de neuf serveurs Archie dans le monde. Elle indique que choisir un serveur plus proche pouvait alléger une partie de la charge de McGill. Cela documente une extension des points d’accès et un objectif de répartition, pas l’identité ni la fraîcheur de toutes les listes conservées par chaque serveur. (Article d’Emtage et Deutsch, USENIX 1992 ; RFC 1325)

Dans la fiche d’Archie de la RFC 1689, mise à jour le 1er novembre 1993, le serveur commercial compte environ 27 installations, dont certaines ne sont pas publiques. Le passage d’une seule machine de McGill à plusieurs serveurs élargit l’accès ; il ne réunit pas pour autant la découverte et la livraison sous une même autorité. Les exploitants d’archives maîtrisaient toujours les fichiers. Archie assemblait une description datée des endroits où leurs noms avaient été observés. (RFC 1689)

La contribution d’Archie n’a pas été de rendre actuel un fichier distant grâce à une réponse centralisée. Elle a rendu les collections publiques consultables sans prétendre les posséder. La question a changé : de « où pourrait se trouver ce fichier ? » à « de quand date cette observation, et l’archive peut-elle encore le servir ? ». La recherche ouvrait une piste vers la preuve ; elle n’en était pas la source.

Sources