摘要

  • Archie 汇总远端 FTP 目录清单中的文件名与位置；它的索引并不承载清单所列文件。
  • 1991 年 5 月的手册写明，系统每晚访问一部分站点，但每个站点约每月才更新一次。搜索结果的“新旧”，因此取决于上次采集时间。

搜索返回的是上一次观察

搜索结果很容易被理解为对“现在”的陈述。对 Archie 来说，它更像一张带日期的便条：上次采集这个站点目录时，这个名字出现在这个路径。若用户把一个看似准确的匹配直接当成“文件仍可下载”的证明，就会把两个不同的动作混为一谈。

Archie 从匿名 FTP 档案的目录清单建立索引。1991 年 5 月 20 日的手册记载，数据库约跟踪 600 个 Internet FTP 档案站点。系统每晚通过匿名 FTP 访问其中一部分，抓取递归目录清单；如果站点已经准备好清单文件，也可以直接取用。每个站点大约每月更新一次。清单经过压缩后保存在 McGill 的 quiche.cs.mcgill.ca，Internet 社群也能用匿名 FTP 获取。McGill 不需要把远端档案里的软件、文档和数据全部复制回来；Archie 汇总的是让人能找到这些资源的名称与路径。(1991 年 Archie 手册)

用户命令展示了“查目录”和“取文件”之间的分工。prog 按名称搜索，返回匹配项所在主机、路径、文件大小和修改时间等信息；site 可以列出一个已知档案的完整目录；list 显示站点清单的最近更新时间。查到匹配项以后，用户仍要连接那个档案站点，自己传输文件。RFC 1325 在 1992 年讲得很明确：Archie 提供档案主机、IP 地址和位置，下一步发生在远端主机。1994 年的 RFC 1689 则把 Archie 称为“第二手信息源”，并说明用户要通过 FTP 从档案站点取回文件。(RFC 1325；RFC 1689)

这套分工也给索引设定了一只时钟。两次采集之间，目录可能已改变；文件可能被移动、改名或删除，而 Archie 仍保留着上次抓到的清单。1991 年手册并未完全遮住这段时间差：它允许用户查看站点上次更新时间。但它也没有声称每次搜索都是在线实时检查。命中只能证明某个名称和路径曾被观察到；能否证明文件现在仍然存在、内容是否可用，要看源站的当前状态和一次真正成功的传输。

覆盖范围同样有边界。手册把“只包含 UNIX 站点”列为限制，也指出用户不能把搜索限定到指定站点。这并非无关紧要的界面缺陷：它决定了哪些档案会出现在索引里，也限制了用户能提出的问题。集中目录让分布式档案更容易检索，但它既不是 Internet 全部文件系统的镜像，也不会把不同站点变成统一的存储空间。

1991 年 5 月，维护这个服务已有明显的计算成本。手册估计数据库约占 70 MB，并说更新和搜索给运行它的 Sun 4/280 带来可感知的负载。Archie 当时仍属开发阶段，软件尚未向外部站点发布，在其他地方部署服务器还只是长期计划。采集频率、存储容量和查询负载因此属于同一个设计问题。更频繁地采集可能缩短清单的年龄，却也增加了远端档案的网络访问和索引主机的处理工作。

扩张中的数字必须连着日期读。Alan Emtage 与 Peter Deutsch 在 1992 年冬季 USENIX 会议论文中的统计表标注为 1991 年 10 月 30 日：已知站点 1,025 个、已编入索引 886 个、文件引用 1,502,976 条、唯一文件名 686,104 个。引用数与唯一名称数不同，意味着同一个文件名不一定对应网络上唯一的对象。1992 年 5 月的 RFC 1325 随后记录约 900 个档案站点上的 150 万个文件名，以及分布在世界各地的 9 台 Archie 服务器。它还说，使用 servers 命令选择较近的服务器可以减轻 McGill 的部分负载。这个记录说明访问点变多、减轻负载成为目标；它没有证明每台服务器的清单都完全相同或同样新。(Emtage 与 Deutsch，USENIX 1992 论文；RFC 1325)

RFC 1689 中的 Archie 条目更新于 1993 年 11 月 1 日，当时商业服务器系统约有 27 个部署点，其中一些并不公开。服务器从 McGill 一处增加到多处，扩大了可访问性，却没有把“发现”和“交付”变成同一个权威来源：档案运营者仍掌握文件本身，Archie 汇总的是这些名称曾在哪里出现过。(RFC 1689)

Archie 的贡献不是让中心化答案自动代表远端文件的当前状态，而是让公共文件档案变得可搜索，同时承认它们仍属于各自站点。用户面对的问题从“这个文件可能在哪儿？”变成“这条观察有多旧，那个站点现在还能否提供它？”搜索给出的是通向证据的路线，证据的来源仍在远端。

资料来源