Ticketing Règles de correspondance des réponses (implémentation client)
Comme les réponses peuvent arriver dans un ordre différent des requêtes (la réponse à une acquisition qui a attendu arrive une fois son tour venu), le client doit associer les réponses aux requêtes selon les règles suivantes — un mécanisme de démultiplexage qui trie les réponses entrelacées sur une même connexion pour les rattacher à leurs requêtes.
| Règle | Détail |
|---|---|
| Clé de correspondance | Refus certain pour saturation de file/capacité ; renvoyer Busy immédiatement, sans retry interne |
| Requêtes multiples avec le même (op, clé) | Ne présumez pas le FIFO — identifiez toujours par l'identifiant. Voir l'explication ci-dessous |
| Moment de l'enregistrement | L'attendant est enregistré avant l'envoi de la requête (pour éviter une course où la réponse arriverait en premier) |
Traitement de N/T | Renvoyés comme des valeurs non-erreur (« n'existait pas » / « timeout ») |
Traitement de B | File saturée — n'échouez pas immédiatement ; réessayez avec un backoff dans les limites du budget wait |
Traitement de M | Conserver seulement une adresse allowlistée comme leader hint et fermer ; aucun owner/key pour corréler les pending envoyés |
Traitement de L | Mettre à jour le leader hint seulement et garder la connexion ; notification serveur, pas réponse |
E no_leader / E not_active / E auth_failed | Fermer et appliquer le backoff propre à l'erreur ; no_leader invalide aussi le hint |
Autre E / réponse inconnue | Non corrélable donc connection-fatal ; les acquires envoyés deviennent Indeterminate |
| Réponse sans attendant correspondant | Incohérence protocol/session : fermer. Pour A, envoyer l'exact token connu à la reserved release lane |
Pourquoi faire correspondre par identifiant plutôt qu'en FIFO
Même pour une clé, un succès immédiat, une attente en file et un refus B finissent à des moments différents. Plusieurs clés sont aussi pipelinées sur une connexion. Ne jamais associer par FIFO : vérifier l'identifier renvoyé, l'op et la key.
Requêtes interrompues et verrous orphelins
Si une requête annulée avait déjà reçu un grant côté serveur, le verrou peut rester. Après l'envoi d'un seul octet sans réponse définitive, le résultat est Indeterminate. Ne renvoyez pas A avec le même owner comme une consultation d'état. Uniquement si le token a déjà été parsé, envoyez un R best-effort avec l'exact token ; un grant inconnu est récupéré à l'expiration du bail.
C'est aussi pourquoi la connexion ferme après annulation post-envoi ou erreur de framing. Abandonner seulement le pending peut orpheliner une réponse. Le socket close ne prouve pas le release d'un grant commit : exact-token R si connu, sinon Indeterminate jusqu'à lease expiry.