摘要

  • 一台远端机器即使可达，也可能在 Cronus 的资源搜索中“隐身”。RFC 947 记录了主机如何挑选必要的询问，并让另一张局域网上的机器听到。
  • 系统操作者因此能自行调整接力范围，不必让管理网关的另一机构先改设备；代价是共享主机为所有到达的 UDP 报文唤醒转发进程。

能通信，却无法这样寻人

给一座新楼修通道路，不会自动把其中的住户写进通讯录。Cronus 面对的网络问题也是如此：把服务分散在多台机器上之后，它要知道谁持有可用资源、哪些服务器正在工作。系统用广播提出问题，不必预先登记每个回答者的地址。

但广播只到达发出它的以太网。网关能把写好收件地址的报文送到远方，却不能替 Cronus 找到尚无地址的回答者。于是，一台远端机器即使可达，也可能仍不在资源搜索的视野里。RFC 描述的是这一机制的边界，并没有报告一次由此造成的具体故障。

维护系统的人于是遇到一个实际选择：请掌管网关的机构替 Cronus 增加特殊功能，还是自己运行一项跨网接力服务？这个选择关系到以后增减参与机器时由谁动手，也关系到处理额外报文的机器是谁。

Ken Lebowitz 与 David Mankins 在 1985 年 6 月的 RFC 947 中讨论了这个差别。Cronus 同时使用 TCP 和 UDP，广播收到的人往往多于真正需要回答的人。作者认为组播更贴近这种少数接收者的需求，但当时某些网络实现没有提供组播能力，初期工具因而采用广播。文章记录的是为这个具体系统延长广播可达范围的一次试验，而非要求互联网普遍转发广播的提案。

其运行方式有两段。发送端局域网上的主机进程监听 UDP 广播，只挑选特定端口或目的地址的报文。它从配置文件读出远端重播端的地址及各自应接收的报文类型，尝试建立 TCP 连接；连接断开后会定期重试。选中的原报文被装入转发端与重播端之间的消息。远端主机收到后，以当地链路广播地址作为目的地址再次发送，同时保留原报文的源地址。网关负责让两台主机之间的通信跨网，广播的挑选与再次发送并不由网关完成。

配置文件还可列出一台并非重播端的主机。转发端会把广播目的地址换成该主机地址，直接送出单播数据报。这个细节使设计的边界更清楚：系统可以针对不同目的地作不同选择，而不是让全部本地广播漫过每一道网关。

为什么不把功能放进网关

网关方案曾被认真考虑。RFC 947 说，它需要网关保有接收者名单，还得扩展网关控制协议来更新名单。某些消息该不该转发，可能取决于网关所能看到的协议层次以上的信息；其他供应商的网关也未必愿意实现这项功能。还有一层管理现实：控制底层网关的机构，与调整 Cronus 配置的人可能根本不是同一批。把功能画在网关上很整洁，实际却可能把一次应用配置变更交给另一套管理体系。

作者同样考虑过 Cronus 内核。如果每个参与者的内核都要知道其他参与者地址，增减主机会变得僵硬，方案也更难脱离 Cronus 使用。于是，选择权落在可配置的主机进程上。这不意味着主机方案没有代价，只意味着代价和决策被放在另一处。

重播带来了回流风险。转发端不连接与自己处于同一局域网的重播端，也不转发源地址不属于本地网络的报文。这是 RFC 所述的防回流措施，不能据此推断所有环路都已消除，更不能把源地址当作身份认证。为在重播时保留原源地址，实验所用的 BBN TCP/IP 实现还增加了一项特殊能力，允许有特权的进程以另一台主机的源地址发送报文。这恰好说明：看似透明的延长广播，需要特定主机软件的配合。

试验达到哪里

作者报告了两段物理上分开的以太网，中间还隔着两张局域网。消息至少经过两道网关。运行环境是装有 4.2BSD UNIX 与 BBN 网络软件的 VAX，转发端和重播端是独立进程；按作者说法，它们已经为该配置工作了数月。这个观察足以说明那套配置可用，却不足以推出大范围部署或独立性能评价。

共享主机的开销反而被写得很直白。因为筛选发生在用户态，每当 UDP 报文抵达，转发进程都要醒来，最后才决定多数报文不需要接力。作者讨论过把筛选放进内核、仍让用户程序管理配置与重播；也计划改用专门的微型计算机实时系统。RFC 没有说这两条改造已经完成。

RFC 919 早已指出广播会给每个接收者带来工作量；RFC 922 处理有子网时的 IP 广播问题。Cronus 这份记录的独特之处，则是把跨网可达、报文选择、配置权和处理成本放在同一张技术账单上。RFC 1112 后来的 IP 组播规范提供了另一种标准化语境，但不能反推这次试验的后续命运。

来源