你在这里。看看这个问题与其他知识怎样相连。
选择节点前往页面 · 展开后可留在地图中阅读
一个问题
反向挂载的“反向”指什么？
改变的是接入的发起或注册方向，不是把授权方向也倒过来。
- 温度计 Provider主动连接与注册→
- 宿主 /lab/sensor提供资源入口→
- 已授权调用者
Provider 可以主动来接入
通常我们想象宿主连接一个已知服务，再把它挂入命名空间。反向挂载允许 provider 一侧连接或注册回来，由宿主把它暴露的能力接到经过授权的位置。具体运输机制可能不同，不能把这个词等同于某个唯一 URL。
Arc 源码中可以分别看到 provider boot/register 的协议类型，以及基于 session 连接的挂载处理。前者描述宿主发出启动信号后注册、或 provider 主动注册；后者有实际连接、namespace 和断开处理的实现与测试。这些相关机制不应被描述为完全相同的部署入口。
三条边界仍然存在
- 谁证明接入者身份，或持有特定会话的挂载凭据？
- 宿主允许它占用哪个命名空间，是否会覆盖已有资源？
- 其他调用者得到什么可见范围和执行权限？
能主动连接，不等于任意挂载、不等于网络穿透的普遍保证，也不等于获得宿主的全部权限。
源码证明这些机制值得研究；具体预览部署是否可用，仍需单独运行验证。
实验室温度计接入一个宿主
设想实验室电脑运行一个温度计 provider，宿主负责向已授权的使用者提供 AFS。以下是说明角色和方向的例子，不是已经部署的演示：
- 温度计 provider 从实验室电脑发起连接，向宿主提出接入请求。
- 宿主检查接入凭据，并只允许它注册到
/lab/sensor。 - 宿主把 provider 的资源绑定到该挂载位置。
- 被授权的调用者读取
/lab/sensor/temperature，请求经宿主转到温度计 provider。
“连接成功”只说明双方建立了通信通道；“挂载成功”还说明宿主接受了资源与路径的绑定。尝试占用未授权路径应被拒绝。连接断开时，读取失败也必须让调用者看得见，不能悄悄返回旧数据并假装是当前读数。