कनेक्शन और प्रमाणीकरण
एक पीयर-टू-पीयर कनेक्शन (Raft पोर्ट = क्लाइंट पोर्ट + 1000) ठीक उसी क्रम में स्थापित होता है जैसे क्लाइंट पोर्ट। क्लाइंट और पीयर को अलग बताने के लिए प्रोटोकॉल के भीतर कोई चरण नहीं है — भूमिकाएँ केवल पोर्ट से अलग की जाती हैं।
- TCP कनेक्ट — डायल करने वाला पक्ष हमेशा अनुरोधकर्ता होता है
- यदि सर्वर पर TLS चालू है तो TLS हैंडशेक
- एक प्रमाणीकरण हैंडशेक — विवरण (चैलेंज, डाइजेस्ट, प्रतिक्रिया) क्लाइंट पोर्ट के समान बाइट दर बाइट है
- यहाँ से लंबाई-प्रीफ़िक्स्ड RPC का आदान-प्रदान
प्रवाह
डायल करने वाला नोड
प्राप्त करने वाला नोड
TCP कनेक्ट (Raft पोर्ट = क्लाइंट पोर्ट + 1000)
यदि सर्वर पर TLS चालू है तो TLS हैंडशेक
चैलेंज (SHA-256 ␣ nonce)
डाइजेस्ट — cluster_tokens के पहले टोकन से गणना की गई
पूरी cluster_tokens सूची के विरुद्ध सत्यापित
यहाँ से लंबाई-प्रीफ़िक्स्ड Raft RPC
अनुरोधप्रतिक्रियासर्वसम्मति RPC (Raft)
यह क्लाइंट पोर्ट से कैसे अलग है
| आइटम | क्लाइंट पोर्ट | Raft पोर्ट |
|---|---|---|
| सत्यापन के लिए टोकन सेट | client_tokens | cluster_tokens |
| भेजा गया टोकन | क्लाइंट द्वारा कॉन्फ़िगर किया गया टोकन | cluster_tokens में पहला टोकन |
| प्रमाणीकरण के बाद | \n-समाप्त फ़्रेम | लंबाई-प्रीफ़िक्स्ड RPC |
- प्राप्त करने वाले पक्ष पर, सत्यापन पूरी
cluster_tokensसूची के विरुद्ध जाँचा जाता है, इसलिए आप पुराने और नए टोकन एक साथ सूचीबद्ध करके और नोड्स को एक-एक करके रोल करके शून्य डाउनटाइम के साथ टोकन घुमा सकते हैं (कॉन्फ़िगरेशन (एनवायरनमेंट वेरिएबल))। - TLS चालू होने पर, Raft पोर्ट भी वही सर्टिफ़िकेट उपयोग करता है। डायल करने वाला पक्ष पीयर के सर्टिफ़िकेट को
tls_ca(या सेट न होने पर सिस्टम ट्रस्ट स्टोर) के विरुद्ध सत्यापित करता है;tls_skip_verifyकेवल परीक्षण के लिए है। - प्रमाणीकरण विफल होने पर,
E auth_failedके बाद कनेक्शन बंद हो जाता है — क्लाइंट पोर्ट की तरह ही।