摘要

  • 1985 年的 RFC 966 提议用一个组地址指向可能提供同类服务的主机，不要求请求者事先掌握每台服务器的地址。
  • 组外主机也可以向开放组发送数据报；组内是否有人、网关是否知道成员所在网络、应用是否答复，是三道独立的关口。

无盘工作站必须先找到启动服务器才能工作。服务器一旦迁移，仍保存旧地址的工作站就卡在开机之前；管理员得逐台改地址，或者让全网无关机器也处理广播问询。Steve Deering 与 David Cheriton 在 1985 年 12 月的 RFC 966 中提出第三条路：把问题交给“可能提供该服务的主机组”，让工作站继续使用同一目的地。这个目的地甚至可以暂时没有成员。它解决的是往哪里问，不是保证一定有人答。RFC 966 是供讨论的设计提案，不能据此宣称当时已普遍部署。

论文把组播的作用分为多目的地传送和分布式绑定。后者更容易被忽略：客户端寻找的是一个服务，不必先确定它落在哪台机器。文中用文件服务器举例，客户端询问服务器组，认识该文件名的服务器再直接回答。常设的组标识也可以指向名称服务器组、启动服务器组等逻辑角色。这里有一个关键变化：地址所代表的需求相对稳定，提供服务的实体却可以换班。

RFC 966 允许同一主机加入多个组，也探讨只通过组地址可达的主机。临时组可随一次分布式程序的生命周期建立，最后一名成员退出后消失。提案列出 CreateGroup、JoinGroup、LeaveGroup 三类操作。常设组标识像一个长期入口，但入口存在不等于此刻有人值守。

“开放”说的是发送资格。请求者无需先加入组，就可以向它发数据报；否则，要找启动服务器的工作站竟得先成为启动服务器组的一员。提案另有用访问密钥限制成员加入的设想。是否可以发送、是否可以作为接收成员、应用是否接受请求，分别由不同机制决定。组地址本身不发放服务使用权。

这份便利要由网关的状态维护来承担。转发时，网关须知道哪些网络当下有该组成员。RFC 966 坦言，如何让各网关的成员记录及时一致，仍是尚未解决的分布式数据库问题。作者希望重复发送不会系统性地遗漏成员，称之为“覆盖”；但故障通知被定位为提示而非必备回执。因此一次发送既不能列明所有实际接收机器，也不能证明上层服务已经工作。

后来的文本保留了这条区分。RFC 988 于 1986 年替代 RFC 966，明确常设组永久的是地址，不是成员名单。RFC 1112 在 1989 年继续指出组播是尽力而为，不保证每位成员完整收到，更不保证顺序一致。这段沿革证明思想得到规范化，不证明原提案的每个细节都曾在网络上普遍运行。

这段历史的要点，并非“一个数据包就能找到所有人”。真正的新能力，是允许客户端凭借一个公开目的地提出问题，同时承认回答者、转发状态和送达结果都要另行查证。

来源与边界

本文仅使用原始的 RFC 966、RFC 988、RFC 1112，并以此前的广播提案 RFC 919 作对照。这些文件不能给出首次部署时间、采用率或某项具体服务的成功率。