Derzeit im Test: Der GitHub-Code wird nach Abschluss veröffentlicht.

R · Release

Strukturrefresh

Eine Sperrenfreigabe-Anforderung. token ist das Fencing-Token, das dieser Erwerb erhalten hat; freigegeben wird nur, wenn es mit dem aktuell gehaltenen Token übereinstimmt. Die Antwort ist Freigegeben R oder Nicht gefunden N.

token — damit niemand fremde Sperren freigibt

Ohne Token-Prüfung entsteht eine gefährliche Reihenfolge: Während eine Freigabe über ein Failover hinweg wiederholt wird, kann die ursprüngliche Sperre durch Ablauf der lease eingezogen und einem anderen Client neu vergeben werden — die verspätet eintreffende Freigabe würde dann die Sperre dieses neuen Inhabers lösen. Da nur bei übereinstimmendem Token freigegeben wird, ist dieser Weg versperrt.

Weicht das Token ab, kommt N (nicht gefunden) und die Sperre bleibt bestehen. Wiederholungen einer Freigabe müssen immer dasselbe Token tragen, und auch die Antwortzuordnung erfolgt über den zurückgespiegelten token (Regeln zur Antwortzuordnung).

Byte-Notation: op ist ein ASCII-Zeichen, token ist binär (u64, big-endian), und key ist UTF-8-Text (variable Länge, in der Struktur als N dargestellt). Das abschließende \n ist 0A. Der feste Header ist ein Binärwert und kann 0x0A enthalten — er muss daher zuerst anhand der Bytezahl verbraucht werden, bevor nach dem Zeilenumbruch gesucht wird.

Ablauf

Inhaber X
Server
Wartender Y
R · release (key · token)
R · freigegeben
falls ein Wartender existiert → A · direkte Übergabe (neues token)
falls der Schlüssel nicht existiert oder das Token abweicht
N · nicht gefunden
AnfrageAntwort

Existiert für den freigegebenen Schlüssel ein Wartender, wird er direkt und ohne erneuten Wettbewerb an die Spitze der Warteschlange übergeben — getrennt vom R (freigegeben), das an den Freigebenden geht, erhält der Wartende ein A (vergeben) mit einem neuen Token.