摘要

  • RFC 1001 与 RFC 1002 把 NetBIOS 名称登记和发现交给 NBNS，把组数据报的分发交给另一个逻辑服务 NBDD。
  • 对 P、M 节点而言，NBDD 的肯定应答只说明它表示愿意中继；规范允许部分分发或拒绝，也没有为发送方提供逐个成员的收讫证明。

在广播型局域网里，发送方可以向一个组发送，而不必先把组内每台机器都改写成单独目的地。把这类服务带入需要路由的网络后，问题就分成两件事：谁知道组里有哪些成员，谁负责把数据报复制并送向这些成员？1987 年 3 月发布的 RFC 1001 和 RFC 1002 为这两件事设定了两个逻辑角色。关键历史点在于职责分离：名称服务器可以找到名称的持有者，但这并不会让它自动成为流量分发器。

两份文件把终端节点分为 B、P、M 三类。B 节点采用广播域模型；P 节点使用点对点基础设施；M 节点兼有两者特征。P/M 路径中，发往唯一名称的数据报直接送到发现出的地址。目的名称若为组名或 NetBIOS 广播名，发送方则通过单播把数据报送到 NBDD，由它向该名称对应的节点转发。设计不把 IP 广播当成每一段网络都能提供的通用手段。

NBNS 与 NBDD 是分开的逻辑实体，同一台设备可以同时实现二者。如果它们分置，RFC 1001 允许实现自行通过私有协议交换名称信息，但没有规定该协议。这里形成了依赖关系：分发器需要掌握目的组名与接收者之间的对应信息；然而，规范没有把私有交换变成互通的记录，也没有把它变成发送方可见的结果凭证。

P/M 节点可以在发送前询问 NBDD 是否愿意为某个目的名称进行分发。肯定回答表示服务器称自己会中继；若答案是否定，发送方可向 NBNS 查询名称持有者列表，然后分别向列出的地址发送单播。查询并非必需。RFC 1002 也允许直接发送，代价是 NBDD 可能丢弃该数据报。这些是不同的控制路径，而不是同一次成功交付的两道确认。

证据边界出现在查询之后。RFC 1001 允许 NBDD 完成分发、只完成其中一部分，或拒绝分发；除查询以外，它没有规定反馈来告诉发送方数据报是否已被转发。因此，能力查询中的肯定答复不是扇出回执。规范没有逐个接收者的送达记录；名称登记成功也不能证明每位成员收到了数据。

组播背景也要说准确。RFC 1001 描述的假设环境是：实现不能指望所有互联网节点或网络都支持所需的广播或组播；它的附录另行勾勒了与 Internet Group Multicasting 集成的方向。这不代表 IP 组播此前从未被提出。RFC 988 于 1986 年 7 月发布，已经提出了支持程度不同的主机组播扩展。准确的说法是，NetBIOS 方案不能假设组播服务已在所有相关网络普遍可用。

RFC 1001 与 RFC 1002 自称为建议标准。它们描述协议设计，不是某个具名网络已部署该方案、所有实现表现一致，或应用程序收到每个数据报的证据。RFC 1001 还把 B 节点的活动留在 NBNS/NBDD 支持服务器的视野之外，也没有要求这些服务器桥接到 B 节点。规范界定了角色，却没有同样清楚地证明端到端结果。

本篇与 RFC 1088 的边界也在于此：RFC 1088 讨论从 IP 地址推导 NetBIOS 名称及本地名称表；名称映射与组数据报分发回答的是不同问题。这一区分不只适用于 NetBIOS：发现一组目的地、授权中继代表该组行动、转发分组、确认接收，是四件不同的事。在这项 1987 年方案中，控制交换说明了前面的选择，却没有让完整交付结果对发送方可见。