摘要

  • MARS 保存并分发三层组地址到 ATM 端点的簇内映射，但明确不参与实际的三层组播转发。
  • 发送者即使不是组成员，也可以取得完整的 MARS_MULTI 快照，随后自行建立 point-to-multipoint VC；或者只得到一个 MCS 地址，由另一条不透明路径完成扇出。
  • 成员登记、完整回复、leaf 已添加、CSN 连续或发送调用成功，各自只说明一个阶段，不能单独证明接收端在线、报文抵达、端到端成员一致、QoS、身份、授权或安全。

RFC 2022 最容易被忽略的一句话，为整个架构划定了边界：MARS 不参加实际的三层组播。它掌握的是地址关联——某个 IP 组播地址在当前 MARS Cluster 内对应哪些 ATM 端点——而不是承载报文的数据通道。

这项分工源于两种网络语义的冲突。IP 组播给发送者一个组地址；ATM UNI 提供的却是需要逐个端点建立的连接。发送端先向 MARS 查询映射，得到当时的 ATM 地址集合，再要求本地信令管理器创建 point-to-multipoint VC，并把每个地址作为 leaf 加进去。

RFC 1112 已经规定，发送者无需先加入接收组。RFC 2022 保留这一点。因此，一次成功查询不能证明源主机是成员；一次发送调用也不能证明任何接收者仍在组内。两者只证明发送端启动了自己的控制与传输动作。

一份名册必须先证明自己完整

当成员较多时，MARS 会把映射拆成多条 MARS_MULTI。字段 x 标记最后一段，序号 y 用来发现中间缺口。只有收到终止段且序列连贯，发送端才能把这些消息合成一次完整回答。超时、缺段或序号不一致都会令已收片段作废，查询必须重来。

这套规则证明的是“服务器的一份快照已完整抵达”，并不是“现实中的所有接收者此刻可达”。快照完成后，成员仍可能离开；信令添加某个 leaf 可能失败；端点也可能已经失去接收能力却尚未从名册清除。

电路建立是另一套状态机。发送端先建立根 VC，再逐一添加 leaf。RFC 2022 允许添加失败后重试，也允许在部分 leaf 仍待加入时开始传输。于是，“VC 已建立”与“所有预期接收者均已接入”不是同一事实；报文交给本地 VC，更不是所有应用已经收到报文的凭证。

MCS 把最后一段路径藏在服务器之后

若簇采用 Multicast Server，MARS 可以返回 MCS 的 ATM 地址，而不是每个实际成员的地址。发送端仍执行查询、建 VC、发送，看起来与 VC mesh 没有区别；它甚至不必知道 leaf 是成员还是 MCS。但真正接收并再次分发数据的是 MCS，而非 MARS。

这种透明性降低了端点复杂度，却压缩了发送端可见的证据。得到一个 MCS 地址，只能说明流量应该交给哪个中介，不能说明中介背后有哪些成员、何时完成扇出或谁实际收到了报文。RFC 2149 后来才专门展开 MCS 架构与多 MCS 协调，不能把后来的讨论倒推成 RFC 2022 已经提供的保证。

控制通知是在修补本地电路

已登记成员通过 ClusterControlVC 接收异步的 MARS_JOIN 与 MARS_LEAVE。端点据此给受影响的出站 VC 增减 leaf。若离开的正是最后一个 leaf，端点关闭整条 VC；该组的下一份报文到来时，再从查询 MARS 开始重建。

每条控制消息还带有 Cluster Sequence Number。MARS 每向控制 VC 发一条消息就递增 CSN，即使那条消息没有改变数据库。端点看见序号跳变，只能判断自己可能漏过一条控制消息，无法由缺口反推出究竟错过了加入还是离开。规范要求它重新查询并校验所有开放的组 VC；校验期间，数据可以继续流动。

CSN 因而是“不确定性探测器”，不是现实重放器。序号连续表明该端点观察到一段连续控制流，不表明 leaf 信令全部成功，也不表明线路末端仍活着。

规范刻意没有给出的保证

RFC 2022 把范围限定在一个 MARS Cluster 内，没有解决簇间路由。三层 QoS 到 ATM 属性的映射也被排除。备份 MARS 协调、死亡成员清理与多 MCS 协调未获完整方案；安全章节更明确写着没有讨论安全问题。

因此，每条记录都必须保留其窄边界：登记只说明登记动作；MARS_MULTI 完整只说明快照收全；leaf 只说明一个 ATM 地址被要求接入；MCS 地址只说明提交点；发送调用只说明本地动作。它们都不能单独升级为在线、送达、读取、真实身份、授权或安全结论。

RFC 2022 的历史价值，不在于用服务器“解决”了组播，而在于没有假装名册就是网络。名册、发送端电路和最终交付由不同主体控制，只能反复同步，不能被压扁成一个永久为真的成员标记。

来源