Contraintes de champs et plages de valeurs ​

Champs de requête (C→S) ​

• Il n'existe aucune attente ni aucun bail infini. Les clients officiels arrondissent les fractions de seconde vers le haut, valident la plage et renvoient une erreur d'entrée explicite avant envoi, sans clamp. Le bail par défaut est de 30 secondes.
• Dans l'API client officielle, wait est la limite globale de l'acquire, depuis l'entrée de l'appel jusqu'à la réponse, en incluant la local queue, les nouvelles tentatives dont l'absence d'envoi est certaine et le write. Un unique monotonic operation deadline est créé ; juste avant l'envoi réel, le writer place dans le wait de la frame l'arrondi supérieur u8 du temps restant. Une connexion tardive ou un failover certainement non envoyé ne peut donc pas recommencer le server wait. À la deadline, une requête encore en queue expire avec certitude sans avoir été envoyée ; si un seul byte a pu partir, la session exacte est fermée et le résultat est Indeterminate. Seul un wait=0 d'origine utilise wire 0, et cette tentative immédiate possède une deadline I/O finie distincte pour ne jamais attendre indéfiniment un transport bloqué. Si un A déjà corrélé juste avant la deadline n'est découvert qu'au gate de livraison du Ticket, le server waiter est déjà résolu : la session reste ouverte, l'exact token connu est libéré en compensation et le résultat est Indeterminate. Les T/B corrélés restent des non-acquisitions définitives.
• Pour un wait=0 d'origine, le comportement wire et server reste une seule tentative immédiate sans queue. Dans sa deadline transport distincte de cinq secondes, une défaillance certainement non envoyée peut choisir une autre connexion et retry avec le même owner. Dès qu'un seul byte a pu être envoyé, l'acquire n'est jamais retransmis.
• L'API officielle exige min_work_budget, absent du wire. Il couvre travail critique + pause prévue + fin du commit/rollback DB, vaut 0..250 secondes et ne dépasse pas le bail normalisé. Sinon, l'appel échoue avant envoi avec une erreur de type UnsupportedDuration/InsufficientLease.
• La longueur de la clé se mesure en octets, pas en caractères — les caractères accentués occupent 2 octets en UTF-8, donc une clé entièrement accentuée atteint 64 caractères.
• owner n'est qu'un identifiant de corrélation de réponse, pas une autorité. Le réutiliser ne rend pas un active token et ne renouvelle pas le bail. Les requêtes simultanées d'un client utilisent des valeurs non nulles distinctes ; si le compteur atteint 0 ou wrap, les clients officiels échouent en mode fermé.
• Un release explicite ou compensatoire d'un token connu dispose de 5 secondes absolues depuis call/enqueue, reconnexions et tentatives incluses. R confirme le succès ; N signifie déjà absent ou token non courant. Une absence de réponse n'est jamais supposée être un succès ; une file compensatoire bornée pleine retombe sur l'expiration du bail.
• bad_key couvre à la fois une clé vide, une clé dépassant 128 octets, une clé contenant un espace ou un retour à la ligne, et un encodage UTF-8 invalide. Les clients officiels n'envoient en plus jamais \r — une clé se terminant par \r deviendrait silencieusement une clé différente.

Champs de réponse (S→C) ​

Le serveur n'émet jamais le token 0. Le mode single utilise un compteur limité à la durée de vie du processus ; le cluster utilise un compteur répliqué par consensus et échoue en mode fermé avant overflow. Ni l'horloge murale ni l'aléatoire ne garantissent la monotonie après redémarrage.

Longueurs d'en-tête fixe ​

La portion binaire de longueur fixe qui suit l'op. Ces octets peuvent contenir 0x0A : un analyseur doit donc en consommer exactement ce nombre avant de chercher le retour à la ligne.

S'il manque des octets, la réponse est E bad_request.

Taille de trame ​

La limite de 192B dépasse la plus grande trame (146B), donc un client conforme ne l'atteint pas. Après une trame structurellement invalide ou oversized, le framing n'est plus fiable et la connexion est fermée.

Handshake d'authentification ​

Voir Handshake d'authentification pour la procédure complète.

Limites côté serveur ​

Ces valeurs ne sont pas fixées directement par le client, mais influencent son comportement.

Le read buffer (4096B), le batch de réponses (64), le progress timeout d'une trame client commencée (5 s) et le sweep d'expiration single (5 s) sont des constantes de compilation. Le cluster emploie un deadline min-heap validant les tokens plutôt qu'un scan complet. Voir la configuration.

L'admission des acquires, nouvelles clés et waiters globaux ferme à 90 % de chaque hard limit et ne rouvre qu'en dessous de 75 %. Un nouvel acquire peut donc recevoir B avant la limite ; la capacité réservée au release et à la récupération Raft est distincte de cette hystérésis.

Récapitulatif : violation → réponse ​

Pour tous les motifs d'erreur et le traitement de la connexion, voir Réponse · Erreur E.