Protocole — Client ↔ Serveur ​

La spécification complète de chaque octet échangé sur le port client (par défaut 5225). Elle se compose de la poignée de main d'authentification, effectuée une seule fois juste après la connexion, suivie du protocole de verrous à trames binaires. Chaque client officiel implémente cette spécification de façon identique, au bit près.

Le Structure de chaque page de message montre la disposition des champs, et l'Exemple montre les octets réellement envoyés (les valeurs changent avec refresh).

Notation des octets : op est représenté comme un caractère ASCII (par ex. A) ; wait et lease sont des valeurs binaires u8, tandis que token et owner sont des valeurs binaires u64 gros-boutien. Elles sont affichées en hexadécimal (par ex. wait=5 → 05). key et addr sont du texte UTF-8, et reason est du texte ASCII — tous sont de longueur variable, notés N dans la structure. Le \n (retour à la ligne) final termine la trame sous la forme 0A. Les champs sont envoyés à la suite les uns des autres, sans séparateur.

Les en-têtes fixes (wait, lease, token, owner) sont des valeurs binaires et peuvent contenir 0x0A — l'analyseur doit d'abord consommer l'en-tête fixe selon le nombre d'octets propre à chaque op, et seulement ensuite chercher le retour à la ligne. Les tailles sont : requêtes A = 10 o / R = 8 o ; réponses A = 16 o / T·B·R·N = 8 o / M·L·E = 0 o.

Table des matières ​

• Couche de transport
• Poignée de main d'authentification — partagée avec le port Raft du cluster, elle figure donc sur la page Protocole (Commun)
• Requêtes
  • A · Acquisition
  • R · Libération
• Réponses
  • A · Acquis
  • T · Timeout
  • B · Occupé
  • R · Libéré
  • N · Introuvable
  • E · Erreur
  • M · Redirigé
  • L · Avis de leader
• Contraintes de champs
• Matrice requête × état de la clé
• Jeton de fencing
• Règles de correspondance des réponses
• Exemple de session

Le protocole de consensus de cluster (Raft) entre serveurs est traité sur une page séparée.