摘要

  • Athena 项目为不断扩大的工作站网络设计 Zephyr，让简短、时效性强的通知能够抵达目标；本地广播和电子邮件各有难以弥补的限制。
  • 认证身份、登录地点、用户选择的可见性、主题订阅和消息送达是不同状态，任何一项都不能证明用户有空或已经阅读。

Zephyr 要解决的并不是如何在屏幕上弹出一段文字，而是计算从共享主机走向联网工作站后，怎样找到正确的人。Athena 在 1987至1988年的规划中描述了这种校园计算环境的转变。文件服务器需要通知受影响的用户即将停机，打印服务需要报告作业完成，助教可能要联系整门课程。电子邮件能够保留消息，却需要等待并由发送者列出收件人。网络广播速度快，但通常止步于本地网络，每台机器还得处理大量并非发给自己的消息。Zephyr 的设计者把差异说得很清楚：邮件慢且繁琐；广播转瞬即逝，也难以扩展。

因此，Zephyr 被设计为通知传输底层，其上可以构建多种通信服务。1988 年的 USENIX 论文描述了基础传输层，以及订阅和用户定位等上层服务。1989 年 6 月 5 日的技术计划给出了运行结构：每个工作站有一个 HostManager（zhm），每个登录会话运行一个 WindowGram 客户端（zwgc），多个 Zephyr 服务器负责注册、路由和维护状态。通知把路由头与客户端数据分开。服务器根据路由头找收件人，无须理解消息正文。文件服务器可以通知自己已知的用户；不知道谁感兴趣的服务则可发布到某个类别，由客户端自行订阅。

订阅是一项明确记录的状态，不是向整个校园喊话。服务器保存由类别、实例和收件人组成的组合。客户端申请订阅后，符合条件的通知才会被路由给相关用户。zwrite 可以指定某个接收者。Kerberos 提供经过认证的主体身份，Zephyr 用它构造 Zephyr ID，于是系统能区分认证账号和消息里随手写下的名字。但认证回答的是“哪种身份发出了请求”，并不自动回答“这个人有权定位或打扰任何收件人吗”。访问控制、用户可见性与特权紧急通知另有各自规则。

在场记录同样有边界。Zephyr 登记用户登录和所在位置，使发送者不必知道用户正在哪台工作站上。设计文档明确提醒，位置数据库不能被当作实时而完整的名单。记录只能说明曾收到经过认证的登录；若工作站崩溃，退出通知可能发不出来，旧位置就会残留。反过来，没有公开的位置也不代表用户从未登录，因为用户可以选择不公开。系统在工作站重启或服务器发现主机不响应时清理部分陈旧状态。这能减少错误，却无法让分布式服务成为永不出错的见证人。

1989 年的计划列出六档可见性：none、opstaff、realm-visible、realm-announced、net-visible 和 net-announced。别人能否查询位置，与登录、退出时是否广播通知，并非同一个开关。MIT 在 1993 年的用户指南还把 hide 与彻底关闭 Zephyr 区分开来：隐藏位置不会阻止别人向用户发送通知。这种控制范围比一个万能的“请勿联系我”按钮更窄。

消息运输是否可靠又是另一回事。Zephyr 使用 UDP，并为有需要的应用提供不同级别的确认。设计者列明了重复、乱序、丢失和缺少流量控制等限制。zwrite 的例子承诺消息已经发出，却不保证对方一定收到，也不保证只收到一份。服务器确认、客户端确认和人读完消息，是三个不同事件。Zephyr 适合快速协调；运输回执却不能证明同意、注意到消息或完成了工作。

到 1993 年，MIT 的使用指南已把一对一和群组 Zephyrgram 作为 Athena 的日常工具。1996 年的一项研究也考察了 MIT 的 Zephyr Help 求助频道。这些材料能证明 MIT 内部的实际用途，却不足以证明 Zephyr 成为即时通信的普遍范本。它更值得记录之处，是划清了几条界线：身份用于路由，登录生成位置记录，订阅表达对一类通知的兴趣，而权限、可达性和人的注意力仍是独立问题。

资料来源