7. Rafraîchissement d'une allocation
Une transaction Refresh peut être utilisée soit pour (a) rafraîchir une allocation existante et mettre à jour son temps avant expiration, soit (b) supprimer une allocation existante.
Si un client souhaite continuer à utiliser une allocation, alors le client doit rafraîchir l'allocation avant qu'elle n'expire. Il est suggéré que le client rafraîchisse l'allocation environ 1 minute avant qu'elle n'expire. Si le client ne souhaite plus utiliser l'allocation, alors il devrait explicitement supprimer l'allocation. Le client peut rafraîchir une allocation à tout moment pour d'autres raisons.
7.1. Envoi d'une demande Refresh
Si le client souhaite supprimer immédiatement une allocation existante, il inclut un attribut LIFETIME avec une valeur de 0. Toutes les autres formes de la demande rafraîchissent l'allocation.
La transaction Refresh met à jour le minuteur temps avant expiration d'une allocation. Si le client souhaite que le serveur définisse le minuteur temps avant expiration à quelque chose d'autre que la durée de vie par défaut, il inclut un attribut LIFETIME avec la valeur demandée. Le serveur calcule ensuite la nouvelle valeur de temps avant expiration de la même manière que pour une transaction Allocate, à l'exception qu'une durée de vie demandée de 0 amène le serveur à supprimer immédiatement l'allocation.
7.2. Réception d'une demande Refresh
Lorsque le serveur reçoit une demande Refresh, il la traite conformément à la section 4 plus les règles spécifiques mentionnées ici.
Le serveur calcule une valeur appelée « durée de vie souhaitée » comme suit : si la demande contient un attribut LIFETIME et que la valeur de l'attribut est zéro, alors la « durée de vie souhaitée » est zéro. Sinon, si la demande contient un attribut LIFETIME, alors le serveur calcule le minimum de la durée de vie demandée par le client et de la durée de vie maximale autorisée du serveur. Si cette valeur calculée est supérieure à la durée de vie par défaut, alors la « durée de vie souhaitée » est la valeur calculée. Sinon, la « durée de vie souhaitée » est la durée de vie par défaut.
Le traitement ultérieur dépend de la valeur « durée de vie souhaitée » :
-
Si la « durée de vie souhaitée » est zéro, alors la demande réussit et l'allocation est supprimée.
-
Si la « durée de vie souhaitée » est non nulle, alors la demande réussit et le temps avant expiration de l'allocation est défini sur la « durée de vie souhaitée ».
Si la demande réussit, alors le serveur envoie une réponse de succès contenant :
- Un attribut LIFETIME contenant la valeur actuelle du minuteur temps avant expiration.
NOTE : Le serveur n'a pas besoin de faire quoi que ce soit de spécial pour implémenter l'idempotence des demandes Refresh sur UDP en utilisant « l'approche pile sans état ». Les demandes Refresh retransmises avec une « durée de vie souhaitée » non nulle rafraîchiront simplement l'allocation. Une demande Refresh retransmise avec une « durée de vie souhaitée » zéro provoquera une réponse 437 (Allocation Mismatch) si l'allocation a déjà été supprimée, mais le client traitera cela comme équivalent à une réponse de succès (voir ci-dessous).
7.3. Réception d'une réponse Refresh
Si le client reçoit une réponse de succès à une demande Refresh avec une durée de vie non nulle, alors il met à jour sa copie de la structure de données d'allocation avec la valeur de temps avant expiration contenue dans la réponse.
Si le client reçoit une réponse d'erreur 437 (Allocation Mismatch) à une demande de suppression d'une allocation, alors l'allocation n'existe plus et il devrait considérer sa demande comme ayant effectivement réussi.