7. Aktualisieren einer Allokation
Eine Refresh-Transaktion kann verwendet werden, um entweder (a) eine bestehende Allokation zu aktualisieren und ihre Zeit bis zum Ablauf zu aktualisieren oder (b) eine bestehende Allokation zu löschen.
Wenn ein Client eine Allokation weiterhin verwenden möchte, muss der Client die Allokation aktualisieren, bevor sie abläuft. Es wird empfohlen, dass der Client die Allokation etwa 1 Minute vor ihrem Ablauf aktualisiert. Wenn der Client die Allokation nicht mehr verwenden möchte, sollte er die Allokation explizit löschen. Der Client kann eine Allokation jederzeit aus anderen Gründen aktualisieren.
7.1. Senden einer Refresh-Anfrage
Wenn der Client eine bestehende Allokation sofort löschen möchte, schließt er ein LIFETIME-Attribut mit einem Wert von 0 ein. Alle anderen Formen der Anfrage aktualisieren die Allokation.
Die Refresh-Transaktion aktualisiert den Timer für die Zeit bis zum Ablauf einer Allokation. Wenn der Client möchte, dass der Server den Timer für die Zeit bis zum Ablauf auf etwas anderes als die Standardlebensdauer setzt, schließt er ein LIFETIME-Attribut mit dem angeforderten Wert ein. Der Server berechnet dann den neuen Wert für die Zeit bis zum Ablauf auf die gleiche Weise wie bei einer Allocate-Transaktion, mit der Ausnahme, dass eine angeforderte Lebensdauer von 0 dazu führt, dass der Server die Allokation sofort löscht.
7.2. Empfangen einer Refresh-Anfrage
Wenn der Server eine Refresh-Anfrage erhält, verarbeitet er sie gemäß Abschnitt 4 sowie den hier erwähnten spezifischen Regeln.
Der Server berechnet einen Wert namens „gewünschte Lebensdauer" wie folgt: Wenn die Anfrage ein LIFETIME-Attribut enthält und der Attributwert null ist, dann ist die „gewünschte Lebensdauer" null. Andernfalls, wenn die Anfrage ein LIFETIME-Attribut enthält, berechnet der Server das Minimum der vom Client angeforderten Lebensdauer und der maximal zulässigen Lebensdauer des Servers. Wenn dieser berechnete Wert größer als die Standardlebensdauer ist, dann ist die „gewünschte Lebensdauer" der berechnete Wert. Andernfalls ist die „gewünschte Lebensdauer" die Standardlebensdauer.
Die weitere Verarbeitung hängt vom Wert der „gewünschten Lebensdauer" ab:
-
Wenn die „gewünschte Lebensdauer" null ist, dann ist die Anfrage erfolgreich und die Allokation wird gelöscht.
-
Wenn die „gewünschte Lebensdauer" nicht null ist, dann ist die Anfrage erfolgreich und die Zeit bis zum Ablauf der Allokation wird auf die „gewünschte Lebensdauer" gesetzt.
Wenn die Anfrage erfolgreich ist, sendet der Server eine Erfolgsantwort mit:
- Einem LIFETIME-Attribut, das den aktuellen Wert des Timers für die Zeit bis zum Ablauf enthält.
HINWEIS: Der Server muss nichts Besonderes tun, um die Idempotenz von Refresh-Anfragen über UDP mit dem „zustandslosen Stack-Ansatz" zu implementieren. Erneut übertragene Refresh-Anfragen mit einer nicht-null „gewünschten Lebensdauer" aktualisieren einfach die Allokation. Eine erneut übertragene Refresh-Anfrage mit einer null „gewünschten Lebensdauer" führt zu einer 437-Antwort (Allocation Mismatch), wenn die Allokation bereits gelöscht wurde, aber der Client wird dies als gleichwertig mit einer Erfolgsantwort behandeln (siehe unten).
7.3. Empfangen einer Refresh-Antwort
Wenn der Client eine Erfolgsantwort auf eine Refresh-Anfrage mit einer nicht-null Lebensdauer erhält, aktualisiert er seine Kopie der Allokationsdatenstruktur mit dem in der Antwort enthaltenen Wert für die Zeit bis zum Ablauf.
Wenn der Client eine 437-Fehlerantwort (Allocation Mismatch) auf eine Anfrage zum Löschen einer Allokation erhält, existiert die Allokation nicht mehr und er sollte seine Anfrage als effektiv erfolgreich betrachten.