摘要

  • 1984 年启动的志愿项目让 UUCP 主机名和邻居关系可以共享；当时并没有一份完整、持续更新且由所有机器共同查询的网络目录。
  • 共享地图可以作为 pathalias 的输入，但条目是否准确、如何变成可用路径，仍取决于参与站点的维护。

分析

共同地图首先是一项报告工作

Stargate Internet Museum 后来整理的项目史，把 UUCP Project 的起点放在 1984 年 1 月 USENIX 会议的一场非正式讨论。三十多位志愿者承担起建立和维护地图的工作。USENIX 提供初期经费；资助结束后，志愿者、地区协调员和其他参与者继续推进项目。这是回顾性记述，能说明项目如何起步，却不能证明所有地区和主机参与程度相同。

地图通过 comp.mail.maps 发布，也可以从主动提供副本的主机获取。这解决的是具体的协调难题：UUCP 通过机器间定时交换传递邮件，发送方需要知道哪个邻站能让消息更接近目的地。每台机器不会在每次传输前查询一个始终完整的中心服务。路由计算所需的大量知识来自运营者。

每条记录把网络事实和人的责任放在一起：系统名称、组织、联系人、电子邮件地址、邻居以及最后编辑者。这很重要，因为候选路径依赖连接描述；条目错了，也需要有人能够回应。项目说明要求参与者检查自己的主机和邻居，再发送修正和补充信息。这证明项目提出了维护要求，却不是合规审计。档案没有说明某项修改要多久才会到达每份地图副本。

地图负责描述，计算由各站点完成

存档 README 说明，发布的数据用于输入 pathalias。DAILY、WEEKLY、DIRECT、DEMAND 等标签对应程序使用的数值权重，代表虚构的连接成本。它们不是账单，也不是实测价格。运营者可以把共享记录和本地 Path.* 数据合并，在自己的机器上计算成本较低的邮件路径。

这样的分工让地图可以复用，却没有把它变成中央指挥系统。项目发布共用描述，各站点自行决定保留哪些额外信息、优先走哪条路径。“最佳”路线取决于执行计算的站点掌握的数据和成本假设。邻站呼叫时间变了但记录没有更新，结果就可能过时。地图不会自动纠错，也不能确认一次呼叫是否成功。

地图记录还有算路之外的用途。README 提到，遇到故障时可以借它寻找联系人，也能寻找适合新连接的站点。名称、组织和邻接关系共同构成服务于网络运营者的非正式目录。路线生成只是用途之一。

发布边界给本地细节留出空间

项目建议大型站点公开少数网关，而不是枚举本地网络中的每台机器。若内部邮件投递需要更多细节，站点可以保存不公开的补充信息，在运行 pathalias 时与共享地图合并。公共数据描述的是 UUCP 广域网络可到达的主机，并非网关后的全部工作站。

这条边界有操作和社会两方面的影响：它限制了地图在资源有限的系统上的体积，不必公开每台内部机器，并让各站点独立维护本地细节。代价是公共地图无法包含每条路径需要的全部信息。项目接受局部不完整，以换取更小、更易维护的共同层。

另一个澳大利亚案例展示了相似需求，但并不属于 UUCP Project。D. F. Davey 在 1988 年《Australian UNIX systems User Group》通讯中写道，ACSnet 节点信息自 1986 年 3 月起通过 aus.map 收集并发布。他提到软件和管理存在缺陷，小型机器也无法存下完整网络状态。这个比较表明地图能够弥补另一种网络工具的不足；它不能证明 ACSnet 与 UUCP 共用地图或项目。

查找记录本身也成了问题

1990 年 11 月，一位 Usenet 用户询问如何搜索或浏览 UUCP 地图。Richard Foulk 征求 Perl 脚本；Paul Vixie 随后发布一个 shell 归档，其中包括解包器和一些工具，以及他表示自己编写的索引器和浏览器。这段交流让数据可用性问题变得具体：即使记录已经分发，用户找不到所需条目也仍然不够。它证明了一个请求和回应，不能说明工具的采用范围。

地图的作用依赖一连串普通工作：站点报告邻接关系，有人检查并修正条目，志愿者整理和分发更新，运营者再下载、搜索并与本地数据合并。任何一步中断，都可能让路由计算拿到一张看似合理却已经过时的网络图。它是由社区维护的参考资料，不是自动发现协议。

来源