Ticketing Regeln zur Antwortzuordnung (Client-Implementierung)
Da Antworten in anderer Reihenfolge als die Anfragen eintreffen können (die Antwort auf ein Acquire, das gewartet hat, trifft ein, sobald es an der Reihe ist), muss der Client Antworten den Anfragen mit den folgenden Regeln zuordnen — ein Demultiplex-Schema, das die auf einer Verbindung verschachtelt eintreffenden Antworten wieder ihren Anfragen zuordnet.
| Regel | Details |
|---|---|
| Zuordnungsschlüssel | Definitive Ablehnung wegen Queue/Server-Kapazität; sofort Busy, kein interner Retry |
| Mehrere Anfragen mit demselben (op, key) | FIFO darf nicht vorausgesetzt werden — immer über die Kennung bestimmen. Siehe Erläuterung unten |
| Zeitpunkt der Registrierung | Der Wartende wird vor dem Senden der Anfrage registriert (um eine Race-Condition zu verhindern, bei der die Antwort zuerst eintrifft) |
Behandlung von N/T | Als Nicht-Fehlerwerte zurückgegeben ("existierte nicht" / "Zeitüberschreitung") |
Behandlung von B | Warteschlange voll — nicht sofort scheitern lassen, sondern innerhalb des wait-Budgets mit Backoff erneut versuchen |
Behandlung von M | Nur allowlistete Adresse als Leader-Hint speichern und schließen; ohne owner/key keine Zuordnung zu gesendeten Pending Requests |
Behandlung von L | Nur Leader-Hint aktualisieren und Verbindung halten; Server-Mitteilung, keine Antwort |
E no_leader / E not_active / E auth_failed | Schließen und fehlerabhängigen Backoff anwenden; no_leader verwirft auch den Hint |
Andere E / unbekannte Antwort | Nicht korrelierbar, daher connection-fatal; gesendete Acquires werden Indeterminate |
| Antwort ohne zugehörigen Wartenden | Protocol/Session-Mismatch: schließen. Bei A bekannten exact token an reserved release lane geben |
Warum über die Kennung und nicht per FIFO zugeordnet wird
Auch für denselben Key enden sofortiger Erfolg, Queue-Warten und B-Ablehnung zu unterschiedlichen Zeiten. Mehrere Keys werden ebenfalls auf einer Verbindung pipelined. Nie per FIFO matchen; echoed Identifier, op und key gemeinsam prüfen.
Abgebrochene Anfragen und verwaiste Sperren
War eine abgebrochene Anfrage serverseitig bereits granted, kann der Lock bleiben. Sobald ein Request-Byte gesendet wurde und keine definitive Antwort kam, ist das Ergebnis Indeterminate. A nicht mit demselben Owner wie eine Statusabfrage wiederholen. Nur bei bereits geparstem Token best-effort exact-token R senden; unbekannte Grants werden durch Lease-Ablauf zurückgenommen.
Darum wird nach Cancel nach dem Senden oder Framing-Fehler geschlossen. Nur Pending zu verwerfen kann eine Antwort verwaisen lassen. Socket close beweist keinen Release eines committed Grant: exact-token R wenn bekannt, sonst bis lease expiry Indeterminate.