Skip to main content

7. Refreshing an Allocation (刷新分配)

Refresh 事务可用于 (a) 刷新现有分配并更新其过期时间，或 (b) 删除现有分配。

如果客户端希望继续使用分配，则客户端必须 (MUST) 在分配过期之前刷新它。建议客户端在分配过期前大约 1 分钟刷新分配。如果客户端不再希望使用分配，则它应该 (SHOULD) 显式删除分配。客户端可以 (MAY) 出于其他原因在任何时候刷新分配。

7.1. Sending a Refresh Request (发送刷新请求)​

如果客户端希望立即删除现有分配，它会包含值为 0 的 LIFETIME 属性。请求的所有其他形式都会刷新分配。

Refresh 事务更新分配的过期时间计时器。如果客户端希望服务器将过期时间计时器设置为默认生存期以外的其他值，则它包含带有请求值的 LIFETIME 属性。然后，服务器以与 Allocate 事务相同的方式计算新的过期时间值，但请求的生存期为 0 会导致服务器立即删除分配，这是一个例外。

7.2. Receiving a Refresh Request (接收刷新请求)​

当服务器接收到 Refresh 请求时，它按照第 4 节加上此处提到的特定规则进行处理。

服务器按如下方式计算称为"期望生存期 (Desired Lifetime)"的值：如果请求包含 LIFETIME 属性且属性值为 0，则"期望生存期"为 0。否则，如果请求包含 LIFETIME 属性，则服务器计算客户端请求的生存期和服务器的最大允许生存期的最小值。如果此计算值大于默认生存期，则"期望生存期"为计算值。否则，"期望生存期"为默认生存期。

后续处理取决于"期望生存期"值：

  • 如果"期望生存期"为 0，则请求成功，并删除分配。

  • 如果"期望生存期"非零，则请求成功，并将分配的过期时间设置为"期望生存期"。

如果请求成功，则服务器发送包含以下内容的成功响应：

  • 包含过期时间计时器的当前值的 LIFETIME 属性。

注意：服务器无需执行任何特殊操作来使用"无状态栈方法"实现通过 UDP 的 Refresh 请求的幂等性。具有非零"期望生存期"的重传 Refresh 请求将简单地刷新分配。具有零"期望生存期"的重传 Refresh 请求将导致 437（分配不匹配，Allocation Mismatch）响应（如果分配已被删除），但客户端将把它视为等效于成功响应（见下文）。

7.3. Receiving a Refresh Response (接收刷新响应)​

如果客户端收到对其具有非零生存期的 Refresh 请求的成功响应，它将使用响应中包含的过期时间值更新其分配数据结构副本。

如果客户端收到对删除分配的请求的 437（分配不匹配，Allocation Mismatch）错误响应，则分配不再存在，它应该将其请求视为已有效成功。

Last updated on