Connexion et authentification
Une connexion pair-à-pair (port Raft = port client + 1000) s'établit dans exactement le même ordre que le port client. Il n'existe aucune étape dans le protocole pour distinguer client et pair — les rôles sont distingués uniquement par le port.
- Connexion TCP — le côté qui appelle (dial) est toujours le demandeur
- Poignée de main TLS, si le serveur a activé TLS
- Une poignée de main d'authentification — la spécification (challenge, digest, réponse) est identique au bit près à celle du port client
- Échange de RPC à préfixe de longueur à partir de là
Flux
Nœud appelant (dial)
Nœud récepteur
connexion TCP (port Raft = port client + 1000)
poignée de main TLS, si le serveur a activé TLS
challenge (SHA-256 ␣ nonce)
digest — calculé avec le premier jeton de cluster_tokens
vérifié par rapport à toute la liste cluster_tokens
RPC Raft à préfixe de longueur à partir d'ici
requêteréponseRPC de consensus (Raft)
Différences avec le port client
| Élément | Port client | Port Raft |
|---|---|---|
| Ensemble de jetons de vérification | client_tokens | cluster_tokens |
| Jeton envoyé | le jeton configuré par le client | le premier jeton de cluster_tokens |
| Après l'authentification | trames terminées par \n | RPC à préfixe de longueur |
- Côté récepteur, la vérification se fait par rapport à toute la liste
cluster_tokens, vous pouvez donc lister les anciens et nouveaux jetons ensemble et redémarrer les nœuds un par un pour faire tourner les jetons sans interruption de service (Configuration (variables d'environnement)). - Si TLS est activé, le port Raft utilise le même certificat. Le côté qui appelle vérifie le certificat du pair par rapport à
tls_ca(ou le magasin de confiance système si non défini) ;tls_skip_verifyest réservé aux tests. - En cas d'échec d'authentification, la connexion se ferme après
E auth_failed— comme pour le port client.