跳到主要内容

10. 相关问题 (Related Issues)

可能需要表老化 (table aging) 和/或超时机制. 这些机制的实现超出了本协议的范围. 以下是更详细的描述 (感谢 MOON@SCRC@MIT-MC).

如果主机移动, 由该主机发起的任何连接都将正常工作, 前提是其自身的地址解析表在移动时已清除. 然而, 由其他主机发起的到该主机的连接将没有特别的理由知道要丢弃旧地址. 不过, 48 位以太网地址应该是唯一且永久固定的, 因此不应改变. 如果主机名 (以及某些其他协议中的地址) 被重新分配给不同的物理硬件, 主机可能会"移动". 此外, 根据经验, 始终存在通过硬件或软件错误意外传输错误路由信息的危险; 不应允许其永久存在. 也许连接发起失败应通知地址解析模块删除相关信息, 理由是主机不可达, 可能是因为它已关闭或旧的转换不再有效. 或者, 收到来自主机的数据包应重置用于向该主机传输数据包的地址解析条目中的超时; 如果在适当时间内未收到来自主机的数据包, 则忘记该地址解析条目. 这可能会导致为每个传入数据包扫描表的额外开销. 也许使用哈希或索引可以加快速度.

建议的地址解析数据包接收算法试图减少主机移动时的恢复时间. 回想一下, 如果 <protocol type, sender protocol address> 已在转换表中, 则发送方硬件地址将取代现有条目. 因此, 在完美的以太网上, 广播 REQUEST 到达电缆上所有站点, 每个站点都将获得新的硬件地址.

另一种方案是让守护进程 (daemon) 执行超时. 经过适当时间后, 守护进程考虑删除某个条目. 它首先直接向表中的以太网地址发送 (如需要, 进行少量重传) 操作码为 REQUEST 的地址解析数据包. 如果在短时间内未收到 REPLY, 则删除该条目. 请求直接发送以避免打扰以太网上的每个站点. 仅仅忘记条目可能会导致有用信息被遗忘, 而这些信息必须重新获取.

由于主机不传输关于自身以外任何人的信息, 重启主机将使其地址映射表保持最新. 错误信息不能通过在机器间传递而永久存在; 唯一可能存在的错误信息是在不知道某台其他机器已更改其 48 位以太网地址的机器中. 也许手动重置 (或清除) 地址映射表就足够了.

如果认为此问题重要, 则需要进一步深入思考. 任何类似地址解析的协议都会遇到此问题.