跳到主要内容

7. 刷新分配

Refresh transaction 可用于 (a) 刷新现有 allocation 并更新其 time-to-expiry, 或 (b) 删除现有 allocation.

如果 client 希望继续使用某个 allocation, 则 client 必须在该 allocation 过期前刷新它. 建议 client 大约在 allocation 过期前 1 分钟刷新它. 如果 client 不再希望使用该 allocation, 则它应该显式删除该 allocation. client 可以出于其他原因随时刷新 allocation.

7.1. 发送 Refresh Request​

如果 client 希望立即删除现有 allocation, 则在请求中包含值为 0 的 LIFETIME 属性. 请求的其他所有形式都会刷新 allocation.

Refresh transaction 会更新 allocation 的 time-to-expiry 计时器. 如果 client 希望 server 将 time-to-expiry 计时器设置为默认 lifetime 之外的值, 则它包含一个带有所请求值的 LIFETIME 属性. 随后 server 以处理 Allocate transaction 时相同的方式计算新的 time-to-expiry 值, 但有一个例外: 请求的 lifetime 为 0 会使 server 立即删除 allocation.

7.2. 接收 Refresh Request​

当 server 收到 Refresh request 时, 它按照第 4 章以及此处给出的特定规则进行处理.

server 按如下方式计算一个称为 "desired lifetime" 的值: 如果请求包含 LIFETIME 属性且属性值为 0, 则 "desired lifetime" 为 0. 否则, 如果请求包含 LIFETIME 属性, 则 server 计算 client 请求的 lifetime 与 server 允许的最大 lifetime 的较小值. 如果该计算值大于默认 lifetime, 则 "desired lifetime" 为该计算值. 否则, "desired lifetime" 为默认 lifetime.

后续处理取决于 "desired lifetime" 值:

  • 如果 "desired lifetime" 为 0, 则请求成功, 并删除 allocation.

  • 如果 "desired lifetime" 非 0, 则请求成功, 并将 allocation 的 time-to-expiry 设置为 "desired lifetime".

如果请求成功, 则 server 发送一个包含以下内容的成功响应:

  • 一个 LIFETIME 属性, 其中包含 time-to-expiry 计时器的当前值.

NOTE: server 无需采取任何特殊措施, 即可使用 "stateless stack approach" 实现 UDP 上 Refresh request 的幂等性. 重传的 "desired lifetime" 非 0 的 Refresh request 只会刷新 allocation. 重传的 "desired lifetime" 为 0 的 Refresh request 如果 allocation 已被删除, 将导致 437 (Allocation Mismatch) 响应, 但 client 会将其视为等同于成功响应 (见下文).

7.3. 接收 Refresh Response​

如果 client 收到对非 0 lifetime 的 Refresh request 的成功响应, 则它使用响应中包含的 time-to-expiry 值更新自己的 allocation 数据结构副本.

如果 client 收到对删除 allocation 请求的 437 (Allocation Mismatch) 错误响应, 则说明该 allocation 已不存在, client 应认为其请求实际上已经成功.

最后于 更新